Results 1 to 5 of 5
  1. #1
    Join Date
    Jul 2009
    Posts
    32

    Unanswered: Restricting exclusive mode for certain user?

    Short of always being the first to open the DB, how can I restrict access of my DB to just myself? I'm asking because I am rolling out the DB out soon but it's still pretty much in construction and I'll need to tweak here and there without asking everyone to log out.

    I've seen someone "lock" his DB and preventing anyone from opening in exclusive mode. He is now gone, and I couldn't ask how he did it. I found that the .ldb file was linked to his PC and does not go away even after it exits the program, or even when the PC is shut. I'd like to do this for my DB, if that's possible.
    -andi_kan
    Financial guy by trade, software tinkering by hobby

    PC : Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz, 4GB RAM
    Windows 7 Professional 32-bit SP1
    MS Office 2010

  2. #2
    Join Date
    May 2005
    Posts
    1,191
    I'm not sure if you're referring to disabling the admin mode for the user, or shutting them out altogether for certain periods of time, or shutting them out permanently all the time.

    If it's the first, I would look at disabling the shift-bypass based on the user's window's login and a reference user's table.

    If it's the second option, I would create a table with a single record and two fields; a primary key and a boolean field which you can toggle as desired. On startup of the application, check against this table, and if it's toggled to kick out, then execute a "docmd.quit" command. You may also want the user's table with an "fldAdmin" boolean field so you don't accidentally lock yourself out, referencing it similarly to the previous method.

    If it's the last, then do similarly to the previous method excepting that you don't bother to look up the toggle field, just close it down right away.
    Me.Geek = True

  3. #3
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    sorry in my books thats the wrong approach
    you should develop in a separate db, ideally you should deploy the app as two MDB's (ideally two MDE's) one contains the data.. the so called back end, the other contains the queries, forms and reports... the so called front end. that means you have a separate development environment with its own data and frotn end. if you do deploy ans an MDE then you must keep your own copy of the MDB to develop on as mde's do not allow development.

    there is some code in which allows for someone to lock a db to stop other people to open the db. I saw it in the Access Developer Handbook published by Sybex. there is also some code which will display show is using the app the front end.

    I've never deployed code which automatically logs people off.. so far the code that shows who is using the db is enough. a quick ring round the offending machines has always worked for me.
    Last edited by healdem; 12-25-09 at 03:10.
    I'd rather be riding on the Tiger 800 or the Norton

  4. #4
    Join Date
    Jul 2009
    Posts
    32
    Quote Originally Posted by nckdryr View Post
    I'm not sure if you're referring to disabling the admin mode for the user, or shutting them out altogether for certain periods of time, or shutting them out permanently all the time.

    If it's the first, I would look at disabling the shift-bypass based on the user's window's login and a reference user's table.

    If it's the second option, I would create a table with a single record and two fields; a primary key and a boolean field which you can toggle as desired. On startup of the application, check against this table, and if it's toggled to kick out, then execute a "docmd.quit" command. You may also want the user's table with an "fldAdmin" boolean field so you don't accidentally lock yourself out, referencing it similarly to the previous method.

    If it's the last, then do similarly to the previous method excepting that you don't bother to look up the toggle field, just close it down right away.
    Thanks mate, but looks pretty much daunting to my eyes. I'm less worried about any of them using the Shift bypass mode, and I would prefer to keep that option open for myself in case I need to change anything.

    Second, I'm not planning to lock anyone out for "a period of time". Basically, I'm trying to let everyone access the DB freely but in shared mode all the time, never having exclusive privilege (reserved only for me or anyone with the right pass, that is).

    Your second/third method sounds good to me, but I'm a little confused on how to do it. But I wasn't intending to "kick" anyone out of the table, just keep anyone from opening exclusive.
    -andi_kan
    Financial guy by trade, software tinkering by hobby

    PC : Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz, 4GB RAM
    Windows 7 Professional 32-bit SP1
    MS Office 2010

  5. #5
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    If you're looking for a network solution and allowing multiple users into your mdb/mde file, you may want to look at the code bank for the vb cloning script.

    On a network environment, when multiple users are opening an mdb/mde file, eventually one of them will open it and then "leave for lunch" or minimize it for a period of time (or lose their network connection). This will "Lock" the *.ldb file which is written to when new users attempt to open the mdb/mde. A "locked" *.ldb file will give you the "Locked by another user error" and be a constant headache when a user calls you to say they got this error while attempting to open the mdb/mde.

    You can deal with this (by having EVERYONE close out of the mdb/mde file) and then compact/repair the mdb/mde. Or you can use the vb cloning script so everyone is essentially in their own mdb/mde file (but the backend MUST be split so the tables are in another mdb and linked to the frontend).

    There's really no way around an *.ldb file eventually getting locked (it will happen sooner or later in a mult-user environment). Same as if 4-5 users were opening a *.doc file. Hence - the recommendation by MS themselves that you shouldn't have more than 3 users in an mdb/mde (frontend or backend.) Your safest bet is to split the mdb to a front-end/backend. That way it's easist for coding changes to copy new code (you don't have to worry about transferring data to copy a new mdb.)

    Look on page 2 of the code bank for the vb cloning script if you're interested in the script. I use it all the time and have never gotten the "locked by another user" error.

    I personally don't like the "bypass shift-key" method. Too time-consuming to get in and make quick changes. An mde file (frontend) is the easiest. I simply make my coding changes in the mdb file, create a new mde file, and then copy it to the "users" folder for them to use (opened by the vb script.)

    If you want someone to open the mdb in "Exclusive" mode, you'll need to deal with other users trying to open the same mdb. I might recommend a second mdb/mde for the users and one for the "special" person. Otherwise I usually control permissions (read/write to forms) within the mdb itself. If you're interested, this code is also in the code bank (last or 2nd to last page.)
    Last edited by pkstormy; 12-25-09 at 21:43.
    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
  •