If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Unanswered: Multiple users cannot access forms in Shared Database

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"

Added Information

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

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.

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.

...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

Originally Posted by billgyrotech

...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!

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/A2010VB based on my own environment: vb6 sp5ASP based on my own environment: 5.6VB-NET based on my own environment started 2007SQL-2005 based on my own environment started 2008MYLEYOUR PASSWORD IS JUST LIKE YOUR TOOTHBRUSH DON'T SHARE IT.