I am using MS Access 10 in a multi-user environment. The DB is split with tables in the back end (stored on a network drive), and everything else in the front-end (stored on about five different computers).
Some of the front-end computers are using Access 07, but the DBs were created in the 07 format. I have checked that the database is NOT using the 2010 encryption, and all the other 10 settings that are not compatible with 07. In fact, the 07 computers will run the DB just fine when alone... the problem is when more than one person logs into the DB.
Often there is a "Too Many Active Users" error when trying to sign in. Other times, users are able to log-in and open forms, but whenever changes are made we get "locked" errors. (This happens on all computers, not just the ones running 07).
All the DB copies have record-level locking, but it behaves as if it is locking the entire table. I have checked, and none open the DB in "exclusive" mode. (When you go to the navigation pane, and open the table, the table itself will not allow new entries).
I have tried creating the forms based on queries and also with filters instead. I get the same locking problems either way (Does anyone know if queries or filters lock data differently?).
This is forcing the DB to be used by one user at a time, when multiple people need access. Is there anything I am overlooking? All have permissions set to the network drive, I removed the "compact on close", I tried converting to an ACCDE file (the ACCDE file will not open in 07, only 10, but we get the same locking errors).
Can anyone think of what I might be missing here?
Related
I have an Access 2013 database that is stored on a remote computer. I do not have it set in a back-end/front-end setup. I have a SharePoint 2010 list linked to it as a linked table. I have 2 users that need to have access to the database at all times, others may need in it at a later date. When I link the table, only 1 user can be in the database at a time. Prior to adding the linked table, all users were able to use the database simultaneously. Now, after the first person gets into the database, subsequent users get the message:
The database has been placed in a state by user 'Admin' on machine '[computername]' that prevents it from being opened or locked.
For testing purposes, I tried creating a blank database that is connecting to that same table and tried to open it from another computer. I received the same error and all that is in there are the 3 tables needed for the SharePoint list.
Is there anything I can do to be able to have multiple users in my database again? I have full control to make changes as needed to the database, but I have no access to be able to change anything server side on SharePoint.
This is because of the 2010 SharePoint caching format.
You can avoid this behavior by going to Options -> Current database -> Caching Web Service and SharePoint tables, and untick Use the cache format that's compatible with Access 2010 or later.
Note that the different cache formats come with different features. The old (XML-based) cache format supports multiple users, the new (table-based) one doesn't. The old cache format can be taken offline manually and needs to be synchronized manually if offline, the new one automatically goes offline if SharePoint is unavailable and synchronizes automatically as soon as SharePoint becomes available. The new one supports adding fields in table view, the old one doesn't.
Through VBA you can mix caching formats for different lists, but that's generally not recommended.
We have a database with a fairly large table (300+k rows) that needs to be shared by a very small group of people (less than 5).
We previously attempted to have the table shared through Access Web Database (SharePoint 2010, so this was using SharePoint lists), but this quickly became a nightmare scenario as our morning process to load a daily inventory report into this table ran for 3+ hours using SharePoint once the inventory became significantly high. We have reverted to sharing the reports database across a network share, and the person who needs this inventory data for a different job function uses a separate front-end.
The issue we have is that when the one guy has his separate front-end open, which links to one table in the reports database, no one else can connect to the reports database; not even for read-only access.
What can be done to allow proper multi-user access? I've checked every record locking property I can think of, and still can't make anything work.
(I have to say that there are no viable alternatives to this setup. Even though we recently upgraded to SharePoint 2016 / Office 365, IT refuses to upgrade Access Web Services; so we won't have any access to SQL server, period.)
The report property sheet has a setting to lock, or not lock the table. simply change that setting, and other users can then edit data, or view the report.
I have several clients that I make databases for, all are pretty similar... They all have a screen with current data displayed. This screen/pc combo also sends some emails, uploads data, etc... usually without problems... however, one client keeps getting an 2004 (Not enough memory) and 3035 (system resources exceeded). I have tracked the memory usage on the device and it hasn't gone about 50%. I ran a memory test and no errors were found.
Today, I notice the error and was able to try a few things. With Access open, I could not open or design view any forms. Some queries I could get to open to SQL, but not design view. Crosstab queries would not open in design or SQL. Neither would open and show any data.
These errors are usually logged, and I will get several 2004s in a row, then it will switch to several 3035s, then eventually it will just quit altogether. Closing Access and reopening will always fix it (for a while).
I have decompiled and recompiled. I have tried accdb and accde versions. This is Access 2007. What should I try next?
Can't add as comment, but one thing to try would be to check the service pack level for Access, the latest for Office 2007 is SP3.
Also, if the issue is with multiple forms, then it could indicate database corruption rather than issues with individual forms. Have you tried to import all objects into a brand new container and run it from that?
The Problem
I have been encountering a problem with MSAccess 2007, with a 2003 format database.
When I try to run the query (for example a select query), I get the message "The Microsoft Office Access database engine cannot open or write to the file "query name". It is already opened exclusively by another user or you need permission to view and write its data".
In addition, I cannot view the query in design view, only in SQL view. This only happens for certain queries, which I was previously able to design and change with no issues.
What I have tried
I have tried Repairing and Compacting, and that does not fix the problem. The only way I have been able to fix so far is by importing all the objects into a new database, which has resolved the problem for a while, then a few days later the same issue happens again.
If you are in a multi-user environment, and the back end database is on a share drive, this will happen when someone else opens the back end database directly from the shared drive instead of using the local front end database. If the back end database is opened directly from the shared drive, other users will be unable to use the front end database due to locking issues.
I have an Access 2007 application (previously in Access 2003) that is running into some performance issues when the linked database tables are on a network drive. In 2003 the application worked perfectly fine. Now in 2007 the speed of data retrieval using sql and a recordset is degraded pretty poorly. The exact area that i am encountering the issue is on:
DIM rs AS NEW ADODB.RECORDSET
rs.Open tsSql, CurrentProject.AccessConnection, iKeyset, iLock
The iKeyset is set to 0 and iLock is set to 3
the rs.Open command is taking from 4 - 5 seconds which is an issue due to the fact that on some of my forms this can happen multiple times on load.
any thoughts?
EDIT: not to mention that I believe that opening and saving forms in design view appears to be slower than normal under these circumstances.
Depending on the SQL statement involved (i.e., your variable 'tsSQL' above) , your recordset should open instantly whether ADO or DAO.
Ideas that come to my mind: is your connection persistent? This seems to cause more of a delay in 2007 than in 2003. Maybe it's dropping and re-establishing the connection each time. With forms this happens when your recordsource is blank and set in code, so one is advised to always have a recordsource such as "tblBlankTable" (a small one-record table just to keep the connection alive all the time in a form that is always open). The 4 to 5 second delay is about what you get when this is not in place. Try making sure you have a form connected to your DB all the time when running your rs.open and see if that works. Possibly you might need a form with an ADO connection open in your case. Lots written out there on Access forums about this.
Is it faster when you are the only user versus when others have the DB with a lock file open? That is the tell-tale sign.
Another idea is whether you indexed everything correctly when you upgraded. Did the underlying DB stay the same or get upsized from MDB to ACCDB? You didn't indicate what is in the tSQL, so maybe you are joining on non-indexed fields or something that is causing that particular tSQL to run slowly and just need to add a primary key.
If your 'tsSQL' involves queries, I've read that when upgrading it is important to recompile all your queries -- go into design mode with each one, then run them, then save them again.
You could try connecting to the DB with your own connection string -- there is one format for MDB/Jet and another for ACCDB/Ace. There are providers for both that one usually uses from Excel to MDB or ACCDB, but maybe could work within Access, at least to debug your problem.
There is a hotfix Description of the Access 2007 hotfix package (Access.msp): August 26, 2008 that mention performance issues however this is very likely included in Access 2007 SP2. Click the Office button >> Access options (lower right hand corner) >> Resources tab and see what the section titled about Microsoft Office Access 2007 shows. Mine states 12.0.6535.5005).