- Local time
- Today, 00:57
- Joined
- Feb 28, 2001
- Messages
- 27,179
I'm getting odd behavior when closing all forms and making Access close, too.
Scenario: Access 2003 DB (soon to be converted to Ac2007, but not soon enough - we have configuration management here that slows down everything we do.) Split FE/BE files, both .MDB format at this time, but running with Ac2007 installed on the system and running the .MDB files.
In the database, I have the MasterControlForm (MCF) as a startup form. It includes the usual gang of events. The startup form tests for certain data safety conditions. If it finds one of the dangerous conditions, it disallows further actions that could compromise data integrity. So the real goal I was testing is to shut down the Access session when bad conditions are found.
The MCF Form_Load code includes this fragment:
The ChangeProperty routine sets the database propery of the given name to the given value. (Found the routine by searching the forums and following links.) This is the property you can touch when in Ac2007 you click the Office button >> Access Options >> "Current Database." We know that call works, see later in the description.
The desired result of this first snippet is that you should not see the navigation pane or ribbon and cannot use special keys. That works correctly. I don't undo or reverse those actions in the production copy, there should be no way for you to see the structure of the database.
By design, when one of the "nasty" conditions is detected, the Form_Load code does this:
Via breakpoints, I saw that after detecting a bad condition, Access actually executed the DoCmd.Close of the form. Access fires the Form_Unload event and the Form_Close event. (No Deactivate event was defined.) Form_Unload in this case doesn't do much, just audit-logs that the database is being closed. It never disallows the Unload. I.e. the Cancel parameter of the Unload event is always 0 (False).
In the Form_Close of the MCF, I take extra care to assure that no recordsets and no subforms are still open. I've used the debugger to set a breakpoint in the Form_Close event so I can watch the Locals window. The remaining open recordset gets closed (confirmed via breakpoint) before running the code snippet below, which is at the very bottom of the Form_Close event code. This next sequence is where my insanity starts.
Everything I've found on-line says that after you do a QUIT command, you don't execute the next line of code. What actually happens is that Access gets to the code above (verified by single-step.) So it executes the Quit method.
The application quits but Access stays open! The FE's .LDB file stays open. Task Manager confirms that MSACCESS.EXE stays open. I have used all sorts of variants here. Application.Quit, Access.Quit, DoCmd.Quit, DoCmd.RunCommand acCmdExit, ... All of the obvious ones and more than a few less obvious ones. Same results each time.
The ChangeProperty call shown earlier DOES prevent use of F11 when the application database closes leaving the Access window open. If I didn't use that call, F11 would bring up the Navigation pane for the database that should have closed fully but did not. Because the database is still open AND LOCKED, users would be impacted if they tried to correct the condition and re-open the database.
Under the circumstances of the test, all timers have stopped and been reset. All other forms either never opened or were closed before getting to that point. The DoEvents call should have allowed all of the sub-forms to settle out, too.
My co-worker and I have researched this for most of the day, hitting this forum, the UtterAccess forum, and several MS Knowledge Base articles, but so far we have not figured this one out. We cannot find anything obvious that is still open that would hold the database in an unclosable state.
Any suggestions out there?
Scenario: Access 2003 DB (soon to be converted to Ac2007, but not soon enough - we have configuration management here that slows down everything we do.) Split FE/BE files, both .MDB format at this time, but running with Ac2007 installed on the system and running the .MDB files.
In the database, I have the MasterControlForm (MCF) as a startup form. It includes the usual gang of events. The startup form tests for certain data safety conditions. If it finds one of the dangerous conditions, it disallows further actions that could compromise data integrity. So the real goal I was testing is to shut down the Access session when bad conditions are found.
The MCF Form_Load code includes this fragment:
Code:
DoCmd.NavigateTo "acNavigationCategoryObjectType"
DoCmd.RunCommand acCmdWindowHide
DoCmd.ShowToolbar "Ribbon", acToolbarNo
bFoundRef = ChangeProperty("AllowSpecialKeys", dbBoolean, False)
The ChangeProperty routine sets the database propery of the given name to the given value. (Found the routine by searching the forums and following links.) This is the property you can touch when in Ac2007 you click the Office button >> Access Options >> "Current Database." We know that call works, see later in the description.
The desired result of this first snippet is that you should not see the navigation pane or ribbon and cannot use special keys. That works correctly. I don't undo or reverse those actions in the production copy, there should be no way for you to see the structure of the database.
By design, when one of the "nasty" conditions is detected, the Form_Load code does this:
Code:
On Error Resume Next
DoCmd.Close acForm, Me.Name, acSaveNo
On Error GoTo 0
Via breakpoints, I saw that after detecting a bad condition, Access actually executed the DoCmd.Close of the form. Access fires the Form_Unload event and the Form_Close event. (No Deactivate event was defined.) Form_Unload in this case doesn't do much, just audit-logs that the database is being closed. It never disallows the Unload. I.e. the Cancel parameter of the Unload event is always 0 (False).
In the Form_Close of the MCF, I take extra care to assure that no recordsets and no subforms are still open. I've used the debugger to set a breakpoint in the Form_Close event so I can watch the Locals window. The remaining open recordset gets closed (confirmed via breakpoint) before running the code snippet below, which is at the very bottom of the Form_Close event code. This next sequence is where my insanity starts.
Code:
DoEvents
Application.Quit acQuitSaveNone
Everything I've found on-line says that after you do a QUIT command, you don't execute the next line of code. What actually happens is that Access gets to the code above (verified by single-step.) So it executes the Quit method.
The application quits but Access stays open! The FE's .LDB file stays open. Task Manager confirms that MSACCESS.EXE stays open. I have used all sorts of variants here. Application.Quit, Access.Quit, DoCmd.Quit, DoCmd.RunCommand acCmdExit, ... All of the obvious ones and more than a few less obvious ones. Same results each time.
The ChangeProperty call shown earlier DOES prevent use of F11 when the application database closes leaving the Access window open. If I didn't use that call, F11 would bring up the Navigation pane for the database that should have closed fully but did not. Because the database is still open AND LOCKED, users would be impacted if they tried to correct the condition and re-open the database.
Under the circumstances of the test, all timers have stopped and been reset. All other forms either never opened or were closed before getting to that point. The DoEvents call should have allowed all of the sub-forms to settle out, too.
My co-worker and I have researched this for most of the day, hitting this forum, the UtterAccess forum, and several MS Knowledge Base articles, but so far we have not figured this one out. We cannot find anything obvious that is still open that would hold the database in an unclosable state.
Any suggestions out there?