Results 1 to 12 of 12
  1. #1
    Join Date
    Feb 2013
    Posts
    99

    Unanswered: Multiple users cannot access forms in Shared Database

    Have been trying to find a resolution to the following issue

    I have a Shared 2010 access Database, which is split into front end and backend as per recommendations from several recommendations on the web.

    The database can be opened by multiple users to a navigation form. When multiple users try to open the same form from a button to input data which is just a simple Vba docmd.open etc an error occurs an this is changeable sometimes 2044 or 2015 or 3044.

    1 user can be filling in a form then another user can logon and then restict the forst user and them selves from activating any of the buttons and vba scripting

    Should say This will always be a new record never an edit to an existing record

    I have shared the Database under File>Options>User Settings>Advanced>Shared

    Default Record Settings are set to "No Locks"

    I have tried unchecking the "Open Database by using record Locking"

    Also Tried changing the Encryption Method to "Use Legacy Encryption"

    I also noted that when the database is being opened a .laccdb file is being created "Microsoft Access Record Locking Information"

    Could this be the issue and if so how do I diasble it

    Thanks

  2. #2
    Join Date
    Feb 2013
    Posts
    99

    Added Information

    Should Say the Front End resides on a network drive for all users to access

  3. #3
    Join Date
    Feb 2013
    Posts
    99

    Resolved

    Looking through the forum found a entry from Missling which said not to put the Front end on to a network drive but to put the database onto the users PC and it all worked. The Backend tables updated correctly and there was no further problems.

    Writing this it was possible to do with I was putting the backend onto my local pc and I was not sharing the drive, Sometimes I woder what I am thinking

    Will try that a bit later

  4. #4
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    As you've discovered, each user has to have their own copy of the Front End on their machine!

    ...Sometimes I woder what I am thinking...
    It's called 'learning!'

    Glad you got it fixed!

    Linq ;0)>
    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
    Jul 2013
    Posts
    46
    As a suggestion make a link to the source front end for each desktop. That way if you make a change to the source front end all will have the same version.

  6. #6
    Join Date
    May 2003
    Location
    Dallas
    Posts
    817
    Provided Answers: 5
    what i do to make sure that people use the same front-end and the most recent I distribute, is I have a table in the backend called tblCheck_version and I set the properties to hidden.
    In that table is a field called valversion it's attribute is text
    it has one row and the data in that row is whatever i want it to be - say like "Test"

    On the frontend I have another hidden table called tblFe_Check_version
    it also has a field called valversion. In that filed and row I type a value before distributing.

    Then prior to distribution - I change the BE field value to say "test3" - this will not affect the users presently in the system

    I also change the value in tblFE_Check_version in the new frontend to "test3"

    On the startup of the front end I get the values of both tables - if they do not match I put up a MsgBox saying wrong version contact System Admin and quit the app.

    So people that have not changed versions know to get the latest Front end from me or read the email I sent and download it. It is a simple way to control user versioning but it works

    also for those users that never close their front end and think they can skirt the issue - on the activate event of the main form run the same version check that you do on start up - that will fire within minutes of using the old application after you change the value in the backend table.
    Dale Houston, TX

  7. #7
    Join Date
    Jul 2013
    Posts
    46
    The Front End should only contain forms. The Back End is where the Tables are and the data is stored.

  8. #8
    Join Date
    May 2003
    Location
    Dallas
    Posts
    817
    Provided Answers: 5
    well in defense of tables in the front end - if they are temp tables used to warehouse data that is being posted or moved to other tables and you are in a mult-user environment then local tables are the solution for this scenario - in SQL it is handled with create tables based on the login name or NT username - but in acccess it is easier to just use temp tables to move data to areas for warehousing or inventory control and then update the results from those tables to the backend. but for data accessability , security and user access - yes all of those tables go on the back end.
    Dale Houston, TX

  9. #9
    Join Date
    Jul 2013
    Posts
    46
    I am a novice at this but to me it seems it's best to keep things simple so the database operates smoothly. That being said I wish you all the best.

    Have a good one,
    Bill

  10. #10
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Quote Originally Posted by billgyrotech View Post

    ...make a link to the source front end for each desktop. That way if you make a change to the source front end all will have the same version...
    Absolutely not! Having multiple users sharing a single Front End , sitting on a network drive is a sure way to repeated episodes of corruption, speed and timing problems, and all manner of strange, odd and curious behavior! Multiple users simply have to work off of a split database, with each user having their own copy of the Front End on their respective hard drives
    Quote Originally Posted by billgyrotech View Post

    ...The Front End should only contain forms...
    The Front End, in addition to Forms and, as mentioned by axsprog, temporary Tables (in some cases) would also hold Queries, Modules and Macros.

    Linq ;0)>
    Hope this helps!

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

    All posts/responses based on Access 2003/2007

  11. #11
    Join Date
    Feb 2004
    Location
    New Zealand
    Posts
    1,424
    Provided Answers: 8
    Hay what i do

    Link the front end by \\servername\databasefolder\database.mdb make this a hidden folder but everybody has read/write

    Create a folder on c:\screens

    Put the front end in there create a short on desktop pointing to the screen folder
    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.

  12. #12
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    isn't there soem code written by PKStormy (?) that checks the local front end is uptodate, and if not copies a new front end over the locla version?
    I'd rather be riding on the Tiger 800 or the Norton

Posting Permissions

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