Results 1 to 13 of 13
  1. #1
    Join Date
    Sep 2007
    Posts
    14

    Unanswered: Access mdb file copy protection

    Hi,

    I've got an access .mdb file saved on a shared server. Several users work with this .mdb file.

    I would like to prevent this file from being copied / saved on another location (except for periodical backup). I don't know how to do that...

    Any idea?

    Thanks a lot in advance,

    deloffa5

  2. #2
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    The only way I can think of is you use a vb script to launch the mdb file (i.e. http://www.dbforums.com/showpost.php...6&postcount=19) and the actual *.mdb file is put somewhere where no one could find it (perhaps in a hidden folder with limited access.) Have the cloned files also created in the hidden folder. You don't even need to utilize the cloning part.

    Thus, the user's only have access to the vb script to launch the *.mdb file. You also may want to make an *.mde file for added security so no one can edit the code like they can with an *.mdb file.
    Last edited by pkstormy; 10-23-07 at 17:27.
    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
    Chicago, IL
    Posts
    1,312
    Another thought is to have the database check its location using CurrentProject.Path or CurrentProject.Fullname and if the file has been moved then close the application with Application.Quit.

    You will need to put the code in a macro called AutoExec or in a form that is called in the Startup parameters.

  4. #4
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Here's an example of DCKunkle's idea:

    Dim DP As Variant
    Set DP = CurrentDb
    If DP.Name = "H:\PH\PH Nursing\Resources for Nurses\Communicable Disease\EpilogUsers\EpilogSQL.mdb" Then
    msgbox "You are in the original source"
    else
    msgbox "You are not in the original source"
    end if
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  5. #5
    Join Date
    Sep 2007
    Posts
    14
    Thanks for the idea, that works perfectly.

    deloffa5

  6. #6
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Out of curiosity...Which one? The vb script method or the dp.name example? (Note: I really should have used the UNC name in the dp.name example.)
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  7. #7
    Join Date
    Sep 2007
    Posts
    14
    The dp.name example.

    Moreover, to enhance the security, I've hidden the database's parent folder, and restricted its ownership rights to the administrator.

    deloffa5

  8. #8
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    If you're going to use DC's idea (which is a good one btw!) then make sure you are aware that any user can hold down the shift key and bypass your autoExec macro.
    George
    Home | Blog

  9. #9
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Personally, I'd rather just have a vb script in the folder which launches a hidden mdb file somewhere else where the user doesn't know where it is. If you can't see the mdb file in the folder (and don't know where it is), you can't copy it.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  10. #10
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    I use batch files instead of vbs files, but that's just personal choice.
    Either way, users can follow a shortcut to it's destination easily enough (not to mention anyone with a text editor can edit and view the source of a batch file or vbs file. No method is infallible.

    Whatever you chose, make sure you lock down the folder containing the access project and even password the VBA within. All these things help your average user to give up quickly, but if someone with enough knowledge persists then you can be damn sure they'll get something.
    George
    Home | Blog

  11. #11
    Join Date
    Sep 2007
    Posts
    14
    I've just realized that.

    Moreover, I've also realized that Ctr+Brk is also a big problem. I've tried to uncheck the "Use Access Special Keys" checkbox in Tools/Startup, but that doesn't help much, as the user can either
    - check this checkbox and use Ctrl+Brk
    - use Ctrl+Brk before clicking "OK" on the "Security Warning - This file may not be safe (...)" MsgBox.

    So, I'll have to try the other method.

    Thanks for all your comments.

    deloffa5

    Quote Originally Posted by georgev
    If you're going to use DC's idea (which is a good one btw!) then make sure you are aware that any user can hold down the shift key and bypass your autoExec macro.

  12. #12
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    The things I do:

    - To prevent others from editing the vbs script, I edit the properties - security of the file and set permissions on it. Sometimes I will instead create a visual basic *.exe file as a launch file which no one can edit unless they have access to the source code (creating a vb *.exe file is nice when I want to create a menu for users and very secure to prevent users from seeing any file locations or editing any code - but you do need visual basic.)

    - To keep others from seeing the code in the mdb file, I make an mde file. I keep the mdb safely in a user non-accessible drive. The mde file is then put in a "secret" location which is launched via the vb script (or *.exe file). Users must have permissions to the folder the mde is located and be able to write to it (so an ldb file can be created) but keeping it in a hidden folder makes it difficult for them to find it.

    - I DON'T use the disabling the shift key in code as I found a way to by-pass even this and I don't want to make it more difficult for me to edit the code. Although there have been a few rare occasions where I have used this method. Users holding the shift key down while opening the mdb/mde file is always a problem but I've found the only users who do this are users which are intent on getting behind the scenes (and somewhat experienced Access users) and try to do everything they can. These, in my opinion, are not users but hackers who are intentionally trying to do something against the program's data. Typical users do not know the holding the shift key trick. But if a user is getting behind the scenes and editing data directly in the tables, I can usually find these culprits sooner or later. Properly monitoring data is (or should be) part of our jobs.

    - I also make sure my code doesn't allow the user to easily by-pass any forms and get to the tables. There are several, several different (easy) ways to do this. Again, making an mde file keeps them from getting into any modifying the code. But simple things like changing the "Shortcut Menu" properties to false for the form properties, making it a modal, popup and removing the X close from the caption, etc...etc... can easily be done. Here's one quick example: http://www.dbforums.com/showpost.php...0&postcount=20. Also see the module2 example in the code bank which allows you to remove all Access background information.

    - I may or may not use Access security. I have found ways to break a secured mdb file with an mdw so depending on the situation, I may or may not utilize this.

    - Since I mostly use SQL Server linked tables, security to the tables is maintained via SQL Server.

    - And lastly, track the loginID of who entered data in all main data tables (and the date the record was entered.)
    Last edited by pkstormy; 10-25-07 at 11:13.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  13. #13
    Join Date
    Feb 2004
    Location
    New Zealand
    Posts
    1,424
    Provided Answers: 8
    Good points Paul

    When I link Tables I use the \\server\data$\databasetablesname.mdb

    also on the Backend database

    I have a autoexec macro the close the database

    Yes the Shift is a problem I been in access from verson 2 and as john say it the one who know msaccess will get in

    With a bit of work you can make a MSaccess database not look like Msacess

    put a bitmap image of the same name in the folder with the mdb
    and that will come the splash screen.
    use =1 in the Menu properies it will hide the file -> edit -> View
    in the startup options you can put a icon and retitle the application.
    all ways title your msgbox's
    Last edited by myle; 10-25-07 at 15:18.
    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.

Posting Permissions

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