Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Eliminating the Shift startup option and using a backdoor hidden butto 7

Status
Not open for further replies.

Szigeti

Technical User
Mar 26, 2000
7
0
0
US
I am trying to eliminate the option of holding the shift button at startup will open the database in edit mode. I want a hidden button in the startup switchboard to be the only way to enter into the database in edit mode. I wonder how I can eliminate the ability to use the shift function at startup and what kind of code is necessary for back-door hidden button.

I will appreciate any ideas
 
This is from the FAQ of the Access General Discussion:

How can I disable the shift key at startup?
faq181-143

How Do I Disable the Shift Key During Startup?

Read All Carefully Before Proceeding!!!!!!!!!

Here is two sub routines. One is to disable the shift key and the other is to re-enable the shift key.
You only need to call the disable code one time and the shift key will remain disabled until you run the Re-enable code.

The main thing to remember is that you need a way to run the Re-enable code from your open app, but you don't want the user to know how to do it. If you don't have a way to re-enable the shift key will have locked yourself out as well. I usually place a small transparent button on a screen that is seldom used by the user. I usually place the button in a corner where I know where it's at. The Re-enable code is called by the On Click event of this transparent button.

To run the disable the shift key code, you do something similar to the above approach or call the sub how ever you wish. The thing to remember is "Have a way to Re-enable the shift key".

Special Note...............
Make a backup of you db before you start.

'********************************************************
'This Code Disables the Shift Key
'
Public Sub DisableByPassKeyProperty()
Dim db As Database
Dim prp As Property
Set db = CurrentDb
Set prp = db.CreateProperty("AllowByPassKey", dbBoolean, False)
db.Properties.Append prp
End Sub
'********************************************************


'********************************************************
'This Code Re-enables the Shift Key
'
Public Sub EnableByPassKeyProperty()
Dim db As Database
Set db = CurrentDb
db.Properties.Delete "AllowByPassKey"
db.Properties.Refresh
End Sub
'********************************************************

HTH
RDH

 
We had a problem. With the 'Startup' form corrupted and the 'AllowBypass' property set to false we created the following solution. It has the added benefit of not having to hide a control in the target database although that is a viable solution. Just strictly control access to this code to administrators only. We keep a separate database for these type of functions and restrict access.

Function ChangeProperty(strDbName As String, strPropName As String, varPropType As Variant, varPropValue As Variant) As Integer

'ChangeProperty "YourDbName", "AllowBypassKey", dbBoolean, True

Dim mWsp As Workspace, dbs As Database, prp As Property
Const conPropNotFoundError = 3270

Set mWsp = DBEngine.Workspaces(0)
Set dbs = mWsp.OpenDatabase(strDbName)
On Error GoTo Change_Err
dbs.Properties(strPropName) = varPropValue
ChangeProperty = True

Change_Bye:
Exit Function

Change_Err:
If Err = conPropNotFoundError Then ' Property not found.
Set prp = dbs.CreateProperty(strPropName, _
varPropType, varPropValue)
dbs.Properties.Append prp
Resume Next
Else
' Unknown error.
ChangeProperty = False
Resume Change_Bye
End If
End Function

Steve King
 
I hope I'm not doing anything wrong by bringing an old post up again, but this sound usful and I wanted to understand it.
Does the code listed by Steve King above check a "user name" or "security level" to determine whether or not to allow the bypass key?
If so then does it run when you open the database?
If so how do you run this code prior to using the bypass?

Maybe I'm way off in what the code is doing, I had a hard time following it's logic? If I am off is there a way to do this as I have mentioned here?
 
No. Steve Kings code is placed in a seperate database, that only admins have access to. The YourDBName is the name of the database, not the logon name.

In a database I made, I have cerated my own User Permissions system. Basically, the db gets the WinNT logon name, and depending on the logon name and the permissions set in a table, permits access - not perfectly secure as someone may find a back door to edit the table, but good enough for my purposes. Anyway, on startup this database checks the username, and if it is an admin, opens another switchboard form (next to the main switchboard) This then has an option to change the AllowByPassKey value. If there is a bug and it doesn't work, I simply recreate the mde file, as all the data is in a seperate backend.
 
The 'AllowBypassKey' is a database property that can be created by the user. If this key is created and set to 'False' then anyone who logs onto the database will not be able to use the shift key to bypass the startup events. Using the above code you could also create this property remotely, although I haven't tested that feature. If the property is not found it goes to the error condition and runs the create property code.

We had a situation where the 'AllowBypassKey' was set to false thereby disabling the ability to bypass startup by using the shift condition and the startup form was corrupted. Every time we attempted to open the database we would receive and error and Access would shut down. This effectively allowed us to set the 'AllowBypassKey' property to true and then use the shift key to bypass startup and repair the corrupted form.

Steve King Growth follows a healthy professional curiosity
 
Steve, I have used the administrative database function too, but I wanted to point out another solution--well, maybe!

From the Help file (Access 97, start at the "AllowBypassKey Property" topic and select "Enable or disable keys that display the Database or Debug windows, menu bars, or modules" from the See Also link):
"If you clear both the Use Access Special Keys check box and the Display Database Window check box, it's possible that users can still access the Database window. This can happen when a user tries more than once [emphasis added] to open the same database from the list of most-recently-used databases, which automatically appears on the File menu. To prevent users from accessing this list, replace the File menu with your own custom menu."

To me, this means you should be able to open the database normally, in order to get it in the MRU list, then close it and open Access with no database (canceling the open dialog), then open it twice from the MRU list.

However, I said "maybe" above because I didn't actually have much luck getting it to work. But maybe somebody else can. Rick Sprague
 
Rick,

I'm constantly amazed by how little I seem to know about Access given I've been working with it for quite a few years. Yes, there are almost always alternate solutions that work. I was unaware of the alternative you mentioned. Keeping in touch with the newsgroup can help give everyone an alternative perspective.

Steve Growth follows a healthy professional curiosity
 
Hi gang,

I would like to point out something else. If a user can get into ANY VBA module, and they do the slightest bit of reasearch, they can find out how to enable the shiftkeybypass property of any database (current or remote). The code is given in Access 2000 help files.

I would suggest that when you apply security, that you really pay attention to who has Read Design permissions to all objects.

Just a thought!!

Lee
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top