I find I will have issues when the macro runs for a very short period of time before executing another macro.  So I will place a pause in between running macros. My utility will run sets of macros in a queue to ensure that only one macro is running at a time.

I also force all of the other sessions to signoff after I have run the macro. It doesn't impact any desktop users and helps with cleaning up 'dead' sessions.

My three macros run at 1130pm, 1205am, and 1230am.  None takes more than a few seconds to run. So, I assume this is not the issue?

Can you let me know how you force all of the other sessions to sign off after? Maybe this is the issue?  Also perhaps best practice to have all sessions sign off before running macro?

Brute force. The return from the .RegisterSignon call will give you the signon number.  When you're all done processing the macro I run the following (FAccpacSignonID is the return from .RegisterSignon):

procedure TmainDM.ClearOtherSessions;
var
    i: integer;
begin
    for i := 0 to 20 do begin
        if i <> FAccpacSignonID then
            mSessionMgr.Signoff(i);
    end;
end;

sorry what language is this? how do you run this?

It does not look like VBA, so I assume its not added to the VBA macro.  It also does not look like the VBS script language.

Macros running in just a few seconds seemed to be a trigger point for lockups.  My macros all have logging and the very last thing they log is that they are done.  In all of my cases I could see that the macro was still running and yet my log said "Done".  There was some sort of 'cleanup' that the a4wvba.exe wasn't performing which left the macro hung.

But, again, it happens most often when the macro was running for a handful of seconds (e.g. start macro, look for transactions to process, find none, shut down). 

I ended up putting Sleep commands in my more problematic macros to give 'the system' time to breath before I shut down the macro and that seems to have helped.

It's VB6. 

You're already calling Signon.SignoffSession SignonID

I just made a loop to clear out any other sessions other than SignonID.

I am sorry to keep bothering.  This has been such a headache for so many years.

The code to signoff does not look like VBA nor the VB script. 

I added it to the VBA macro - code shows error. 

I added it to the VBS (in my original post) and that also caused errors.

Is it possible there are different flavors of VBA?

Oh rats - I'm sorry.  That's Delphi and my old code.

Here is the code that I use to close a session and clean up.

Public Sub CloseSession(Optional aForceAll As Boolean = False)

3530      If SageSessMgr Is Nothing Then
3540          lg " > No Session Manager"
3550          Exit Sub
3560      End If
         
3570      SageSessMgr.Signoff mlSessionID
          
3580      SleepEx 50, False
3590      DoEvents
          
          Dim i As Long
3600      If aForceAll Then
3610          For i = 1 To 10
3620              If i <> mlSessionID Then
3630                  SageSessMgr.Signoff i
3640                  SleepEx 50, False
3650                  DoEvents
3660              End If
3670          Next i
3680      End If
          
3690      mlSessionID = 0
          
End Sub

And you can see that I have Sleep commands after each Signoff call.

Thank you! this seems to run fine. I am calling CloseSession(True) and that works.

Time will tell if we start to hit the same errors.

Thank you!

I decided to go a little more aggressive to ensure shutdown of all open sage instances and signon manager. I wrote a simple batch script and have it run 5 min before each macro.  It kills all the sage tasks that could be a problem for the macros:

Taskkill /IM accpac.exe /F
Taskkill /IM a4wLPMgr.exe /F
Taskkill /IM a4wSignonMgr.exe /F

:)  As long as there will be no users or any other process accessing Sage at that time on that machine then you're fine. But heaven forbid that you're doing an upgrade or something that processes for a while when your cleanup task comes along...

Typically I only have to address the last two of those times and not accpac.exe itself.

The machine these macros run on is a dedicated VM for these macros.  no users allowed!

The machine these macros run on is a dedicated VM for these macros.  no users allowed!