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.
I'm currently running reports and queries against one linked excel spreadsheet. Ran into a permission conflict on my work network, so what I've needed to do is create a duplicate of the excel spreadsheet. Then place that duplicate in another location with lower access rights.
All my queries and reports run from the previous data source. All fields are the same - as the spreadsheets are duplicates of one another. Is there a simple solution that would prevent me from having to go back and redo all my queries and reports? I've tried changing the data source and leaving the rest the same with no luck.
Just delete the old linked table, and then link the spreadsheet from the new location applying the same name (in Access) to the linked table as you used before.
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 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 just downloaded the ziped package containing the Contoso Data from partnersource and I don't know what to do with the files.
The files are:
MicrosoftDynamicsAx.bak
MicrosoftDynamicsAx_model.bak
I don't know what to do with those files to have the Contoso (Demo) Data on Ax.
Edit: Since I made this post, Microsoft has released a new Dataset. In order to install this data, you can use the restore option. In order to do so:
Shutdown the AOS in services
Open SQL Management Studio
Connect to the SQL Database
Right Click MicrosoftDynamicsAx => Tasks => Restore => Database
Select From Device and then find the downloaded .bak File.
On the top left click on "Options" and check the first box:
Overwrite the existing database (With REPLACE)
Click OK and repeat for the other DB.
For more information on the three partitions contained in the CONTOSO Dataset check the pdf available next to the CONTOSO data download link!
The folowing procedure allowed you to install the first Dataset that Microsoft removed a couple of days later from their website. This procedure can still help you restore the new .bak files if the previous one fails.
Shudown the AOS in Services.
Open SQL Server Management Studio.
Connect to your Ax Database.
Note: Here, you will see there are two bases with the same name as the Contoso .bak ones. You guessed right, we are going to import them, but you can't do it by just clicking on "Restore Database" since the .bak file originated from a different database. Here is where a litle bit of coding is required.
Backup the two bases.
Click on "New Query" and input/Execute the following code:
Alter Database MicrosoftDynamicsAX_model
SET SINGLE_USER With ROLLBACK IMMEDIATE
RESTORE DATABASE MicrosoftDynamicsAX_model
FROM DISK = '%Path to .Bak File%\MicrosoftDynamicsAX_model.bak'
WITH REPLACE
If this doesn't work because the Database is in use, add the following lane at the top of the query:
Use Master
Repeat the same query for the MicrosoftDynamicsAX.bak file
Once all this is done, your Database should be up to date and the Contoso Data should be imported.
You can now restart your AOS. This might take a long time and you might even consider rebooting the server. Once the server finally starts, open the Ax Client. It should be extremely slow. This is due to the 26 000 Alerts that you should see on the bottom right part of the client. Mark them all as read (again this will take some time) and now the client should run much faster!
You should now have Contoso Data in your Dynamics AX 2012 R2 Installation!