Menus hidden on database load - how to unhide

[Whoopsidaisy]

Hello,

I have hidden most of the menu bars for my database (from the tools.. startup.. menu) and I dont have a backup of my latest database (yes, I know, stupid.) The only menus I have are File, Edit, Insert, Records, Window and Help. The database window is also not displayed.

How do I get them back..? My database is set to load a form on startup, all data is accessed via a set of forms linked from the first. I cant access the tables, design view, anything.

Help!!

 

[rainman89]

hold shift down on startup!!

Also please dont post your questions more than once

 

[jon jomaco]

Well if he won't thank you i will. I'm just currently messing about with the whole hiding menus etc thing.
Cheers,
Jon.

 

[mrbillbenson]

I just want to remark, late date that it is, how much this post helped me tonight. I had "locked" myself out of a database exactly for the same reason, and this Shift key method of opening saved me BIG time. Thank you.

 

[isladogs]

Only 11 years after the previous reply!

This method is called the shift key bypass.
When developers add security features to their apps, the shift key bypass is often disabled to prevent this approach being done.
If you haven't yet done so, I recommend you save a backup which hasn't been locked down for you to use during development work.

 

[The_Doc_Man]

mrbillbenson, if you are going to use the shift-key bypass, remember that everyone else can do that too.

Usually, when you want to do this, you disable shift-key bypass BUT you also include some backdoor method that allows you to trigger the code to undo disabling of all of those things that the startup code disables. You don't disable everything without having a way to re-enable stuff. You ALSO don't do it this way if the purpose of re-enabling stuff is for development purposes. In that case, you keep a separate "dev" copy that you can diddle with, and when it is "ready for prime time" you copy that and do the final steps to make it a production copy, then distribute it.

In my case, I had a label that was basically a static form name area. I put in a double-click event on the label and allowed that to trigger a dialog IF the person doing the double-click had permission to re-enabled the stuff that had been disabled. The ONLY time I ever used it was on-the-fly data repair. Code repair was always through the DEV copy and that had a formal "promotion" cycle for quality control.

How you would determine the "permission" question is of course up to you.