[X]My Assistant

[louzam2115]

If a users uses shift to stop all startup commands and what not, am I still able to place some sort of password against that? So if a users does hold shift at start up it still requires a password to look at the database objects

[R. Hicks]

The short answer is no ...

The ShiftKey is a property created in the database ...
It can not be password protected ...

RDH

[louzam2115]

Then I am assuming that you should never tell a user about the shift key
Way someone knows about it, is there any way to prevent chaos on your databse if they know about the shift key?

[R. Hicks]

Not much you can do aboout is .. as it is pretty much known by all with the slightest knowledge of Access ...
DH

[StevenLS]

there are a handful of databases floating around that allow you to enable and disable the shift bypass feature completely.
When I am at a particular client next I can email you a database I have there that does that very thing.
S.

[R. Hicks]

The app that you describe is in the Access Code Archives here at Utter Access ..
And most others found on the internet have be copied from this app ...
But that is not the problem ...
They want to know if the property can be password protected ...
RDH

[StevenLS]

just chucking another option into the fray.

[louzam2115]

Yes, I did notice that, unfortuently I want to be able to still use the shift key for my own uses.
Thanks for the ideas.
Louis

[R. Hicks]

The question was .. "Can the bypass shiftkey property be password protected" ...
The utility you speak of has nothing to do with that aspect ...
DH

[ghudson]

You can use a password to "control" if the shift key "property" is enabled or not.
The db will have to be closed and reopened to be able to open [or not open] the
db using the shift key after you use the code to disable/enable the shift key.
The below function and command button code will allow you to use a password
protected input box to determine if the Shift key can be disabled or not. The
Input Box is only used as a quick example for the below code. I do not recommed
using an input box in your application. Use a custom form or hidden text box.
You might have to set your "References" to DAO 3.6. When you are viewing
the module, click the Tools menu >>> References >>> and Browse for Microsoft
DAO 3.6 >>> Select "Files of type: Executable Files (*.exe; *.dll)"
My DLL was located @ C:\Program Files\Common Files\Microsoft Shared\DAO.
Copy this function into a new public module.

CODE

Public Function SetProperties(strPropName As String, varPropType As Variant, varPropValue As Variant) As Integer
On Error GoTo Err_SetProperties
    
    'Dim db As Database, prp As Property
    Dim db As DAO.Database, prp As DAO.Property
    
    Set db = CurrentDb
    db.Properties(strPropName) = varPropValue
    SetProperties = True
    Set db = Nothing
    
Exit_SetProperties:
    Exit Function
    
Err_SetProperties:
    If Err = 3270 Then 'Property not found
        Set prp = db.CreateProperty(strPropName, varPropType, varPropValue)
        db.Properties.Append prp
        Resume Next
    Else
        SetProperties = False
        MsgBox "Runtime Error # " & Err.Number & vbCrLf & vbLf & Err.Description
        Resume Exit_SetProperties
    End If
    
End Function

Assign this to the OnClick event of a command (transparent?) button named "bDisableBypassKey".
Change the "TypeYourPasswordHere" default password.
This sub ensures the user is the programmer needing to disable the Bypass Key.
You can not format an Input Box! [well you can but it takes a lot of code.]

CODE

Private Sub bDisableBypassKey_Click()
On Error GoTo Err_bDisableBypassKey_Click
    
    Dim strInput As String
    Dim strMsg As String
    
    Beep
    strMsg = "Do you want to enable the Bypass Key?" & vbCrLf & vbLf & "Please key the programmer's password to enable the Bypass Key."
    strInput = InputBox(Prompt:=strMsg, Title:="Disable Bypass Key Password")
    
    If strInput = "TypeYourPasswordHere" Then
        SetProperties "AllowBypassKey", dbBoolean, True
        Beep
        MsgBox "The Bypass Key has been enabled." & vbCrLf & vbLf & "The Shift key will allow the users to bypass the startup options the next time the database is opened.", vbInformation, "Set Startup Properties"
    Else
        Beep
        SetProperties "AllowBypassKey", dbBoolean, False
        MsgBox "Incorrect ''AllowBypassKey'' Password!" & vbCrLf & vbLf & "The Bypass Key was disabled." & vbCrLf & vbLf & "The Shift key will NOT allow the users to bypass the startup options the next time the database is opened.", vbCritical, "Invalid Password"
        Exit Sub
    End If
    
Exit_bDisableBypassKey_Click:
    Exit Sub
    
Err_bDisableBypassKey_Click:
    MsgBox "Runtime Error # " & Err.Number & vbCrLf & vbLf & Err.Description
    Resume Exit_bDisableBypassKey_Click
    
End Sub

[R. Hicks]

That is useless if someone has the utility in Access Code Archive forum ...
Anyone with any knowledge of Access can get into this app ...
DH

[ghudson]

True, but he has not asked about using Access security...yet.

[jfanya]

Hi there. I just wanted to thank you for your post! I was finally able to come up with a solution to the shift key problem. I knew I could set up some kind of password, but since Microsoft's own code suggestion (CurrentProject.Properties.Add "AllowBypassKey", False) doesn't seem to work, I needed your wonderful SetProperties function in order to make it all happen. If you're interested, my solution is here. Thanks again!
essica

[R. Hicks]

Again .. this is useless ...
If you create a small database file .. and set you shilft key property off and attach it to a reply.
I will send the file back to you with the property turned on .. and will post the password you set ...

RDH

[datAdrenaline]

Isn't the by-pass property a DESIGN change? ... So if you design the database with an owner besides Admin ... and you do not give the Admin user the priviledge of making design changes to the database ... won't this prevent the setting of the By-Pass property? ... Unless you are the DB owner? ..
... I guess I will try it out and post my findings.
Also, what I have done in some cases is this, compile my app to an MDE to protect my code and other objects, then in the start-up code create all my linked table-defs. Plus in my start-up code, I check for the by-pass property ... if it set to Allow the shift key, I reset it then quit the app, unless it is me who started the app (use the Windows User Name to determine who is starting the app)... granted you can still open the db, but most, if not all, of what you see is pretty much useless to a hacker.
I have another way to force start-up code, but again, you can open and browse the object titles ... you just can't do anything with them.

[jfanya]

Right, but isn't the app ultimately useless also, because anyone who's determined enough can find it online, put it on their own diskette, and use it on any database they like?
up, I realize that if someone is determined enough, they can "hack" my database. But in terms of a deterrent for someone who simply knows about the shift key and wants to snoop around, this seems like a good option.
P.S. Can you divulge your secret for figuring out my password?

[R. Hicks]

Not saying the app is useless ...
I am saying that if you expect bypassing the shift key to be a secured application .. then you are mistaken.
The code need to unset the property can be found in about 5 seconds on the internet ...
RDH

[datAdrenaline]

Here is an example of a properly set AllowByPasskey ... You can change it only if you have the correct permissions on the database. I know you can purchase utilities that will crack the workgroup information required, but that is definately a bigger barrier to cross than just D/L'ing the utility here on the Archives. I can post the .MDW I used to secure it as well ... I just wanted to post it in its LOCKED state first.

Attached File(s)

 ProtectByPassKey.zip ( 15.69K )Number of downloads: 157

 

[datAdrenaline]

>>> I am saying that if you expect bypassing the shift key to be a secured application .. then you are mistaken <<<
.. I 100% agree ... MS Access security mechanisms are not "world class"... but they are pretty effective for keeping most people honest! ... If a person has to go through great lengths to get past the barriers you place in the system, then SOMETHING ought to trigger in their brain that says ... "HEY! ... I shouldn't have to do this to get what I need ... maybe I should speak to the developer of the app and see if we can get this feature added or unblocked"

[fdelval]

5 years later, i discovered the thread.
Any possibility to get the .MDW file?
FOr any others possibilities to block users?