Results 1 to 7 of 7
  1. #1
    Join Date
    Dec 2003
    Location
    Oklahoma
    Posts
    17

    Smile Unanswered: Final steps before the user...

    After I have completed all the programming, what are the best steps to take to prepare for a user? I do not need extreme protection, but I want to insure that they cannot get into design mode for anything, while I do want them to have access to menus that have Find/Filter, etc. I have looked at the Startup options, but cannot quite tell what the Menu-related commands do (even locked myself once with those!)

    I appreciate any help. This will be the first database I have put in a user's hands.

  2. #2
    Join Date
    Feb 2004
    Location
    Canada
    Posts
    133
    Probably the best way is to make an .mde file for the users to use. Just make sure you keep the .mdb file so you can make future changes to the design. You might also want to use the database splitter to split it into a front end/back end so you can make changes to the forms, queries, reports, etc. without affecting the data.

  3. #3
    Join Date
    Dec 2003
    Location
    Oklahoma
    Posts
    17
    Well, I am not sure how to do either of those, but it makes sense. I will check it out. I would like to have separate data files, anyway, so I am definitely interested in that.

    Thank you!

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

    Making an mde

    bmacr is right - the best way to protect your code is to make an mde file. Tools - Database Utilities - Make MDE file. Make sure your code is debugged first. If it's grayed out, you'll need to convert the database first. Keep in mind also that if you're using Access tables, when you make a new mde, you'll need to copy the old mde tables to the new one (or to your source mdb file before you make the mde.) You can split the database like bmacr suggested to prevent having to copy the tables each time you want to make an mde. Another good thing to do is to have an Admin table (see the posts on getting the users loginID or the code below) and have some code which tests to see if that user's loginID is in an Admin table you create. If so, you can let them do certain things which you don't want other users to do. An example is like this below (in a module):

    Function IsAdmin() as boolean
    Dim wshNetwork As Object
    Dim strLogin as string
    Set wshNetwork = CreateObject("wscript.network")
    strLogin = wshNetwork.userName
    dim rs as adodb.recordset
    dim strSQL as string
    set rs = new adodb.recordset
    strSQL = "Select * from Admin where LoginID = '" & strLogin & "'"
    rs.open strSQL,currentproject.connection,adopenkeyset, adlockreadonly
    if rs.eof and rs.bof then
    IsAdmin = false
    else
    IsAdmin = true
    end if
    rs.close
    set rs = nothing
    End function

    (People you want to have admin rights would have their LoginID in the Admin table which would have a field called LoginID.)

    Then for example you could have a button on a form with code in the OnClick Event like:
    If isAdmin() = true then
    'let user close form
    docmd.close
    else
    msgbox("you do not have admin rights.")
    end if
    Last edited by pkstormy; 02-20-05 at 16:34.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    If you want to protect your code then making a MDE is the most effective way, short of messing about with security and changing permissions on all code objects. Unless you are fairly experienced at granting permissions I wouldn't reccommend. However making a MDE comes at a price

    1) you can only make a MDE if the database format is the SAME as the version of access you are using. So if you have a mixed environment (say soem Access 2000, 2002, XP etc.... then you can only make the MDE on the lowesst common denominator (ie Access 2000). If it isn't then the option will be grayed out

    2) all your VBA modules should have error trapping / handling. Not every function needs an on error goto handler, however it helps. If you are certain that you have handled the error gracefully then it shouldn't be a problem.

    3)if you do make a MDE make sure you keep copies of your MDB. sounds dumb, but if you deploy an MDE version and you loose your MDB then your are stuffed with a capital F. You cannot get the design code back out of a MDE.

  6. #6
    Join Date
    Dec 2003
    Location
    Oklahoma
    Posts
    17
    Thanks for the replies. I am going to try those and see if I cam make it work. It sounds reasonable and exactly like what I want to do.

    Wayne

  7. #7
    Join Date
    Oct 2003
    Location
    London
    Posts
    341
    Hey guys,

    your suggestions are also helping me in this respect. I have never understood the permissions passwords and etc so I made do with a disable and enable bypass user code in the database - keeping the db window closed.

    Can someone explain what the database splitter is?

    I'm constantly making implementations to my safe database then having to copy over all the tables when I update the working one to keep the data accurate.
    ------

    just tested the database splitter so ignore my above comment, however, is there anyway to protect users from accessing the backend database?
    Last edited by christyxo; 02-23-05 at 20:07.

Posting Permissions

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