I am debugging a Microsoft Access program that occasionally hangs when users click on the quit button after been using the program for a long time. This program is just a lean Access front end with a SQL database back end.
One thing that puzzles me is that the quit button does nothing except for the following command:
DoCmd.Quit
Right now I'm suspecting this could be caused by the antivirus. MS Access will try to write (compacting) the database file on exit and the antivirus probably doesn't like that.
However, I'm just wondering anyone else had this problem before? Anything else that could cause this issue?
The DB probably has automatic compaction..and docmd.quit exercises that option. A compaction of a largish db, even if it is sql backed, can take enough time to look like a hang.
Try this...
Application.Quit acQuitSaveNone will close faster but will not compact.
I have experienced this kind of behaviour and it was casused by code that used a static DAO Recordset that failed to close it.
Static rs As DAO.Recordset
'Missing code
rs.Close
Bit obscure but you never know...
This was when closing the application by any means though.
If you have COMPACT ON CLOSE turned on,
TURN IT OFF.
It is a worthless "feature" that never should have been added to Access in the form that it was implemented.
there is no Access application but the most trivial that should not be split into front end (forms/reports/queries/modules) and back end (tables only). A properly-designed front end will never bloat beyond a certain percentage and does not need to be compacted. It's only the data tables that need compacting. COMPACT ON CLOSE will thus not be compacting the data at all, just the front end, so it's worthless.
if you have it turned on in your back end, you can lose data, with no recourse. This is because some forms of corruption in Jet/ACE allow you to use the data without problems, but as soon as you compact, data is lost. Thus, before compact, a table might have 100 records, and after a compact, 98, because the corrupted records were lost in the compact operation. Since this generally happens without it being noticed, COMPACT ON CLOSE puts you in the very dangerous position of compacting without being able to cancel it so that if your file is corrupt, you can lose data.
Don't use COMPACT ON CLOSE. It is both valueless and dangerous.
Try closing all your forms and running docmd.quit from the command window to see if you get the same behavior.
If not, it might be some teardown code in one of your forms that executes when the form is closed. I have seen it before where this type of code gets in an infinite loop or there is a teardown problem in objects that have cyclical dependencies.
If this turns out to be the issue, repeat the above step with each form that is typically open when you press your "Quit" button until it happens again and then inspect the code that runs when that form is destroyed.
In my case it was the use of 'CurrentDb' which seems to be preventing Access to quit. The problem went away once I replaced it with a global variable at the start of the application like...
Set goDbs = CurrentDb
And thereafter using 'goDbs' whereever I needed CurrentDb...don't know why but that solved my problem.
I've encountered the same problem those days, when quitting Microsoft Access 2019, it quits the Database, but keeping a background process running, so not cleanly quitted the applciation.
I've tried Decompile, Repair and Compacting , no any success.
Windows 10 21H1 updating solved my problem.
Related
My company uses a shared MS Access database, with a back end stored on a server and a front end copied onto users desktops.
Recently, our IT department moved us to a new server without giving us any notice, and now our database keeps crashing.
Every 20-40 minutes, users get an error message that says:
Error 3043 Your network access was interrupted. To continue, close the database, and then open it again.
If they close and reopen, it does work. However, I'd like to stop this from happening, since it typically happens when they are in the middle of something and have to re-do everything.
I've already spoken with our IT consultants and they see no issue with our server/network, nor do they know anything about Access and therefore are no help.
Does anyone have any experience with this or have any ideas that may help me repair my database?
Thanks in advance.
Here are some thoughts:
It sounds very much like (short) network interruptions. MS Access doesn't like these at all, in particular it doesn't recover from a broken connection (even if very short) until you restart the frontend.
Network interruptions during write operations on Access backends are the prime cause of backend database corruption. Consider yourself lucky if you haven't experienced that yet. But you should backup and Compact&Repair the backend often (!) .
You can prevent backend corruptions by moving the backend to a server database, e.g. SQL Server Express (free). Errors will still occur ("ODBC call failed" instead of error 3043), but they will only affect the frontends.
You can probably work around all errors by changing the frontend from bound forms to unbound forms. This is a major undertaking.
I don't think there is anything you can do with the backend to prevent the errors.
If this database has value to your company, and IT says there is no problem, I suggest you escalate the problem to someone who can make IT look closer into the issue.
(How to do so would be a separate question, perhaps on SuperUser.)
Sorry for this mainstream post. after doing a long digging to this problem, i've never really found the solution yet. many cause that could trigger this problem.
so i bring up this post to ask for some understanding.
I'm manipulating database.. populating them into array, list, compare, and then storing back them again in database. in all of that process i use many query like ExecuteScalar and MysqlCommand, resulting in creating a lot of new mysqlcommand in module.vb
I'm using vb.net and xampp mysql as data server..
and i have 2 database: they're same but different in size..
the problem is: when i'm testing the 2nd database (the smaller size in records amount)
my program works well without delay or timeout period error`
but when i'm changing the datasource with my 1st database (with 4900 records), the timeout expired popped up directly, causing my vs 2005 become not responding
as per my research on google, i've found few explanation for this error
vs 2005 still has a bug, and that is timeout expired. the solution is to upgrade vs version
the error raised because attempting to open the same connection on the same server.
this error message is not exactly mean what it says. it tells you that the connection was full, but in reality the connection's slot is still available
i'm using too much mysqlcommand variable as i've in module.vb as many as 50 mysqlcomand variable !!!
my personal opinion: i can't apply the first solution.. my program will have a lot of error if i were to upgrading it into vs 2010 or higher
for the second solution: i don't really understand what's that mean. i think that's because i'm trying to open the same connection (example CMD_open1. executereader) again, but that same connection is already open and hasn't been closed
in my program i've already ensure that everytime i'm using CMD.execute reader or executenonquery or execute scalar, i add the CMD name.connection.dispose(), to close the connection properly between open another new one
so my question now is
did all my personal speculation correct? if not, please tell me the correct ones
based on my problem, personally i think the cause is i'm using too much mysqlcommand, even i did close the connection everytime i used. is that correct? what is the right explanation for this?
what is the proper solution that i could apply to fix my problem?
thx for reading. i really crave for the answer for this problem.
here's the ss of my module.vb that contains lot of mysqlcommand variables
Looks like you need some serious refactoring.
Databases-related objects are expensive. The more you instantiate, the more you pay in performance penalties. They are also scarce. You will run out eventually (sooner rather than later). You need to be very judicious in your use of them and be sure to clean them up appropriately when you're finished.
Many programmers put all of the database-related objects into (essentially) a single function which handles all the cleanup, etc.:
Private Function RunQuery( ByVal procName As String ) As DataTable
Using l_connection = new MySqlConnection("connection info")
Using l_command = New MySqlCommand( procName )
l_command.CommandType = StoredProcedure
' ... etc ...
Return l_results
End Using
End Using
End Function
The Using blocks ensure that the database objects are cleaned up properly after each call (calling the appropriate Close and Dispose functions).
But it sounds like you've already got some good advice about what the potential issues might be. The list you provided is pretty much what I would recommend. It's up to you to test and debug to figure out which one of those is causing the problem.
Also, mainstream support for Visual Studio 2005 ended in 2011. If you can't be bothered to upgrade your tools to fix known bugs (because it'll be too much work for you), then there's not much more to say on the subject other than, "Don't complain when you run into bugs."
I have a multi-user split access DB with a front end and back end on a network drive. I often need to make structural changes to the back end of the database but the file is always locked due to the frequent use of the file by many users and the fact that nobody seems to be able to close the file when they are finished with it.
When I need to modify the file I have to contact IT to kick everyone out of the file from the server which is a real pain.
I've tried things like coding an auto close timeout on the FE and a few other vba methods but over time there will always be something that causes the FE to hang or something before running the necessary code leaving the BE locked.
Is there any way to get access to the file without needing access to the Server settings?
Unfortunately, no.
Unless you implement a listener on the FE that looks at a flag on the BE and closes the FE when the BE flag is set (it sounds as if you've tried something like that), there is no way to do what you want. You can't even open the BE exclusively unless there are no other users. This is just one of the reasons that Access is not really a preferred multi-user DB solution.
I'm using Access 2003 on a duo-core machine with 4GB of RAM, running Windows XP (Service Pack 3) [5.1.2600]
Periodically, I get an error msg "There isn't enough memory to perform this operation. Close unneeded programs and try the operation again."
A check of Task Manager indicates that there is plenty of free memory. Closing other open programs makes no difference.
This happens sporadically, and under different circumstances: sometimes whilst saving Form design or VBA code changes, sometimes when several Forms are open and in use.
If attempting to save design changes, and this error occurs, the Access objects are corrupted and can't be recovered.
Any suggestions on what might be causing this would be very welcome.
MTIA
The VBA project in your front end is likely corrupted. You need to rebuild it from scratch and then use proper Access coding practices:
in VBE options, turn off COMPILE ON DEMAND (see Michael Kaplan's article on DECOMPILE for details of why).
in VBE options, turn on REQUIRE VARIABLE DECLARATION.
in the VBE, customize your toolbar so that the COMPILE button is easily accessible (it's on the Debug menu). I also recommend adding the CALL STACK button (from the VIEW menu), as it's handy for debugging errors in break mode. The point here is to make debugging and compiling as easy as possible.
having set up your environment, go through all the modules in your newly recovered project and add OPTION EXPLICIT to the top of every module that lacks it. Then compile. You'll quickly find out where you have invalid code and you'll need to fix it.
from now on, when programming, compile frequently, after every two or three lines of code. I probably compile my project 100 or more times a day when coding.
periodically decompile your project and compact and recompile it. This will clean out any crud that accumulates during regular development.
These practices insure that the code in a non-corrupt project stays in as clean a condition as possible. It will do nothing to recover an already corrupted project.
In regard to how to rebuild the project, I think I'd go the drastic route of exporting all the objects with Application.SaveAsText and importing them into a new blank database with Application.LoadFromText. This is superior to simply importing from your existing corrupted front end because the import can import corrupt structures that won't survive a SaveAsText/LoadFromText cycle.
I program daily in Access, working with non-trivial apps that use lots of code, including plenty of standalone class modules. I have not lost an object to code corruption in over 5 years, and that was back in the day when I was still using A97.
Having tripped across this old post of mine, and seeing it's had a fair bit of interest, I thought maybe an update would be in order?
So 2 years down the track, doing a lot of 2007 app work as well as older 2003 (and even '97) apps, I'm finding that 2007 is less prone to really nasty crashes than 2003 - where Access object definitions (forms and reports esp.) would be easily corrupted.
I still follow the suggestions 1-6 (above) by David-W-Fenton religiously though, plus the use of Application.SaveAsText (see Tony Toews' suggestion and link above).
These days, whether it's 97, 2003 or 2007 I'm working on, if Access gives any hint of "being weird | crashing | throwing inexplicable errors" etc, I do the following:
Immediately close the Access app
Backup the mdb/accdb file
Re-open the app whilst holding down [Shift] so nothing runs
Export all objects as text using Application.SaveAsText (as another backup)
Close and re-open the app using the /decompile switch
Recompile the VBA code
Do a Compact/Repair.
This doesn't solve everything, but it does significantly reduce the number of corruptions of Access objects from what I'm able to observe.
Oh my.
I worked in a shop for many years that used Access as their platform of choice. The application eventually got so large that it began hitting an internal memory limitation of Access 2003. They began experiencing the exact same problem that you are having. As you have noticed, there is no external indication of memory problems when this happens.
The company talked at length with Microsoft about the problem, and I believe Microsoft eventually supplied them with a patch. So you might want to talk to Microsoft about this, if it sounds like a similar situation to what you are experiencing, as they may be able to supply you with the same patch.
Ultimately the long-term solution is to break the application into smaller pieces. Moving to Access 2007 didn't help; in fact, it made things worse because Access 2007 has more moving parts.
Quick solution; guaranteed to work:
Open VBA (Alt-F11)
In the immediate window enter the following:
Application.SaveAsText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"
then
Application.LoadFromText acForm, "corrupt form name here", CurrentProject.Path & "\zzTempRevive"
That's it :) Hope this helps others!
This is also the default error message when Access has no idea what the problem actually is. Now if your MDB is particularly large, say more than 800 forms and reports with modules then, yes the MDB could be too large although that gave you a message when you went to create MDEs. ACC2000: "Microsoft Access Was Unable to Create an MDE Database" Error Message
I have had this happen occasionally myself. And my current MDBs aren't quite that large. Note that compact and repair doesn't detect errors in objects other than tables, indexes or relationships. So importing into another MDB is the only way to correct these errors.
Are you working on this MDB over the network? That's about the only thing I can think of that might cause this problem.
As I know that it's either forms or reports that most likely get corrupted, I created a new mdb, and only imported tables (attached), queries, scripts (one only), modules and menus. Then I used LoadFromText to import Forms and Reports via a function, and then did the usual decompile/compile and compact/repair etc.
So far, touch wood, I haven't had another crash in some days, so I'll probably stick with this recovery method.
Many thanks to all for your suggestions.
I have encountered this problem many times and finally found a solution that worked. I don't know what causes the problem, but I do know how to solve it.
Usually the error occurs when you open a form. What you need to do is completely re-create that form. The easiest way to do so is to first export the form to a text file with the undocumented function Application.SaveAsText. Then you delete the form from your database and re-load it with Application.LoadFromText.
The database that I am working on (in MS-Access XP) seems to have become corrupted somehow. It no longer supports any events - clicks, change, update events, nothing seems to work. This is the error that I get:
The expression On Change you entered as the event property setting produced the following error: Object or class does not support the set of events.
What can I do to make events start working again? I have tried Tools->Database Utilities->Compact and Repair Database..., but it didn't help at all. Also, it hasn't been like this the whole time - events were originally working, but now nothing works, not even the auto-generated command buttons.
Compact and repair generally won't solve problems that happens in objects other than tables and indexes. Importing usually fixes those but maybe try a decompile and then an import. Decompile or how to reduce Microsoft Access MDB/MDE size and decrease start-up times
I encountered the same problem once and documented my trouble shooting steps here. The expression On Click you entered ...
Also see Corrupt Objects within a Corrupt Microsoft Access MDB
Long discussion summarized.
One page that might have a solution that might help is Errors using multiple versions of Access under Vista/Windows 7 This is basically a permissions problem into the registry.
Another suggestion is to to repair the Office 2003 installation in control panel. A2003 then reverts to using Version 11 of the library, but only until A2007 is used again, then the problem reappears.
The original poster stated "Okay, after a few restarts, it seems that removing the 2007 runtime did fix the problem for me. "
Tony alluded to this in his long string of comments, but this sounds exactly like the dueling Access registration problem. I hadn't used A2007 until recently (I had the runtime installed to test if a database developed in A2003 could be deployed under it -- it could -- but hadn't used it since that testing was completely), and when I run A2007 after I've been using A2003, it has to reconfigure itself. The other day, something went wrong during the A2003 reconfiguration (after having last run A2007) and I got errors similar to yours. Running A2007 (to re-register everything as A2007) and then running A2003 (to re-register everything as A2003) fixed the problem.
The key is that when the re-registration fails, Access doesn't necessarily know it the next time it runs, so you end up running in an environment that is partly registered for A2003 and partly for A2007. The way to restore it is to run the other version of Access. That is, if A2003 is launching without the reconfiguration notice, then close it down and run A2007 so it reconfigures itself and re-registers itself as the real Access. Then when you run A2003 next, it will re-register itself as the authoritative version of Access and your A2003 app should have all of its references in proper shape.
Yes, this is very annoying.
And time-consuming.
I don't know why MS seems to think this is something that doesn't need to be fixed. While I know they don't give a rat's ass about developers who need to run A2003 and A2007 side by side, there are plenty of end users who might have an A2007 runtime app installed but also have A2003 installed as part of their base Office installation.
This has been going on forever, so I doubt it will ever be fixed.
I have encountered the same problems many times in Access 2013. From a page on MS web site, I found the answer which solved my problem. I am sharing it here.
I copied the code safely somewhere else outside Access, in the Notepad++.
Then I deleted entire vent Procedure, with its code, which was not firing.
Created fresh Event procedure, and restored the code from Notepad++ to the newly created Event Procedure.
The event earlier not firing started without any glitch. The issue got solved.
I don't know why the problem appears. This problem has come up many times and every time it is resolved with the same solution.
Try it.
Try to decompile and recompile the database.
If that does not work, I usually create a new database and import everything from this one to the new one. If something is corrupted, I will encounter issues at that time and be able to fix it.
Can you see the code in your code modules? If so, cut and paste it somewhere safe. Then flip the HasModule setting for each form to false, repair the database, and restore the code to newly created code modules.
You decompile the database by adding the flag /decompile to the start-up options i.e.
msaccess.exe “C:\my_folder\mydb.mdb” /decompile
I find that solves most of my problems. If not then another one is to re-secure the database by running the security wizard. This basically makes a new db and imports all the objects for you
I had a similar problem. When it started I created a new version of the code by copying the database. This did not help. However, deleting the form from the new database and importing it from the original solved the issue. I did not receive any warnings of corrupted code or other. It simply just worked without any changes to the VBA etc. Bit weird all in all
I compacted the database (Access 2010) into a new one. No joy. Deleted the form that was not working and imported it from the old database. No joy. Recompiled. JOY! Not sure why it quit and why it now works. I suspect a problem with a large amount of text in a linked text box on the form.