How to stop DB from being opened when under maintenance

tucker61

Registered User.
Local time
Today, 06:49
Joined
Jan 13, 2008
Messages
344
To open my database i run code through a cmd prompt that copies the front end of the database onto my local machine using the code below.

copy "\\retail\DB.mdb" %Temp%\DB.mdb /y

start "C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE" %Temp%\DB.mdb

Exit

Before the code copies the front end i want to check if the database is under maintenance, Idealy by checking if a txt file exists somewhere on my network. If the text file exists, Great run the code above. If the text file is missing, Provide a message saying that the database is under maintenance.

I can do this in code in the database, but would really want to do it in the command prompt above.

Is this easy to do ?

Thanks in advance.
 
I make an Offline database that is comprised of one form that opens on load that says 'Database Under Maintenance. This database will be back in service at 12:00 On 12/9/2016'.

I name that database 'Offline.mdb'. Then, when I want to take another database offline, let's say 'Sales.mdb', I rename 'Sales.mdb' to 'Sales_Offline.mdb' and I rename 'Offline.mdb' to 'Sales.mdb' and update the form to show the expected time Sales.mdb will be back.

That way all the links/shortcuts to Sales.mdb still work, but it pulls up my Offline database. When I'm done fixing the actual Sales.mdb I reverse the renaming process.
 
Where I work, we give each user a shortcut to place on their desktop. That shortcut runs a batch file which downloads a local copy of the front end, replacing any existing copy, then runs it. Before it does that, though, the batch file checks for the existence of BLOCK.txt, and terminates execution if it exists.

(And yes, I've suggested actual version control, but it got shot down.)
 
I had two levels of maintenance.

My database was split into front-end/back-end. If I was changing code or form stuff or report stuff, all that was in the FE. Everybody had a local copy of the FE, but there was a master copy as well. If I wanted to change the FE but the BE was OK, I just moved the old copy of the FE that was in the shared folder to an archiving folder and replaced the FE with a new version. Typically, I added a generation number to the name field of the archived version so that I could visually identify which version that copy represented, and I would erase the oldest copy in the archives folder. I usually kept about the last three versions.

When I needed to update the BE, the database had an opening form that looked at a scheduled down-time table and if you tried to open the FE, it would read the BE and tell you, "Go away, maintenance." A timer would check every minute and would also pop up a message that said, "Go Away! Maintenance." Then it would kick out users. After I verified that everyone was out of the DB, I copied the BE file to my working folder and then RENAMED the BE file in-place. That meant that the linked table pointers wouldn't work and the FE file was smart enough to detect this. It would do an orderly shutdown in a way that let the users know the BE was not available. When I was done, usually because of schema changes, I would copy the updated BE to folder and the move the renamed version to that archives folder. At that point, the FE would work again.

For both new FE files and new BE files, I had a facility in the app such that I could broadcast a mail message to all users when a scheduled event was occurring or had just ended. They knew when to pick up a new FE copy and they knew when the BE was safe again.

Just to prevent craziness, I also made it a point to have the FE test where it was located (i.e. which folder) and would make it go away if the users were running the FE from the shared folder rather than their local folder.
 

Users who are viewing this thread

Back
Top Bottom