Closing your data base

[atrium]

Is it appropriate to close out of your database by just closing Access.

Could it cause corruption??

 

[theDBguy]

Hi. I have no evidence of this, but I would hope that Access is smart enough to gracefully close out your database when you close the entire application. Why do you ask?

 

[arnelgp]

same is true with Excel?

 

[The_Doc_Man]

I'm going to explain what I believe to be the case. The answer to your question is in more than one part.

1. For an Access monolithic database or one where the front end and back end are both "native" Access .MDB or .ACCDB files, you are using SMB protocol to read and write segments of the data tables. The read/write operations have been initiated and are, at the very least, pending in your system's I/O queue. Where a BE file is involved across a network, the buffer to be written is already in the network I/O queue and (I believe) is not delayed because network I/O is considered slightly higher in process priority than local I/O.

When the Access image shuts down, it triggers what is called an I/O Rundown. This is a WINDOWS thing that causes all pending I/O to be completed if it had not been completed. There is a table (not an Access table) inside Windows that lists the handles that are open for a given process. Some non-Windows systems call this the channel table. As the final act during rundown, Windows for each I/O channel (handle) issues an IOClose operation. Therefore, if you were watching the Task Manager display of active processes, it would be POSSIBLE (not guaranteed) to see that Access doesn't actually disappear from the process list immediately. There is a slight lag. When Access disappears, everything is complete and everything is closed. All pending I/O is complete. Memory buffers cannot be released until the task that held them signals (through I/O completion) that is done with them. This is part of the safeguards that prevent data loss by recognizing the temporal nature of process I/O.

2. For an Access FE using some other type of BE based on an active SQL engine (SQL Server, ORACLE, INGRES, SYBASE, ...), while most of what you do (via SQL) should not cause corruption, it is at least theoretically possible that you COULD construct a bad action query that leaves your DB in a really bad state. Invariably, such queries would not be considered "good programming practice" anyway. However, if you take care to avoid TRYING to construct bad queries, you should be OK. Most normal queries will reach completion, particularly if they are across a network.

3. IF you used Access to open something else - like Excel or Word as application objects - then closing Access doesn't guarantee a clean shutdown. This is because the "something else" programs are running as Windows processes that have a life of their own. Their primary input and output and command channels are essentially network-like connections using the Loopback channel that is on EVERY machine that has a TCP/IP stack. (This is true for Windows, Unix family, and OpenVMS, and I recall it was true for DEC TOPS-10 and RSX-11M/D as well.) Anyway, if you fail to command your "something else" programs to quit, whatever THEY had open at the time, though it might NOT be a database, could be corrupted when someone has to come behind you to clean up the "dangling" processes.

4. In ALL cases, if you are in the middle of some non-trivial action query and you catastrophically lose power when a disk I/O is active, THAT would easily cause corruption - but that would NOT be case of a graceful Access shutdown so is outside of the original scope of your question.

 

[atrium]

Thank you very much "The Doc Man" ours is a Monolithic Database with 16 users on a network. You have answered my question perfectly and and the other scenarios are good knowledge for our future development and expansion.

Once again thank you

 

[FrankRuperto]

In all of the Access front end's we have worked with we make use of modal forms where appropiate, and disabled the windows exit button to force users to exit via a control in the switchboard, which is the entry/exit point.

 

[The_Doc_Man]

ours is a Monolithic Database with 16 users on a network.

Ouch - that is NOT good. A 16-user database needs to be shared via split Front-End/Back-End because of file locking and lock contention. A shared monolithic database runs a SERIOUS risk of corruption because of potential deadlocks in the midst of individual session shutdowns. You can even run into file locks on the forms and reports in the worst-case scenario. Every one of those 16 users needs to have a private copy of the FE and you have to assure that the BE is shared using Optimistic (or No) locking. Otherwise, you can jam yourself up INCREDIBLY badly.

Split Database Concept

Hello Guys, I would like to clarify whether my understanding about Split Database is correct or Not. I have a Database in my Network Drive and there are 20 Users are going to Access this Same Database. This may cause Access Database to be slow and chances to get my Database get corrupt. To...

www.access-programmers.co.uk

Solved - Possibilities Of Centralized FE For All Users OR Individual FE At Each Terminal

Hi, I dont know if this question was asked before or not but I need to know if a centralized Access FE copy can be used by multi-users or delivering separate copies to various terminal is the right way. The only thinking behind this we could save time in delivering and setting up FE at each pc...

www.access-programmers.co.uk

 

[The_Doc_Man]

In all of the Access front end's we have worked with we make use of modal forms where appropiate, and disabled the windows exit button to force users to exit via a control in the switchboard, which is the entry/exit point.

Frank, while I fully agree with that strategy and have used it myself more than once, at some point you will have to exit the DB and that is when the process I described becomes important.

 

[Pat Hartman]

The user is always the ultimate control when it comes to closing the database. He can always use the three-finger salute.