I have an MS Access 2007 split database. The Back End database contains 1 table. It is on a shared drive and front end has a data entry form with Macros, also a linked table from back end. Everyone in the organization has same version of Access (2007), same operating system etc.
Problem is I am able to open and add records to the front end but when anyone else try to open the front end it comes up with "Unrecognized database format" and they couldn't open it.
So far tried changing New database sort order to general - Legacy/ Compact and repair database from database tools but still not working for other users. Almost spent half a day searching and trying various solutions without success. Any help into right direction will be highly appreciated.
The lock file got corrupted. Delete it and re-open the application.
Related
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 problem with a DB I started work on a couple of years ago in Access 2010. I fired it up last week and now I'm getting an "unrecognized database format" error when I try and open the front end.
I left this project sat after the company lost interest in finishing it. Since then I worked on another project on the same dev machine which required me to install Access 2007. I had both 2010 and 2007 installed at the same time and I remember opening the now problematic db to take some snippets from some code in there for use in the other project. Im pretty sure I only opened it in 2010 at that time.
Now the company has shown interest again I need to finish the project.
Ive tried uninstalling all instances of Office and the Access Database Engine (I needed this to test the 2007 project) running a clean up and putting a fresh install of 2010 back, but Im still getting the same error. Ive tried importing the objects from the accdb file into a new db but access still throws the unrecognized database format error. The same error is given if I try to decompile as well.
Today Ive tried uninstalling office 2010 and putting a clean 2007 install to see if I can open/decompile/import from the older db under that version of access but Im faced with the same error.
The file server where I backed up to has been rebuilt since I worked on the original project and I thought that the accdb file might have been corrupted during this process as Im pulling it from the old vhd. I've also pulled backups from several locations and all the files give me the same error. Ive even tried running them on one of the clients where I know it used to work and has not been had office tampered with since I was last looking at this and still I get the same error. I know that I had compact and repair on exit set on the front end and Im wondering if I managed to inadvertently use 2007 and the last time I opened it and royally screwed it up unknowingly creating a little surprise for me here two years down the track!
I have even tried installing an "Access Recovery Toolbox" util to see what that could make of the file, and it pulls absolutely nothing back in the report.
I have a much older version of the db which works on my dev machine but Im at a massive loss if I have to start work from this version as I made some very significant changes between these versions including changes to the back end table structure.
Any light anyone can shine, even if it just means getting the VBA out into a text file would be really helpful!!
TIA
Have you tried creating a new DB and pulling in the tables, forms, etc from the bad DB? I would recommend doing it incrementally and checking the new DB after each import. IE just bring in the tables and then see if they are healthy before moving on.
We have a system that uses replication to allow folks in two different locations to work with a common database back end. The network is not high quality, and slow so I used replication to put a back end at each location and keep them synchronized. Synchronization is done through the Replication Manager and synchronizer running on a schedule. This has been working great for the past two years. The system was originally developed and used with Access 2007 but with the back end in mdb format. So now the client is up to Access 2010. The client wanted some changes to the back end, entailing some new tables and new fields added to existing tables. No problem I think. I went to the site and opened the Replica set design master using Access 2010 and added the new tables with no problem. Then I tried to add the new fields to existing tables. I could do that in design view but when I tried to save the changes I get a message 'Operation not supported for this type of object' message. I banged my head against the wall for a while thinking I was doing something wrong, then gave up working at the client facility. I did run the synchronizer before leaving and the new tables propagated properly to the other managed databases. This part is working.
After returning to my office I thought possibly this is an Access 2010 issue. I fired up a virtual machine with Access 2007 on it and a running replication system of the same database. In Access 2007 I could open the design master and add fields to existing tables with no errors and the changes would save. Is this an Access 2010 issue or is there something else going on? I'd hate to have to re-install Access 2007 on one of the client computers to make these changes. I have the same system running on my Access 2010 machine and I can duplicate the 'Operation not supported for this type of object' issue using Access 2010 in my office. Any thoughts?
Thanks in advance for your assistance.
Old thread but I have also run into the same problems. I found that using Access DDL (e.g. ALTER TABLE) in the SQL window works to modify table design in a replicated database in Access 2010. It won't allow you to modify an existing field/column but you can at least add or drop fields from existing tables. You can use DDL to modify an existing field by adding a new temporary field to your table the way you want it, copy the data from the existing field to your temporary field, then drop the existing field. Then add a second new field with the name of the field you deleted and copy the data over from the temporary field. Then delete the temporary field. More Access DDL info here
I recently upgraded to MS Access 2010. When I open a certain .mdb (2000-2003 file format), I am greeted with this message: collating sequence not supported with the specified file format. I'm not sure what it means, but it gives it to me every time the database is opened.
I have Googled around but found nothing that I thought seemed related. If I upgraded the file format to 2007 it didn't give me the message but that isn't much of an option in this situation.
Is this a 2010 issue? or is there something corrupted with my database? What do I need to do to work around it?
I had the same problem and found a different solution. I am using ms-access 2010 and 2007. 2010 could not create mdb files and the accdb files it created would not open in 2007. The solution was to go to the File tab in 2010, click the options link and set the sort order for new databases to 'General - legacy'. The sort order that was displayed was 'General' I then created a blank database in mdb format and imported all the objects, forms, code et. The newly rebirthed database works in 2007.
This KB article by M$ fixed my problem. The issue was the "new database sort order" setting.
I encountered this error after enabling the Track name AutoCorrect info option for a database originally created in Access 2007 then later upgraded to the 2010 file format. I'm now using it in Access 2016.
In my case, contrary to the resolution provided by the Microsoft KB article referenced by #Icode4food's answer the solution was to change the new database sort order to "General - Legacy".
Additionally, this database is configured to automatically perform a Compact & Repair upon exit. For some reason this caused the sort order to revert back to General. Therefore the exact steps I had to take to solve the problem are as follows:
Change New database sort order setting to General - Legacy.
Close database. Cancel automatic Compact & Repair by pressing ESC.
Re-open database and confirm sort is is still set to General - Legacy.
I also faced similar issue, I had MS-Access file created on one machine. And I shifted my web server to another machine. And I started getting the similar exception.
I just created a new MS-Access DB on new machine and copied all the tables (with data) from old db.
And using the new DB file fixed my problem.
Cheers!
Backup. Make a backup copy of the bad database, without overwriting any existing backups. Whatever has gone wrong, you don't want to make it worse, and a backup gives you multiple attempts at recovery.
Uncheck the Name AutoCorrect boxes.
In Access 2007: Office Button | Access Options | Current Database.
In previous versions: Tools | Options | General.
For an explanation of why, see Failures caused by Name Auto-Correct.
Compact.
In Access 2010: Compact and Repair Database on the Database Tools ribbon.
In Access 2007: Office Button | Manage | Compact/Repair.
In previous versions: Tools | Database Utilities | Compact/Repair.
Decompile. Close Access, and enter something like this at the command prompt:
Use the path to where msaccess.exe is found on your computer, and include the quotes.
Compact again.
Open Access (holding down the Shift key if you have any startup code), and compact again.
Do this twice: one comp
I was inserting data into a MS Access database using JDBC-ODBC driver. The blank mdb file was 2KB. After populating this database, the size grew to 155MB. Then I was deleting the data. But I found the size of mdb remains the same as 155MB. I don't get any errors. But is it normal this way? I would expect the file size reduces. If it is designed in this way, what is the idea behind it? Thanks
MS Access doesn't reclaim the space for records until you have compacted the database.
This is something you should do to an access database as part of your regularly maintenance otherwise you will end up with some pretty painful problems.
You can compact a database either through the MS Access UI (Tools -> Database Utilities ->
Compact and Repair Database) of you can use the command prompt using:
msaccess.exe "target database.accdb" /compact
N.B. the /Compact switch must be after the target database
MS Access doesn't free up space used by records even after they are deleted. You can free the space manually when you need to or automatically each time you close the application.
To do it manually, use the Compact and Repair utility:
Backup your database, as there is a bug in Access 2007 that may delete your database during the compacting procedure.
If you are compacting a multiuser (shared) database that is located on a server or shared folder, make sure that no one else has it open.
On the Tools menu, point to Database Utilities, and then click Compact and Repair Database.
To do it automatically when you close the application:
Open the database that you want MS Access to compact automatically.
On the Tools menu, click Options, and then choose the General tab.
Select the Compact On Close check box.
After deleting the data and compacting the database don't be surprised if is still larger than 100 KB. There is a certain amount of overhead that cannot be removed after you add data the first time.
Also, beware that AutoNumber field values behave differently than advertised after the compacting procedure: According to the MS Access 2000 documentation, if you delete records from the end of a table that has an AutoNumber field, compacting the database resets the AutoNumber value. So the AutoNumber value of the next record you add will be one greater than the AutoNumber value of the last undeleted record in the table.
I have not found this to be the case: If you have 100 Autonumbered records and delete the last 50, the next AutoNumber record (according to the documentation) should be numbered "51". But in my experience it is numbered "101", instead.
The first stop, as mentioned should be attempting to compact/repair the database. However you can also get some size saving past that by creating a new database and importing all of the objects from the old.
You can compact the database from code using JRO. See: http://support.microsoft.com/kb/230501
The first stop, as mentioned should be attempting to compact/repair the database. However you can also get some size saving past that by creating a new database and importing all of the objects from the old. Past that, converting it to an MDE should get you a hair more. As always, don't play around with your production copy. Also if you go with an MDE, make sure you have properly split the database first. (And of course keep a copy of the source MDB should you need to make modifications in the future.)