Shift Start (1 Viewer)

Kundan

Registered User.
Local time
Yesterday, 17:43
Joined
Mar 23, 2019
Messages
118
What is the benefit of pressing the Shift key and starting Access database?
 

HiTechCoach

Well-known member
Local time
Yesterday, 19:43
Joined
Mar 6, 2006
Messages
4,357
Under normal usage, you do NOT want any user to hold down the shift key to open a front end in production.

When I deploy my front end, I disable the bypass key so holding down the shift key will not work

The shift key used when opening a database is called the bypass key.

This will "bypass" or disable the AutoExec macro and will also not load the form set to open when the database loads.

Developers may use it to bypass their startup routine for the database when they want to open it with nothing auto running or autoloading.
 
Last edited:

Kundan

Registered User.
Local time
Yesterday, 17:43
Joined
Mar 23, 2019
Messages
118
Under normal usage, you do NOT want any user to hold down the shift key to open a front end in production.

When I deploy my front end, I disable the bypass key so holding down the shift key will not work

The shift key used when opening a database is called the bypass key.

This will "bypass" or disable the AutoExec macro and will also not load the form set to open when the database loads.

Developers may use it to bypass their startup routine for the database when they want to open it with nothing auto running or autoloading.

Thanks GOD BLESS YOU !!!!
If in case there is a prob in starting the database, is there any setting to start the REPAIR automatically ?
 

HiTechCoach

Well-known member
Local time
Yesterday, 19:43
Joined
Mar 6, 2006
Messages
4,357
Thanks GOD BLESS YOU !!!!

You're Welcome. Glad we can assist.

If in case there is a prob in starting the database, is there any setting to start the REPAIR automatically ?

If a REPAIR is required, then it is important to first make a good backup. Depending on what caused the corruption, doing a repair can fail and destroy the database beyond any ability to retrieve anything. I have tried to help people recover a database after a repair has gone bad and they did not have a current backup.

I will NEVER run a repair on a database without first creating a ZIP of the file and copying the file to a backup folder.

I only run the repair on a database that is on a local hard drive. NEVER NEVER NEVER over a network connection. The network probably caused the issue in the first place.

A multi-user application set up following best practices will use a split database with the back end on another computer and the front end on a local hard drive. If the front end is corrupt, I replace it with a copy from the deployment folder. If the back end needs to be repaired, it is only done on the "server" machine after making the backups.

In 20+ years, this method has a 100% success rate for not losing any data. I can’t say the same for compacting a database over a network connection.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 19:43
Joined
Feb 28, 2001
Messages
27,001
In fact, I'll add general advice on that topic. No matter WHAT you intended to do, if you are going to be making ANY changes to a shared back end file, you have to take the app offline in one of several ways so that nobody can be in it. Then make a WINDOWS-level manual copy of the file as a backup. (Don't use Access for this first copy.)

Make your changes, manually do a compact and repair, and then perhaps make a backup copy using the Access File >> Save options to make a backup. Then and ONLY then, put your app back online.

Now, as to making the app go offline: What I always did was look at the lock file. If there is no lock file, then the odds are that nobody is using the file. Make the non-Access backup copy to another folder. Now rename the shared-folder's copy of the file to anything else. If you can't rename it, the file is still open. BUT if you rename it successfully, nobody will be able to open the front-end file because it won't find the back end.

Now make a copy of the file to a local folder, rename the local copy back to .MDB or .ACCDB as appropriate, make your updates, etc. Open it and do a COMPACT & REPAIR. Now make a backup copy. That copy will have a date tag added to the name. Now finally, copy the local file back to the shared folder (with the proper name).

At this point you can dump the renamed copy of the file from the shared folder because you have three other backups in three different places. Dispose of them as your business model sees fit.
 

Users who are viewing this thread

Top Bottom