You are right - that is a nasty shutdown. Here is what I have resorted to:

LOCAL lcProcessID
lcProcessID = ALLTRIM(STR(_VFP.ProcessId))

CLEAR EVENTS
CLOSE ALL

DECLARE INTEGER ShellExecute IN SHELL32.DLL ;
        INTEGER nWinHandle, ;
        STRING  cOperation, ;   
        STRING  cFileName, ;
        STRING  cParameters, ;
        STRING  cDirectory, ;
        INTEGER nShowWindow

=ShellExecute(0, "Open", "Kill.exe", lcProcessID, "c:\", 0)

Problem is that sometimes the IC error hits before the .DBC (containing about 90 remotes views) is closed thus affecting a lock on SQL Server processes, not to mention rolling back any session updates.

BTW, the IC error occurs imediately following CLEAR EVENTS. Nothing (e.g. forms) have had a chance to be released.

There is alot more information I can give (two weeks of analyzing this monster), but it's too much for this venue. I have been authorized to bring in another consultant if I have to. This is an important app for a very large defense contractor.


>Jeff, the most common cause I've founf for this is to release a form where another, still existing form, holds an object reference, so the form never quite de-instantiates (RELEASE never properly terminates) - the only fix I've found that cleans this up is to issue a quit, followed by issuing a couple of messy API calls:
>
>

DECLARE Sleep IN WIN32API INTEGER
>DECLARE TerminateProcess IN WIN32API INTEGER, INTEGER
>DELCLARE INTEGER GetCurrentProcess IN WIN32API
>IF VERSION(2) = 0
>   ON SHUTDOWN
>   CLEAR EVENTS
>   CLEAR ALL
>   CLOSE ALL
>   RELEASE ALL
>   FLUSH
>   QUIT
>   =SLEEP(30000)
>   =TerminateProcess(GetCurrentProcess(),0)
>ELSE
>   CANCEL
>ENDIF

>
>This can be a messy shutdown, so keep that in mind.