I copied a split/compact&repaired DB from a system running Access 2013 to a new system running Access 2016.
I get an immediate crash if I attempt to open it.
If I temporarily rename the backend (so the frontend doesn't find it) then the front end opens OK.
I can then rename the backend to the correct name and the frontend can now access all my data. Everything works except a compact and repair. I have even recompiled all the VBA and that is fine too.
It will continue to work until I try and reopening it and then I'm forced to use my rename trick to get it going again.
The source DB both front and back were compacted/repaired before copying!
Any clues as to what I should check or look for?!?!?
Looks like this is database corruption. Create new database and copy all objects to new one, it may help. In most of cases coping doesn't fix corruption in tables data, export to xls and import may help in some cases.
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.
An Access database with a load of queries, tables, reports and forms with VBA code.
Was used in Access 2010 for ages, then some users upgraded to Office 2013 very recently.
One user had a "problem" on their computer while using the database, which may have resulted in their computer restarting, and now the database seems to have no forms or code visible when opened.
Googling finds reports of similar situations where the forms and code was there but invisible.
Any ideas?
The first thing to attempt is to open the database and choose Compact and Repair. I would then go into the VB Editor, if possible, and choose the Debug menu, Compile. While in the VB Editor, also check Tools, References for any missing references.
If the database is split to a back-end and front-end then just give them a new copy of the front-end. If this doesn't work then I would re-install Office on their computer.
If they have their own copy of the database (it is not split) then give them a new copy.
If they have already entered data that needs to be kept then I would start a new database and import all of the Access objects from the existing database. I have found that re-importing all objects solves most of these issues. You could import just the tables from their copy of the database, but the other objects from another copy.
If re-importing all objects doesn't resolve the issue then a remaining option is use the decompile command-line option:
C:\Program Files\Microsoft Office\Office15\MSACCESS.EXE /decompile
Open Access from this command-line, go into the VB Editor and choose the Debug menu, Compile. Then close, re-open and Compact and Repair.
I have an application that creates an Jet database at run-time, and imports ~100k records so that I can make use of the indexing for performance reasons (1 minute versus nearly 10 when not using a Jet database).
The database is created using ADO Extensibility in Excel, and everything works just fine. However, my issue comes whenever I then open the MDB file in Access front-end, it automatically starts to "repair" the database.
The data is still fine after the "repair", however my main output query can not then be viewed in Access as it tells me it cannot represent the joins, and if I then view it in SQL the required joins are not there, and the query can no longer run. This still happens if I let it get "repaired" but do not open that query, i.e. it is the "repair" that breaks the query, not the act of trying to view it in Access. The funny thing about this is that I used the Access GUI query designer to construct the SQL as my life is too short to worry about it's crazy bracketing style, but it then later decides that it's too complex for itself??
Also, nothing else appears to be affected so I can only assume it's this one query it doesn't like.
This isn't a deal-breaker for me as my fix is to make the MDB hidden and advise users who can see it not to open it.
However, I would really like it if the database could be opened and I didn't have to hide it away like that. Therefore, my question is whether there is any way to prevent the MDB being "repaired" automatically?
Thanks!
Microsoft Access is "repairing" the file when opened because it is missing some tables that are specific to the Microsoft Access user interface. Since you created the MDB file directly using OLEDB with Microsoft.ACE.OLEDB.12.0, these tables are not present, and must be created when Access opens the MDB the first time. There are several ways you can circumvent this:
1) Name the MDB something other than .mdb - e.g.: MyAccessDatabase.mad - this will prevent Windows from using Microsoft Access to open the file.
2) Use COM+ to open an instance of Microsoft Access, and have it create the .MDB file. This .MDB file will then have all the necessary tables present and will not need to repair the file.
FYI, whenever Microsoft Access opens an MDB that needs repairing in this fashion, it will inspect all the QueryDef objects for invalid SQL and correct them as necessary. This is why your "complex" query is breaking.
Last week I was modifying portions of two modules in an access 2010 db when the program crashed, and would crash every time I tried opening up the db thereafter. I was able to create a new database and import the tables and queries from the corrupted one, but when I tried to import the forms/macros/modules the new database would start crashing also. I keep daily backups, but ended up losing several hours worth of work. This happened twice last week, each time MS Access would crash without warning and the VBA was unrecoverable.
The functionality works as intended until the db crashes seemingly at some unknown point. There must be some sort of issue with my VBA code, since this only started happening when I started modifying the module last week, but I can't pinpoint it since the crashes actually occurred when nothing was being executed. Ie during save.
Does anyone know if it's possible to export the VBA out of access without exporting it to another database? Ie export it without having to use MS Access to do so. On a related note, has anyone created a library that exports query definitions, table schema, and all VBA to text files that I could drop them into source control?
Thanks.
In addition to the method suggested by #Remou, you could try the SaveAsText method to save a code module to a text file.
Application.SaveAsText acModule, "Module1", "D:\Access\Module1.txt"
However, that doesn't satisfy your desire to do it without using Access.
Try a decompile operation on the chance your project includes saved compiled code which has been corrupted. You can find detailed instructions for decompile in the 2 answers to this Stack Overflow question: ms-access: HOW TO decompile and recompile
After decompile, make sure all your modules include Option Explicit in their Declarations sections. Check the project's references, and fix any that are broken (missing). Then run Debug->Compile from the VB editor's main menu to verify your code compiles without error.
Those steps are the best I can offer to reduce potential for continued corruption problems.
For integrating source control with Access, start with this selection of related Stack Overflow threads: site:stackoverflow.com ms-access version control
Folks
We're having the same problem. There is a bug in SP1 that causes it. If you keep opening the database, you'll finally end up with a backup that works - rename the old one BROKEN and remove the _backup from the new database, and you are oky till your next bit of development. Our IT guys (Microsoft Gold Partners) are looking at a fix reported on http://answers.microsoft.com/en-us/office/forum/office_2010-access/access-2010-sp1-you-receive-random-crashes-in/d2bf6175-075a-4a12-a2b1-f55d40af271b
I may go take a look at decompile/recompile however as some of our database have come all the way up from Access 97, to 2000, 2003 and now as mdb/2003 file format still, running under 2010. Having said that, converting to accdb/2007 seems even worse!
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.