Results 1 to 10 of 10
  1. #1
    Join Date
    Feb 2004
    Location
    Colorado state
    Posts
    65

    Unanswered: Disable Get External Data

    Got a quick question.

    Is it possible to code into access a way to disable the "GET EXTERNAL DATA" command on a toolbar? I am trying to secure a personal db that is written in access 2000. The db is not split and has a password. I have also found a db that disables the "shift" key. I am not too sure how secure that is though. Anyone with that same db can enable the "shift" key.

    Can someone help me secure this db?

    Thanks
    Mike

  2. #2
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926

    Disable

    Take a look at the example attached. You cannot get to any of the menu items (i.e. you would create your own menu system). It uses a simple technique I made where you open a "MainFormBackground", maximize it, and then set your other forms to pop-up and modals. It's a nice way of keeping the average user from utilizing the menu system. Normally I would have a button on the "Main Menu" form which would allow closing of that form and the "MainFormBackground" (based on permissions) so I could quickly and easily get at coding. Notice also that it uses a quick and easy way of getting the loginID, comparing it to a permission table (you could have several different permission tables) and allow permissions to certain forms/buttons, etc. You could even have a "users" type table where if the user wasn't in that table (which would check on the opening event of the MainFormBackGround), it would quit the application. I also used some class modules to get rid of the caption bar so user's can't get into the design mode of the form. There are other techniques. This is one I just use because it's quick and easy without a lot of hassle.

    In regards to the shift key....you can do it, but do you really have users who "want" to get behind the scenes and are apt at doing it (i.e. know about the shift key). You have to weigh that against how easy you want it to be for you to make changes if you constantly need to get into the db. I like to use the SQL Server "default user" to know who's been adding/changing data behind the scenes. You could probably do something similar with MSAccess tables.

    (I hate database programs where I have to enter a loginID and password everytime I get into it.)
    Attached Files Attached Files
    Last edited by pkstormy; 09-24-06 at 00:01.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  3. #3
    Join Date
    Feb 2004
    Location
    New Zealand
    Posts
    1,423
    Provided Answers: 8
    A way I stop the user is put =1 in the Menu bar or the form

    =1 will stop the file edit ... menu from showing
    hope this help

    See clear as mud


    StePhan McKillen
    the aim is store once, not store multiple times
    Remember... Optimize 'til you die!
    Progaming environment:
    Access based on my own environment: DAO3.6/A97/A2000/A2003/A2007/A2010
    VB based on my own environment: vb6 sp5
    ASP based on my own environment: 5.6
    VB-NET based on my own environment started 2007
    SQL-2005 based on my own environment started 2008
    MYLE
    YOUR PASSWORD IS JUST LIKE YOUR TOOTHBRUSH DON'T SHARE IT.

  4. #4
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Paul raises a very important point about security in his post. You have to consider what you're trying protect, and who you're trying to protect it from. We all too often get caught up in the current security frenzy and don't stop to think "Who would want to access my system?" and "Would it really make any difference?" as well as "Is the need for security worth the effort/cost?"

    There's a post on this site as we cyber-speak where the poster asks "How can I stop two users using the same username and password" and then proceeds to say that he simply can't keep employees from sharing their usersnames and passwords! Then he wants a way to still inforce security and/or at least track who makes changes in data!
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  5. #5
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    I'm curious about Myle's =1 and how you would instigate that via vba in the form. What would be the command in vba (or how would you do it via the Menu bar)?
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  6. #6
    Join Date
    Feb 2004
    Location
    New Zealand
    Posts
    1,423
    Provided Answers: 8
    Quote Originally Posted by pkstormy
    I'm curious about Myle's =1 and how you would instigate that via vba in the form. What would be the command in vba (or how would you do it via the Menu bar)?
    What I do Is On form open

    if Admin then
    Me.MenuBar = "" 'show menus
    else
    me.menubar = "=1" 'don't show menus
    End if
    hope this help

    See clear as mud


    StePhan McKillen
    the aim is store once, not store multiple times
    Remember... Optimize 'til you die!
    Progaming environment:
    Access based on my own environment: DAO3.6/A97/A2000/A2003/A2007/A2010
    VB based on my own environment: vb6 sp5
    ASP based on my own environment: 5.6
    VB-NET based on my own environment started 2007
    SQL-2005 based on my own environment started 2008
    MYLE
    YOUR PASSWORD IS JUST LIKE YOUR TOOTHBRUSH DON'T SHARE IT.

  7. #7
    Join Date
    Feb 2004
    Location
    Colorado state
    Posts
    65
    Hey thanks for all the responses. I have considered what I am protecting. This is a personal db and is for my eyes only. I have tried the "=1" option before in the properties view. I will try it this way as well and keep you all posted.

    Thanks
    Mike

  8. #8
    Join Date
    Feb 2004
    Location
    Colorado state
    Posts
    65
    This just occured to me and I should have put it in my last post. What I am trying to do is stop someone from opening a blank db and importing tables that way. I looked at the getpermissions db and was able to get to the tables by importing them to a blank db. Are there any other ways to secure this db?

    Thanks,
    Mike

  9. #9
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    You could:

    1) Go into Windows Explorer and send a shortcut for your db to your desktop
    2) Rename the shortcut something cryptic/innocuous and change the icon so it doesn't look like an Access DB
    3) Go back into Windows Explorer and set the db's properties and check on the Hidden Attribute

    You now have a way into your db (which you say is password protected) and it will not show if someone creates a blank db and goes into get External data.
    Of course, in order to import data you also have to know the name of the db you want to import it from, which you do but presumably no one else will, you being the secretive kind! And realize, your db can reside in any folder or subfolder, or even subfolder subfolder.
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  10. #10
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926

    Permissions

    You can also try the routine attached but you would need to establish "pre-set" permissions on the mdbname + LoginID.mdb which is created in this routine. It probably won't help in this situation but I thought it might be worth looking at for possibly other ideas (it works for updating code without having the user's close out).

    It's sort of a clone mdb and add user LoginID routine then launch that specific mdb - you just need to change the location, filename, and type (mdb/mde) on 1 line using notepad and save as a vbs, then copy to the user's desktop.

    I like Missingling's idea better though.
    Attached Files Attached Files
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •