Compacting Access 2003 database

[BlackEagle]

When I compact my access 2003 database named 'Projects.mdb' of size 7.1 Mb, a
file named 'db1.mdb' of size 4.1 Mb is created. The original file
'Projects.mdb' remains the original size. The newly named database functions
correctly when opened. This problem only occurs if the database is located on
our company network. If I move the database to my local workstation drive it
compacts correctly preserving the original file name with no duplication
created. I have checked folder permissions and have made the following
observations: Not folder dependant, not network drive specific, not database
dependant(i.e. tested using another database), not security related as
database doesn't have password or permissions set, and the database compacted
correctly at one time. Note also that the network administrators can't see
any write or permission problems on the network. Any insight would sure be
appreciated.

 

[banem2]

When I compact my access 2003 database named 'Projects.mdb' of size 7.1 Mb, a
file named 'db1.mdb' of size 4.1 Mb is created. The original file
'Projects.mdb' remains the original size. The newly named database functions
correctly when opened. This problem only occurs if the database is locatedon
our company network. If I move the database to my local workstation drive it
compacts correctly preserving the original file name with no duplication
created. I have checked folder permissions and have made the following
observations: Not folder dependant, not network drive specific, not database
dependant(i.e. tested using another database), not security related as
database doesn't have password or permissions set, and the database compacted
correctly at one time. Note also that the network administrators can't see
any write or permission problems on the network. Any insight would sure be
appreciated.

See

http://www.eggheadcafe.com/software/aspnet/31218278/compacting-not-deleteing..aspx

Regards,
Branislav Mihaljev
Microsoft Access MVP

 

[BlackEagle]

I didn't find a solution in this reference as I don't get any error file and
the problem is Not database specific but rather network specific.

 

[banem2]

I didn't find a solution in this reference as I don't get any error file and
the problem is Not database specific but rather network specific.

Give us more details. As I see it, the problem is compacting of
backend in shared network folder? Do you have any MS Office 2003 SP
installed?

Regards,
Branislav Mihaljev
Microsoft Access MVP

 

[BlackEagle]

Give us more details. As I see it, the problem is compacting of
backend in shared network folder? Do you have any MS Office 2003 SP
installed?

Regards,
Branislav Mihaljev
Microsoft Access MVP

We're running ACCESS 203 Ver 11, build 8166. I don't have the database
split, however compacting worked in exactly the same environment for the past
year or more. I keep thinking the problem is somehow related to network
folder permissions or database/application permissions although I don't have
permissions set up for the database and the networked folder permissions look
good to me. I am relatively new to programming in ACCESS so maybe I'm missing
something that should be obvious.

 

[banem2]

We're running ACCESS 203 Ver 11, build 8166. I don't have the database
split, however compacting worked in exactly the same environment for the past
year or more. I keep thinking the problem is somehow related to network
folder permissions or database/application permissions although I don't have
permissions set up for the database and the networked folder permissions look
good to me. I am relatively new to programming in ACCESS so maybe I'm missing
something that should be obvious.

First advice I am giving in these cases, when something strange came
up from nowhere, is to import all objects into new, empty database to
make sure that DB is not damaged in any way. You can try something
else and let us know if that worked: copy database to your PC and try
to run compact & repair. As you can edit data in database, that means
you have both read and write permissions to the shared network folder
and, as it worked before, this is not an issue.

Regards,
Branislav Mihaljev
Microsoft Access MVP

 

[BlackEagle]

First advice I am giving in these cases, when something strange came
up from nowhere, is to import all objects into new, empty database to
make sure that DB is not damaged in any way. You can try something
else and let us know if that worked: copy database to your PC and try
to run compact & repair. As you can edit data in database, that means
you have both read and write permissions to the shared network folder
and, as it worked before, this is not an issue.

Regards,
Branislav Mihaljev
Microsoft Access MVP

Following your instruction, I simply created a new database although I
didn't bother to bring in tables etc. and tried compacting on the network and
the same problem occured ; that is the db1 file was NOT renamed to the
original file and erased. I repeated the procedure on my local drive and
compacting succeeded. I then tried compacting using my old desktop computer
that also was networked and it also compacted on the network successfully. A
third step was to ask one of my staff to try compacting the file from their
networked computer and that also went successfully. The conclusion I must
draw is that the problem is related to the ACCESS application which is
installed on my local drive. What is puzzling however is the fact that
another coworker has the same problem as I do with the ACCESS application
running on her own local drive. She works with the same datsbases as I do.
Before I call Information Systems to reinstall the application, can you offer
up any ideas as to what role the application plays in this problem. Is there
some security or option setting that could affect this?