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.
Related
I have an Access 2013 database split across a network that is mainly used via Citrix. I keep getting the error message that the database is in an inconsistent state and I don't know why. I created a query to capture the user name and machine id as a auto-exec macro so I can go back and ask users what happened etc. But what I'd like to know is if it would be possible to know which user first encountered this error? Can I trap the error somehow and know which user "caused" it? I have a feeling that this error happens prior to the auto_exec macro firing but I live in hope.
What I am hoping to be able to do is get with the Citrix team and see if they have a corresponding error or something in their logs.
.. sadly they are all sharing the same front end. It's only being used
for read-only lookup purposes. I wanted each user to have their own
copy but IT disagreed with me.
The only way it could work reliably, is if the accdb file itself is marked as Read-Only, and that would probably leave your application useless.
I've been through this with a client running a huge Citrix setup (40000+ employees) for an application with a priority. IT had for a reason a strict view on security, but though quite cooperative, they were of little help.
However, I got it solved by a VB script. It worked in the first attempt and so well, that I wrote up a description here:
Deploy and update a Microsoft Access application in a Citrix environment
The great thing is, that you probably won't need IT to do anything for you.
I'm having a problem. One of my databases on our shared network will not open for any user. It says "Unrecognized Database Format."
I've had this problem before but was still able to open the database, compact and repair, or import all of the database objects into a new database.
The problem here is -- I can't even get it to the point of opening. Is there a solution here without the use of third party software to repair the database?
Open access, go to the database tools tab, select compact and repair database. You can choose the database from there.
WE had this problem on one machine and not another...the solution is to look in control panel at the VERSION of the Access Database Engine 2007 component. If it is version 12.0.45, you need to run the service pack 3
http://www.microsoft.com/en-us/download/confirmation.aspx?id=27835
The above link will install version 12.0.66...and this fixes the problem...thought I would post it since I haven't seen this solution on any other forum.
After much struggle with this same issue I was able to solve the problem by installing the 32 bit version of the 2010 Access Database Engine. For some reason the 64bit version generates this error...
Try to create a new database and import every table, query etc into this new database. With this import Access recreates all the objects from scratch. If there is some sort of corruption in an object, it should be solved.
If you're Lucky only the corrupted item(s) will be lost, if any.
Well, I have tried something I hope it helps ..
They changed the schema a little bit ..
Use the following :
1- Change the AccessDataSource to SQLDataSource in the toolbox.
2- In the drop down menu choose your access database (xxxx.accdb or xxxx.mdb)
3- Next -> Next -> Test Query -> Finish.
Worked for me.
Sometimes it might depend on whether you are using code to access the database or not. If you are using "DriverJet" in your code instead of "DriverACE" (or an older version of the DAO library) such a problem is highly probable to happen. You just need to replace "DriverJet" with "DriverACE" and test.
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.
I'm trying to use the built in Make ACCDE functionality in access to make a standalone application that interfaces to an SQL-Server 2008 back end. When I run the Make ACCDE I receive an error that states that too many TableID references are being used (the limit is stated to be around 2048).
Through trial and error (deleting forms until it compiles) I've discovered which form is causing the issues. It seems to compile if I delete all the VBA code from the form.
I was wondering if anyone has run into this problem before and if there is a specific issue that causes it? I've run into this problem a few times now and it's a real pain to go through my code deleting half of it to find where the error is coming from.
For future coding, you should make sure you follow good coding practices:
in VBE options, turn off COMPILE ON DEMAND and make sure REQUIRE VARIABLE DECLARATION is turned ON (this will cause new modules to be created with OPTION EXPLICIT by default).
add the compile button to your toolbar in the VBE so its easily accessible. When coding, hit the compile button after every few lines of code (and SAVE after each compile). This will prevent you from writing too many uncompilable lines of code, so it will be easier to fix them to be compilable.
on a regular basis, make a backup of your database and decompile and recompile it. This will clean out any crud that has accumulated in the compiled p-code (decompile strips all the compiled p-code and leaves only the canonical code text) and can flush out compile errors that had previously been hidden by corrupted p-code.
By following these best practices, you will hardly ever encounter code corruption.
I've occasionally seen similar errors. I'd suggest importing all your objects into a new ACCDB. Compact & Repairing only cleans up tables and indexes and doesn't do much in the way of corruption diagnosis or cleanup for the other objects.
If you do have it isolated to one particular form try doing a copy and paste on the form. This should be enough for Access to save a clean copy of the form.
Next time you encounter this though could you record the exact error message including the number and email me at tony at granite.ab.ca. I'd like to add this to my list of such errors for my corruptions web page as this appears to be an Access 2007 specific message.
I'm working on a MS Access database. I've made some changes to one of the modules. I want to go out for lunch, but when I try closing the database, I get the following message:
"You do not have exclusive access to the database. Your design changes cannot be saved at this time. Do you want to close without saving your changes?"
I'm pretty sure nobody else on the network has the database file open, and I don't have any other Access databases open. I'm probably missing something obvious, but would really appreciated some help!
Update:
In the end I copied all the code, closed the database without saving, re-opened it and pasted the code back in. I was then able to save the database. I'm not sure if this was a one off, but I'll report back if it happens again.
If you're sure no one else is in the db but you, it's an additional connection to your db from your own pc. You can verify this with the LDB viewer, downloadable in the free JetUtils.exe download from Microsoft:
http://support.microsoft.com/kb/176670
Look through your code and check if you have two separate database objects in the default workspace or another database object in a separate workspace. That will cause this problem.
To fix it, make sure the database objects are set to nothing before they go out of scope, and if you opened the database object in code, you also need to close it before setting the database object to nothing.
=============================================
Update in August 2022:
The MS link above no longer works. The document remains available on Archive.org, but is outdated. A document that appears to provide the current version of its information is at:
https://learn.microsoft.com/en-us/office/troubleshoot/access/determine-who-is-logged-on-to-database
This provides VBA code for a sub to obtain a list of users. The writer of this update has tested that code successfully in Access 2019.
If you close the database and are sure nobody else has it opened, check to see if there is a .ldb file (it will have the same name as your database file). If the file is there, then there is a good chance it is still in use.
Is it being access by a service, like a website?
You could copy the database to another sub-directory and make your changes. If that doesn't work, I will have to look that up. Of course there is always the database tool, "repair and compress database..."
Is the file located on a file server? If so check to see if any users have a file handle to it.
If it still doesn't work, update your post with your new information and we'll go further.
UPDATE (9/26):
Another thing I do when having strange issues with access databases with contain vba code is decompile. I don't know if this is documented yet, I haven't looked in years, but it's was (at least) an undocumented switch to msaccess.
From a cmd line:
change directory to where msaccess.exe is located.
Run the following command
msaccess \path to access file\databasefile.mdb /decompile
usually runs very quick then opens the database. Open any module and compile.
Doesn't always work, but sometimes can remove strange happenings.
Did you ever trying to copy the database to another directory and making your edits? That should of worked; you could then rename the original and copy the file back.
Anyway, I am glad you are working again.
If even a word mail merge is linked to the access database, that counts as an access connection.
Very simple.
Close all of your MSaccess files.
Open task manager (by right click on task bar).
Select Processes tab in that.
If the list has a msaccess*32 process close that by clicking on End Process.
This worked for me. I think it closes all the recordset which we have not closed in the codes or which is closed forcefully.