In my organization, all Access databases with a table containing data stored in the database on a shared location generate the error 'Unrecognized database format'. If we make and fill the database locally, everything works just fine. Once we save the database to a shared file location, the error 'Unrecognized database format' appears and the database starts repairing itself (unsuccessfully).
If the database doesn't contain data but is connected to a external data source, for example a .txt file or sharepoint list, the database keeps working fine.
The databases are .accdb files but if we make a new database as .mdb file the problem doesn't disappear.
I found several other questions regarding the error 'Unrecognized database format' but none concerning this error when saving on a network location.
Most likely, you are hit by the now three(!) year old lease bug.
Daniel has wrapped it up nicely, including the options you (don't) have:
Access – Bug – Database is in an Unrecognized Format
The main issue is, that the way newer Windows versions work may not be compatible with the way Access shares an Access database.
As this is touching both the core of Windows file sharing and the core of the Access database engine, there is no simple fix, as the three year delay clearly indicates. What we currently know is only, that Microsoft is still working to find a solution.
Related
I'm updating a 2006 program written in VB6. It has a large database created with Access 1997 with which the program works fine, but Access 2007 would not allow me to modify the database unless I converted it from .mdb to .accdb.
I did so and in Design mode, changed the DatabaseName to the .accdb extension, left RecordsetType as Dynaset, but when I click on RecordSource, I get an "unrecognized database format" message.
I've researched everything I could find on the web. Someone said to switch from DAO to MS Office Access database engine (12.0) which I did. Someone else suggested using Access (2007) to compact and repair it, which I did.
In Resources, I see *MS ActiveX Data Objects 2.5 library and MS Data Environment Instance 1.0 (SP4). I don't know what they are for offhand, not having looked at this software in a dozen+ years.
If I run it without specifying a RecordSource in Properties, when it gets to the line:
Set rs_BidTable = db_BidBase.OpenRecordset("Table1") (where Table1 is a table in the database)
it gives a "Type mismatch" error message. None of the code changed after the update other than changing the database name in the code.
I could give more detail about what I have in the code, but since it's bombing in Design mode, I'm don't think the code is relevant (is it?).
I have other programs with databases updated to Access 2007 and never had this kind of problem.
I am maintaining an application which uses an access mdb file as a front end to SQL Server, using odbc linked tables.
I would like to make the mdb file readonly (otherwise the file just grows and grows as users use it, and some occasional odd locking errors not relating to data but to the access application).
Since all the data is in sql, the application should work just fine even if I make the mdb file readonly, and in fact it does work for the most part, except...
Part of the application uses DoCmd.TransferText to import various text files into various tables. if the mdb file is readonly I get runtime error 3051 error "The Microsoft Access database engine cannot open or write to the file ... it is already opened exclusively by another user, or you need permission to view and write its data".
I can't see any reason for this error, since I am not writing any data to the mdb file itself. (and I also noticed in the 'External Data' ribbon all the 'import' buttons are greyed out).
any suggestions?
thank you
Since all the data is in sql, the application should work just fine even if I make the mdb file readonly
Not necessarily. You are using the .mdb file as an application so it may well need to update local temporary tables or other objects in the .mdb file.
Furthermore, if you are using an .mdb front end then each user must be given their own local copy of that file, so file bloat is essentially a non-issue and you can just let the users have write access to the local file.
I'm getting the following error message on some users machines:
The expression On Open you entered as the event property setting produced the following error: There is an invalid use of the . (dot) or ! operator or invalid parentheses.
This error message appears when trying to open the Access database on some peoples' machines using Access 2010 on Windows 7 from a shared location.
Using the same shared network location the database opens fine on Windows XP with Access 2003.
I've checked the registry for the Sandboxmode (2).
The folder location is shared and open for all users.
Looks from the code its not liking the main menu, its complaining about the ! in this form:
strCriteria = [Forms]![MainMenu]![Text22]
I see two issues here:
Compiled .mde (and .accde) files are a lot more "fussy" about different versions of Access than .mdb (and .accdb) files are. This is presumably because .mde files have the source code stripped out of them so Access cannot re-compile things "on the fly" like it can with an .mdb file. Years ago I began stipulating that if the Access application is using an .mde front-end then all users must be running the same version of Access and the .mde must be compiled for that version. Even so, an .mde file will occasionally "act up" but re-building the .mde from the source .mdb will usually fix it. (Subtle changes introduced by Office patches and Service Packs may account for at least some of that.)
If multiple concurrent users are opening the same .mde file from a network folder then you will almost certainly encounter problems. For many years it has been well-known among Access developers that a multi-user Access application must be split into a front-end and a back-end (which you have apparently done), and each user must have their own local copy of the front-end file. Even Microsoft is recommending the practice now (after many years of their being conspicuously silent about the matter).
We have the problem, which I think should be easily resolvable, but just not sure how.
We have the Windows 2003 Server with the Classic ASP application on it. The MSAccess database is used for data storage.
The application is designed in the way that it has a lot of includes.
The .asp page may open the DB connection and close it in the end of the page. At the same time the include that is included on the page may have the same database open as well.
The problem is that on the second open we're getting an error:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Microsoft Access Driver] Could not use '(unknown)'; file already in use
This is on our local configuration only - we don't own that project, but are helping customer to fix some items. Everything works just perfect on Customer side.
When we set the read-only access to the database this error is not shown.
So, it seems that the ADODB.Connection is opening the database in exclusive mode.
Anyone has any ideas how to fix that?
Thanks
Ok. The issue was resolved. As I was saying in the question - the resolution was VERY SIMPLE. Instead of setting the IUSR_* Write permission to MDB file only, it was necessary to set the Write permission to the whole folder where the MDB file is stored. Strange, because I don't see any additional files created (meaning, like .ldb file, which is created during an exclusive DB open). But, it works now!
As far as I remember from using Access in my first classic ASP days you can't have more than one connection opened in the same time pointing to the same physical .mdb file because once it's opened, it's locked. That's what I learned the hard way.
The solution for me was using one single Connection. Having very small website to manage, I just used Application level connection object, created and opened once in global.asa then used in all pages.
However this is not good for ordinary websites so you can write file called "database.asp" in there create and open the connection then include that file and use the connection object in your code, not forgetting to close it in the end of every page.
Hope this makes sense, I'll clarify if needed.
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