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.
Related
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.
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.
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.
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.