Access won't close after writing to external tables

My application will not close after doing some updates to tables in another Access database file using Recordsets.  I am closing recordsets and setting them = Nothing, I am closing database and setting = Nothing.

My mdb (or mde) is unloaded, but msaccess.exe will not quit.  I have to kill the process in NT Task Manger.  I am not using workspaces.

Anybody seen this?
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

paaskyConnect With a Mentor Commented:
Okay, more rude method is required.. try change &H10 (=Close) to &H2 (=Destroy)

If that doesn't help, then we need TerminateProcess API..

make sure that you are up to date with all of your mdac and dcom updates.

I get this problem when using poorly (In my opinion) made component which handles scanning images and storing the objects.  Check 'everywhere' to make sure you aren't leaving any recordsets open.  Other than that, check you updates and service packs.  If this all fails...another form of attack is always creating a new mdb and importing all objects from the old mdb.  Compact, compact, compact!!!
I was able to get an application like that to close by changing all references to fields in recordsets from the form




Additionally, that app had made all calls to Subs in the form


I changed all of these to the form

    SubName Arg

Doing those two things cause the app to close normally.

The new generation of project management tools

With’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Hello KMAN,

Many people participating EE have had this nasty problem. Here are useful links you find information for the bug and instructions how to fix your database to prevent the problem:


KMANAuthor Commented:
OK - I have changed my boolean IF's so they are explicit, no help.  Recordsets are all closed and destroyed as is the DAO reference to the external MDB file.

No improvements.

I do deploy as MDE with Runtime, when I 'Exit' in this case (.mde /Runtime), I actually get a Run-Time error dialog that reads:
"Execution of this application has stopped due to a run-time error.  The application can't continue nd will be shut down."

Thanks, KMAN
Try this:

Close in the way that won't.
Restore the app so that you can get to the DB window.
Click on the Modules tab, and open any module for design.
If "Debug|Show Next Statement" is available, click it.

It's a shot in the dark, but I'm thinking that there might be some halted code waiting...
KMANAuthor Commented:
Actually the app is closed, just Access itself won't close.

Here's *dirty* method to close your application and Access:

Private Declare Function apiPostMessage Lib "user32" _
        Alias "PostMessageA" _
        (ByVal hwnd As Long, _
        ByVal wMsg As Long, _
        ByVal wParam As Long, _
        lParam As Any) _
        As Long
Public Sub CloseAccess()
Dim RetVal As Long
    RetVal = apiPostMessage(hWndAccessApp, &H10, vbNull, vbNull)
End Sub

KMANAuthor Commented:
Paasky -

I put this code in a module and call the sub from my Exit button (in place of DoCmd.Quit), but to no avail.  Access still won't close.

Thanks for trying.
KMANAuthor Commented:
I prefer KILL to destroy, but either way it works.  Thanks!

What are my possible side effects of using this technique?
Are you using linked tables or are tables in same project?

You should ensure that all table transactions are finished. Access DB is binary file so interrupted actions may cause problems.
KMANAuthor Commented:
Only linked tables and Pass-Through queries.  I don't use transactions so I guess I'm OK there.
OK. Happy I could help you to find work-around for this problem.

Best regards,
KMANAuthor Commented:
I spoke too soon.  This method gives Dr. Watson every time when compiled as MDE and opened with /Runtime option.  Back to the drawing board.

The log gives Fault Info:
function: LszFromIdz
        3001b8fb 6a00             push    0x0
        3001b8fd 8bd6             mov     edx,esi
        3001b8ff e806000000       call    LszFromIdz+0x1c6b (3001b90a)
        3001b904 5f               pop     edi
        3001b905 5e               pop     esi
        3001b906 c9               leave
        3001b907 c20c00           ret     0xc
        3001b90a 83ec0c           sub     esp,0xc
        3001b90d 53               push    ebx
        3001b90e 55               push    ebp
FAULT ->3001b90f 8b5a04           mov     ebx,[edx+0x4]          ds:09c5f3d6=????????
        3001b912 56               push    esi
        3001b913 57               push    edi
        3001b914 8b7c2420         mov     edi,[esp+0x20]         ss:0174e6ab=????????
        3001b918 33ed             xor     ebp,ebp
        3001b91a 8bf1             mov     esi,ecx
        3001b91c 3bfd             cmp     edi,ebp
        3001b91e 89742418         mov     [esp+0x18],esi         ss:0174e6ab=????????
        3001b922 896c2410         mov     [esp+0x10],ebp         ss:0174e6ab=????????
        3001b926 7506             jnz     LszFromIdz+0x1c8f (3001b92e)
        3001b928 8b3dd4ac2930     mov     edi,[3029acd4]         ds:3029acd4=00000000
        3001b92e 57               push    edi

I'm sorry to hear this. hmmm.. runtime/MDE seems to work differently as I can see.. How about making external program with VB/C++/Delphi/SomeOtherTool? that is launched just before you close the application which will wait <x> seconds and then kills Access window?

I also saw suggestion that there are MS Access analyzer tools which could help you to check your code. See

KMANAuthor Commented:
Low and behold, there was a little itty-bitty DAO database not being destroyed.  Found it, coded it...problem gone.

This was a valuable lesson none-the-less.

Thanks for all the help.
All Courses

From novice to tech pro — start learning today.