Hi, Ken.
While Jeff has offered excellent advice that answers your question, I wonder
whether you are asking the correct question. You mentioned that clicking on
the Access application close button often causes data corruption. What sort
of data corruption are you experiencing?
Abnormal termination of Access while the user has a write lock on a table
generally causes data corruption, not the closing of Access via the GUI.
Abnormal terminations of Access while the database is open that commonly
corrupt data are: turning off the computer's power switch, yanking the
computer's power plug out of the outlet, using Windows Task Manager to
terminate the MSAccess.EXE process, yanking the computer's network cable out
of its socket, faulty networking hardware severing the user's network
connection to a networked Access database, or the workstation or network
server crashing.
For all practical purposes, clicking the application's close button, or
pressing <ALT><F4>, or programmatically using API functions to call the
application's system menu to close the application window all produce the
same commands from the operating system, in the same order, to the
application. One of these methods requires a lot more effort on the part of
the database application developer, though. (And if you need to justify
your job in this age of IT downsizing, we understand the desire to take the
programmatic approach.)
You haven't described your database structure or application's business
logic, but if your database application needs to guarantee a commit or
rollback of a certain transaction before closing the database application,
then the inability to do so could corrupt the data. This would be the case
when referential integrity is being applied programmatically instead of
through the Jet engine, such as when the tables are linked to different
database files. Obviously, running some special code to guarantee that this
transaction is executed properly before the application quits is necessary,
so programmatically calling the API for the system menu functions would be
appropriate, but only after this special code runs.
If this isn't the case, then perhaps you can clarify your situation for us
so that we may give you some further helpful advice, or perhaps you should
be checking for other causes of the data corruption, such as a user who hits
the computer's power button (and claims otherwise), or a bad network card,
or even a bound memo field. If you would like some free diagnostic tools to
help you determine which user has left the database in a suspect state
(i.e., corrupted), then you may find links to these tools in the "Free
Microsoft Access Troubleshooting Tools" section on this Web page:
http://www.Access.QBuilt.com/html/links.html
HTH.
Gunny
See
http://www.QBuilt.com for all your database needs.
See
http://www.Access.QBuilt.com for Microsoft Access tips.
(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
