Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Compact creates db1.mdb, but database is not read-only 1

Status
Not open for further replies.

suedemick

Programmer
Apr 29, 2002
26
US
I am developing a small (3,000KB) Access 2000 database (not yet split, due to other issues), that resides on our network. Some of the tables are linked, the rest of the tables are populated twice a day by downloading data from our AS400. I recently had to move the database from one network folder to another, and although I have no problem designing new forms, etc., now, when I compact and repair my design copy, instead of overwriting my design copy, it creates db1.mdb and displays the following error message:

"Microsoft Access can't delete .....mdb after compacting it. The compacted database has been named db1.mdb.
If you compact a database using the same name, Microsoft Access creates a new compacted database and then deletes the original datase. In this case however, the original database wasn't deleted becausee it is read-only.
If you can, remove the read-only status,...."

The problem is, the original database is NOT read-only: I have checked the properties. In an attempt to solve the problem, I created a new, blank database and imported all the objects and relinked the tables that were linked. The new database compacted the first time with no error messages. When I tried to compact again, I was back to the error message!

I have just been renaming db1.mdb and proceeding from there, but it is a nuisance and I'm afraid there is some corruption that is causing the problem.

Any idea why it is saying the database is read-only when it is not? How can I correct the problem?

Thanks in advance for any help!
Sue
 
Sue,

Are you sure that within the new location on the network you have sufficiant access to the directory to delete a file within that directory?
 
cghoga,

Thanks for the idea! I contacted our network help desk and they checked my permissions: theoretically, I have full permissions on the folder in question. HOWEVER, we copied the database to my workstation, and it compacted with no problems, i.e. it compacted and replaced the original with the compacted version. I repeated the process three times just to be sure. When we copied this database back to the network folder, I got the same error message again and a new db1.mdb was created!

So, we've decided it is not a problem with the database, but rather a problem in the network folder in which it resides, or at least a problem with my permissions for that folder.

Thanks again for your help,
Sue
 
I had a database that did this.

The cause was an open but hidden form that would not close.

I used a routine on the 'Exit' button to close all the forms and this cured the problem:

Dim intx As Integer
Dim intCount As Integer
intCount = Forms.Count - 1
For intx = intCount To 0 Step -1
DoCmd.Close acForm, Forms(intx).Name
Next

DoCmd.Quit

Garry
 
Garry,

I added your code to my exit button, set the database to compact on close, and I still got the same error message and a new db1.mdb. (Of course, it didn't work when I tried menu option Tools\Database Utilities\Compact and Repair Database, since the code had no chance to run).

Thanks for the suggestion,
Sue
 
Hi, everyone, this is suedemick, again.

I'm not sure, but I might have solved the problem. I think it has something to do with the fact that the linked tables belong to a split database that can only be opened through a workgroup file. When I open the new unsplit database (the one with the compacting problem) through the workgroup file, I can then compact it with no problem! So, I'm going to change the users' shortcuts on their desktops to go through the workgroup to open the database, then I can set the database to Compact on Close.

I was surprised when I created the new database (with linked tables belonging to a secured database), that I wasn't required to give a username and password when opening the new database, but the original database's back-end security may be lax.

Thanks for your help. If anyone can enlighten me on how workgroup files can affect other linked databases, I'd really appreciate it!

Sue
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top