Holding down Shift

J

jonnymenthol

Registered User.
Local time
Today, 11:55
Joined
Oct 31, 2001
Messages
58
Hello all,

Is there any way of stopping users of my database from holding down Shift and getting into the database.

I however, still need some sort of facility to do this, so I can add new forms, queries etc whenever necessary.

Thank you in advance, and apologies if this is not the correct place to post, but I'm very new at this.

Thanks.

J.
 
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.

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!
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
HTH
 
Last edited:
ghudson's code is the best I've come across for doing what you're looking for. I've tried others but this prevents anyone from figuring it out.
 
Thanks for the compliment Rob.Mills. It is simple yet very effective for keeping the riffraff out. I bet I average one posting per week with this code on at least one forum.
 
ghudson - Thanks very much for your response.

The code is first class, and it worked a treat.

It's people like yourself that make this board what it is !!!

Thanks again.

Jonny.
 
Thank you for the code, it works great.
Just want to know if there is a way to mark the password with (*)
Thanks
Newman
 
I was thinking about that too. What I'm considering is replacing the inputbox with a custom form and set the format of the textbox to password. Then pass that string on to the procedure. I'm thinking it shouldn't take that much modification.

ghudson, would you agree that this will work?
 
Using a form will allow you to format the text box as a password. I never had a need to hide the password with ********* so I kept the coding simple by using an input box.

You will have to take it a step further and use real Access security once the glemlins figure out that they can import your db objects into their own db. Then they can open up "your" forms, modules, etc. from their db and see all your secrets.

;)
 
ghudson said:
You will have to take it a step further and use real Access security once the glemlins figure out that they can import your db objects into their own db. Then they can open up "your" forms, modules, etc. from their db and see all your secrets. ;)
Click to expand...

I have a solution to that problem

I just kill the B*****D.................... :D
 
G Hudson,

Your example of shift disable is absolute ace. I have managed to convert my database to an mde and disabled shift etc and I am quite excited that nobody can get into my data such as tables, forms etc.

The next step is to look at the security side of things, although I am a bit worried about that challenge as I have only kind of went over it briefly, but can I ask, with an MDE and the code you have provided to disable shift, is my database now fully secure?
I have also unticked allow special keys/hide database window etc and created a login form as the startup screen.
Is there any other way in which my table data, queries, forms etc can be exported?

Let's All Chant G Hudson :)
 
Last edited:
Charles -

No, your db is in no way secure... Here's a scary/fun trick! Create a brand new, empty db. Go to File -- Import and navigate to your mde then import all of the tables and queries!!!

Because its an mde you wont be able to get to the forms, marcos (no one but one person here really uses these anyway), and modules but the user can surely get to all of the data (the most important piece IMO)...

TO Fully secure you'll have to use Access User Level Security and cross your fingers here on this as this is a pain in the you know what... or.... do your self a favor and write the app in VB.NET! :cool: (couldn't resist a crack on Access)

HTH,
Kev
 
Charles -

Open a new, blank db and save it to your desktop. Next, click File -- Get External Data -- Import. The open Dialog box will open - navigate to your shift bypass, protected .mde and select it. After you select it you will now see all of the objects contained in the db!!!!! (Note* forms/macros/modules will be greyed out and unselectable in an .mde) They even make it easy for you by having a 'Select All' button. Click the tables tab and then click the select all button - ok - and PRESTO!! all of the tables are in the new, unsecure db....

Kev
 
Hi Kevin

Thanx for your reply again m8.

Please excuse my ignorance. Although I haven't created a new MDB on my desktop, I understand the risks with my unsecured database.
I will now start to look at security (whilst saving a backup) and hopefully explore this complexed area.

Thanx again m8.
 
No Problem Charles - wasn't trying to yell at you - just wanted you to know that what you thought was "secure" was actually not...

If your beginning to explore Access Level Security do two things first:

1 - make a backup of your database file.
2 - make a copy of the system.mdw file of which you will be modifying.

Also - you can find a complete wall-though of the steps for securing a db located on the Microsoft knowledge base website. Read these instructions, then read them again, then search this forum for keyword "user level security" - there are many posts on the subject on this forum.

If you still having problems after all of this post back to this thread and I will help you...

HTH,
Kev
 
Kevin_S said:
1 - make a backup of your database file.
2 - make a copy of the system.mdw file of which you will be modifying.
Click to expand...
1 - Yes
2 - Yes & No ~ Do NOT alter your System.mdw file. Create a new workgroup file!
 
ghudson said:
1 - Yes
2 - Do NOT alter your System.mdw file. Create a new workgroup file!
Click to expand...

Should have clarified - Charles you wont be modifying the original system.mdw you actually create a new .mdw and add users to that new .mdw. For with modify I actual meant, and should have said, that many people try to manipulate the original .mdw file and in the end usually try to solve the problem by deleting it... by making a backup of the file you are assured to be safe so you don't lock yourself out...

good call ghudson - thanks for pointing that out...

(probably should have gotten that first cup of coffee before I starting trying to help this morning!) :D

HTH,
Kev
 
Thanx Again Kevin & G Hudson,

I am a day or two away from starting the security wizard. I have looked over quite a few threads in this subject and from what I have read, I will need to read up a wee bit on it first.
I have kept a back up off the MDB & MDE version of the database - so I will have a play about with the security settings and I'll let u guys know how I get on.

Thanx again
 
Secure DB

:cool:

I noticed this post and couldn't help myself to reply!

I can't remember where this method originated (wish I could take the credit) ;) ....at any rate, I think this provides the MOST security.

First, in the Back End, set a DB password: Tools, Security, (in this case, case sensitive "PASSWORD").

Next set the security for coding: F11, Tools, Properties, Protection....set password. (In this case PW2).
*********DO THIS ALSO FOR THE FRONT END*********
*********AFTER ALL THIS IS WHERE THE BULK OF YOUR CODING IS**************************************

I believe Canadace Tripp (not sure if it’s CT’s site) provides a method of how you must "PROVIDE THE LOCATION" of the linked tables. Candace Tripp

Once you open the sample, you will see how it works. The macros provide a way in and out of the db. C+S+G will unlock the bypass and C+S+S will lock the bypass.

Also, if someone attempts to IMPORT your data from the BACK END to a new DB, they MUST know the password to the database. If they should be brilliant enough to crack that, they then MUST also know the password to for the coding. Without these passwords, NOTHING can be imported! The "Path to Linked Tables" method forces the user to know the Path to the BE (this is important if someone were trying to re-link tables).

If the method of "knowing the Path to the tables" is applied, the prying eyes would have to know even more, they would have to know the PATH to the backend, they would have to know the PW for the BE db and they would have to know the PW for coding.

Therefore, should prying eyes be curious, they would also need a lot of work to get to the DATA.

Everything in the db which is attached, is very simple to apply to your own db. The "Path for Linked Tables" method requires only a small amount of work, yet very effective.
 

Attachments

kybb1 said:
:cool:

I noticed this post and couldn't help myself to reply!

I can't remember where this method originated (wish I could take the credit) ;) ....at any rate, I think this provides the MOST security.
Click to expand...

Its a good little example.

The problem is, I want to create a database for others to use.

ie: Create a database, and give it to them, but I dont want them to gain access to any forms or tables.

How is this possible?

In other words, to make myself more clearer:

I want to give an organisation my database as an application.

I want them to be able to use it without needing (access) usernames and passwords. But I dont want them to be able to access/modify the tables or forms...

Is there anyway to create and MDE file that can import/export tables, but not allow other databases to import them?

I imported my "staff" table into a blank database, changed a low profile user's admin field from "no" to "yes", exported it back, and had full reign of the program.
 
yhgtbfk said:
Is there anyway to create and MDE file that can import/export tables, but not allow other databases to import them?
Click to expand...
You will have to implement Access security with workgroups and permissions if you want to prevent somebody from linking to your database. A MDE only protects the design of the forms and reports and modules. A user can access and modify the tables [data and design], queries and macros in a MDE.
 
You must log in or register to reply here.

Similar threads

D
Calendar displaying autonumber from a combo box..
Replies
5
Views
325
Pat Hartman
P
A
Having trouble with a combo box
Replies
17
Views
550
Pat Hartman
P
M
Shift Key Bypass
Replies
14
Views
1,075
Marshall Brooks
M
H
Problem with Search Boxes
2
Replies
24
Views
874
Pat Hartman
P
T
Copying a split FrontEnd
Replies
5
Views
308
Pat Hartman
P

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top Bottom