Page 1 of 2 12 LastLast
Results 1 to 15 of 23
  1. #1
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185

    Question Unanswered: file already in use. (Error 3045)

    Hi folks,
    I recently finished my db for DCC control in 2007 edition and put the Back-end file in a folder in the server and put the front-end files on users computers, the server folder is read only for all users and is r/rw for the administrator.
    When admin opens the db the users get the error 3045???
    I looked in the Old posts and tried few solutions but still the problem persists
    as far as I know if I change the permission of the back-end file folder to r/rw for all users then it will work but this will afect the security of back-end file and make it possible to be deleted or replaced by another file.
    Last edited by Aran1; 04-14-08 at 08:46.

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    priobably because you need to allow your users read/write access.. access alwasy does soemhtign to its own files when you sue them

    change the permissions on the server

    im guessing its a crappy error message..... what it means is file is locked, rather than file is already in use

  3. #3
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185
    I know its because of folder permission which is read only but I dont want to change the permission to read/write for security reason, I need a better solution.

  4. #4
    Join Date
    Apr 2004
    Location
    metro Detroit
    Posts
    634
    Are your users just viewing data or do they need to enter/change data as well?

  5. #5
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185
    only admin changes the data which has r/rw access to back-end folder, other users just read the data

  6. #6
    Join Date
    Apr 2004
    Location
    metro Detroit
    Posts
    634
    You could either have the admin push the data out to the front end(s) after update, or have the front end connect to the back end with a different user name to refresh the data. It depends on how often the data gets updated.

  7. #7
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185
    I think you mean the admin use edit forms as Unbound form and communicate each time it need to update data, this will solve the problem as the users forms are unbound forms already but the chalenge is to solve the problem without using unbound forms, I mean somehow else Access should have an option to overcome this problem

  8. #8
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Using access built in security perhaps..?
    George
    Home | Blog

  9. #9
    Join Date
    Apr 2004
    Location
    metro Detroit
    Posts
    634
    Are your users able to open the file when admin does not have the file open?

  10. #10
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185
    Yes cuz they use unbound forms which open the file for just a glace each time they get a report

  11. #11
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Regardless of where the mdb (or mde) is located, the user MUST have read/write permissions to that mdb/mde file and that folder (Access always needs the ability to create an ldb file - backend as well as frontend.) Lack of permissions to that folder will most likely result in a hanging ldb file and the need to compact/repair the mdb. You are correct in that Microsoft should find a way to utilize folder permissions with Access (hopefully Microsoft will consider that in future versions of Access.)

    Consider as georgev stated, using Access built-in security (regardless if you're using unbound forms or not - that's not a factor.) Although a little difficult to learn and initially setup, MSAccess security is pretty secure.

    I think you're misunderstanding the use and intention of unbound forms though. User's ability to open and view a report because an admin person is not in an mdb is not due to utilizing unbound forms. It would have to do with the admin (or another user) opening the mdb exclusively (not shared) (which is a setting in the Tools -> Options, Advanced tab) or code in the mdb somewhere which sets the mdb to open exclusively.

    To help with your specific error 3045 though, see this article: http://support.microsoft.com/kb/94035 (even though it references Access 97) but you should check your code in the mdb which is most likely the culprit.

    This article is interesting reading: http://support.microsoft.com/kb/247180 (even though it is talking about the same user opening the same mdb twice.)

    Lastly, I'm not a fan of putting front-end on each user's computer. It just makes it more difficult to keep each user's frontend updated and since you're already using unbound forms (which is utilized and ideal for multiple users in the same frontend mdb), it is unnecessary. Consider that UserX turned off their computer and you can't update their code or the need to put in "checking" code to see if the user has the latest code changes every time they open the mdb (which I'm not a fan of). I'd personally keep the front-end on the server with the backend, give all users who use the mdb read/write permissions to the folder and mdb files (front and backend), and impliment Access security. I also use a cloning script (I know, I keep advocating this script), but it works so nicely by always cloning the source mdb (which I keep in a safe place) and users are never opening the source mdb so it's always safe, hidden, never corrupt or bloated, and I can copy new code changes without having users close the mdb (http://www.dbforums.com/showpost.php...&postcount=19). It also has many other benefits, is so easy to implement, and will sincerely make your life easier (it is a vb script with 4 lines of code that you simply edit with notepad and you only need to change the 1 line of the UNC location in the script to point to where your mdb/mde is located.) Then simply email or put the script as a shortcut on the user's desktop and just have them click on the script to get into the mdb/mde. Wouldn't it also be nice to always know who is in the frontend or know when was the last time the user opened the frontend? See the thread link to the script for more info.

    Anyway, I hope the above link for error 3045 helps solve your issue.
    Last edited by pkstormy; 04-14-08 at 20:23.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  12. #12
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    You are correct in that Microsoft should find a way to utilize folder permissions with Access (hopefully Microsoft will consider that in future versions of Access.)
    Don't hold your breath. Access security was removed in 2007, not improved. Seems they don't give a hoot about security in regards to Access.

    (it is a vb script with 4 lines of code that you simply edit with notepad and you only need to change the 1 line of the UNC location in the script to point to where your mdb/mde is located.)
    Can I have a copy of that one? The cloning launcher I have has 15 lines of code
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  13. #13
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    You bet StarTrekker. I attached the zipped script without all the comments. (I was wrong - there's a few more lines than just 4 but you can easily follow along through them.) Just edit the .vbs file with notepad (when saving, make sure to change the File type to All files and add .vbs to the end of the name of the file you save it as.) You may want to call it the same as your mdb name. You should see the distorted green $ (scroll-type) icon for the vb script (which you can change to better represent your app).

    When editing, you'll need to change the 3rd or 4th line which points to where your mdb/mde is located (preferable use a UNC name). If you don't get the name correct, no biggie (you just won't see the cloned file after it's run) and just redo it until you enter the correct location/filename in the script.

    A few lines under that, comment out 1 of the NewName = .... lines depending if using mde or mdb (cloning an mdb is currently commented out).

    Then save it to the same folder your mdb/mde is located and run the script. You'll immediately notice that instead of just an: MyAppName.mdb, you'll also have an MyAppNameStarTrekker.mdb which is the one you're in and a MyAppNameStarTrekker.ldb meaning you have it open (it uses the getuser loginID to add to the source name). Have some other users run the script to get a better picture on being able to tell who's in the app and when they last got into it (send the script to their desktop as a shortcut so they can always run it from there.) Then look in the folder at the file creation date of their cloned filename and notice that you can tell when they are in the mdb and when they close out of it (by seeing if their ldb file exists.) Also try corrupting the user's cloned copy so you can't open it. Have them run the script again and notice that since it copied from the source mdb over the top of the user's cloned mdb, the user's cloned copy is no longer corrupt and launches right away. A 30meg mdb should take less than 1 second to clone and open (the opening part depending on other code you have running when it opens though.) I don't let users get into the mdb directly but instead, have them launch getting into it always via the script. I have some code in the source mdb which checks to see if the source mdb is being opened and if it is, it displays a messagebox, closes the mdb, and will then execute the script for the user.

    You can email the vb script out in as an attachment and have the user unzip that to their desktop (or again, just create a shortcut to vb script on the user's desktop.) I like to keep the vb script in the same folder as the mdb and then put shortcuts on the user's desktop to the vb script file. For some reason if you send it out as a vbscript file and the user saves that to their desktop and they change the icon, it makes the vb script non-usuable. But a shortcut to the vb script file can be changed with a new icon without any problems.

    Again, please let me know how it works for you and if you do or don't like it (be honest). It does so many nice things for me that I wouldn't be without it. After you try a few out, it'll become second-nature on quickly creating new ones for your other mdb's.

    Additionally, you can get fancy and clone a source mdb file from a "hidden" folder to a "working" folder (or even to their desktop if you so wish.) But the source mdb will always stay safe, hidden, and never gets corrupted and you can copy new source mdb code at any time and then simply send the user an email telling them to just close and reopen again (using the vb script to always get in.) I will usually also list out the changes I made in the email to the user.

    As a Note: any tables linked into the source mdb are also linked correctly in the cloned mdb so you don't need to worry about that. You can really carry this technique further by cloning other startup programs (not just Access files) or add message/question boxes to the script if you like.) If you like this, I've got another vb script which automatically creates ODBC DSN's by running them. And another which opens recordsets in the db and will set flags or write data and close the recordset.

    I use these scripts to write to a table and set a "loggedIn" field to true when the user logs into windows (I then don't need to open Access to do it.) and also a script to make the "loggedOut" flag in the table to true when they logoff of windows. I had the network guys add these scripts to the other logon/logoff scripts that are executed when a user logs in/out of windows. It worked very nice for a who's in/out type of mdb program. User's open the mdb file and immediately see who's all in the office and who's all out of the office (providing they log on when they first get in the office.) We then trashed our sign-in/out board since users rarely kept that up-to-date and prefered simply opening the mdb to see if someone was in the office.

    I sincerely apologize I got so in-depth here and wrote a small book on using it. It's really not as complicated as all the stuff I wrote but I do get excited about all the things you can do with vb scripts.
    Attached Files Attached Files
    Last edited by pkstormy; 04-15-08 at 02:53.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  14. #14
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185
    Dear pkstormy,
    I started using ur vb script file and I like it, I already had to produce copies of front-end files and install it on user computers one by one each time I had to make change in my db, also I can see the logged on users as well.
    Additionally, you can get fancy and clone a source mdb file from a "hidden" folder to a "working" folder (or even to their desktop if you so wish.) But the source mdb will always stay safe, hidden, and never gets corrupted
    the only problem in this script (not real problem) is if users open the script file in edit mode they can see the address of db so it can be detectable in my point of view, if you do something else to solve this, please let me know.
    also tell me for directory with space in its name which character should be used exactly for space for example: "DCC Database"?
    I need the script file make a new directory in one of drives and put the clone file there for the first time and every time the script being run check for directory and put the new clone file there, I tried MkDir but not working, is it possible???
    At the end thanks to you for nice informations and I'm going to use this script in future.
    If you can share more usefull files like this, I think everbody appreciate it.
    Last edited by Aran1; 04-15-08 at 04:53.

  15. #15
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    I have some code in the source mdb which checks to see if the source mdb is being opened and if it is, it displays a messagebox, closes the mdb, and will then execute the script for the user.
    Good idea. I'll have to work on that one.

    If you like this, I've got another vb script which automatically creates ODBC DSN's by running them. And another which opens recordsets in the db and will set flags or write data and close the recordset.
    Awesome I'm sold on the idea tbh and I'd appreciate other VB scripts so I can start to learn what can and can't be done (and how) in .VBS files.

    And it's fine PK, I read your book and enjoyed it

    also tell me for directory with space in its name which character should be used exactly for space for example: "DCC Database"?
    See this: http://www.dbforums.com/showthread.p...68#post6333068

    Use the Chr(34) to encompass names like I have suggested in that post. It copes with the spaces. The Chr(34) is a " character.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

Posting Permissions

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