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?
Related
So currently my boss and I are the two employees that work on our company's access database. I just got Office 2013 on my computer and he is will working with 2010. We have ran into some inexplicable bugs with the database.
Most of these can be fixed by just copying an old version of a form or report into the database when it fails; however, it is quite disconcerting when we spend hours trying to discover why something is wrong and are able to fix it without explaining why.
Most of the issues so far have occurred when I am using the db in Access 2013. So far the issues have been:
Access occasionally crashes and restarts when I am working in the VB code
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile erro. To further explain the "bugging out", the form usually contains about 2000 separate forms that you can search through, but when it bugs out it will only show one blank form. At first I panicked thinking all the table's data was gone, but nothing changed the table
There have been other hiccups, but nothing noteworthy besides these two
I guess my question is if anyone else has had issues along these lines, or if they knew of any other known issues. I tried to research errors people have been having, but I couldn't find anything besides Microsoft's official release of what features were being deleted.
As always, thanks in advance!
Your system should be split into two files. FE(front end) containing all forms, queries, code, etc., linked to the BE. BE(back end) containing the data tables only.
Maintain a development copy of the FE that is only used for making modifications.
Each user should have their own copy of the FE on their local machine. If you don't know how to split, just search for it as there are plenty of instructions out there.
I have 2010, but I worked with a consultant who worked on the same project in 2013. I too, saw some behavior that looked like version related bugs, but nothing definite.
Responding to your list:
Access occasionally crashes and restarts when I am working in the VB code -- This has happened to me in every version of Access I have used, from 97 to 2010.
Some forms bug out for no reason. It yet again occurs when I am working in the VB code if there is a compile error... -- If the compile error is severe enough to lose project state, this is not surprising.
Recommendations:
Decompile your application front-end occasionally, especially when 'weird' errors show up. See this SO link: automating decompile / recompile in ms-access
Compact & Repair at least daily while developing your application
Backup! Do this at least for every significant revision. Sometimes, the Access front-end will become so corrupt that it trashes all of your work. When this happens, nothing is recoverable.
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 a MS Access 2010 DB with bunch of forms,queries ,macros, Reports etc
The data for my report comes from ODBC links to SQL Server 2000 Tables via linked table property.
Now, whenever i goto design mode of a report,Everything moves painfully slow (I have to wait atleast half a minute for every mouse click,or to select a text box , or any operation performed on the report)
The report itself takes about a minute to run.Which i dont mind.
All I am looking for, is a quicker way to make changes to the design of reports.
This is an old question, but I had a similar issue with form design running extremely slowly recently. For me, only one form seemed to be affected (all others ran fine in design mode). The record source for the form was a complex query built on a hierarchy of subqueries. I dumped the query results into a table and used the table as the record source for the form instead of the query. This appears to have resolved the issue. Hope this helps someone else.
I found the main cause to be the Access conversion program that converted 2003 format to 2010. If you create a new .accdb and then import all of your object, it should work OK. I definitely fixed my issues
What worked for me is based on the answer provided by Albert Kallal at http://www.utteraccess.com/forum/lofiversion/index.php/t1959800.html.
For me, in my split database, if I open any table that is linked to the backend then opening any frontend form or subform was very quick. If I do not have open and keep open a linked table, then it takes about 20 seconds to switch from Form View to Design View and another 20 seconds to open a subform, etc. When I have a linked table open (it does not matter which table, just any table linked to the backend), then it takes about 1 second to do any of those functions. Huge difference!
That is not normal. Something is wrong. Could be your Office/Access installation, your OS installation, something taking up too much of the system CPU, or your system just not having resources, like memory, to properly run Access. Or that your DB is corrupted and/or bloated.
Two tests you can try.
First, do a compact/repair on the DB and see if that fixes it.
Second, is to start your computer in Safe Mode and see if Access still runs slow. This will test for much of the above issues.
What worked for me was to change the subdatasheet name from 'auto' to 'none' on all local tables. Do this in the property sheet in table design mode. There are routines posted elsewhere that will find all your local tables and change this value.
A table was linked to an Excel file. I found that when the Excel file was open, it took forever to change to design view on ANY form. Closing the Excel file eliminated my problem!
My case is access work fine in every function except opening or designing report. But access can work fine when network disconnect. I found it's cause by printer share by other computer and the computer which was removed. I remove the printer from control panel and access can work smoothly.
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?
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.