J
Jay
The problem is centered on the fact that the
option "Compact on close" is selected for each of my
database files.
The users open these database files through Microsoft
Access over the network. When they close the database,
the compact utility is automatically triggered. The
result is that Access creates a temporary database file
that is the compacted version of the original file, and
Access then attempts to delete the original file in order
to replace it with this new compacted version.
The problem happens when Access attempts to delete the
original file. The error message states that the file is
read-only; however, the read-only attribute is not checked
for that file. It is also the case that user permissions
are not to blame, as one can easily delete the database
file by hand outside of the compacting process.
Therefore, the crux of the problem is why Access cannot
delete the file.
This happens only on the Network versions, not local
copies of the database .
My conclusion is that Access is getting ahead of itself by
attempting to delete the file prior to actually
relinquishing control of it while compacting, and the
reason it is getting ahead of itself is that these large
database files have to cross over the network. The
network is fast, but there is just enough lag time to
cause Access to think that it can delete the file, yet its
handle to the file is not totally relinquished.
Anyone have a solution to this?
Any help would be GREATLY appreciated.
Thanks, Jay
option "Compact on close" is selected for each of my
database files.
The users open these database files through Microsoft
Access over the network. When they close the database,
the compact utility is automatically triggered. The
result is that Access creates a temporary database file
that is the compacted version of the original file, and
Access then attempts to delete the original file in order
to replace it with this new compacted version.
The problem happens when Access attempts to delete the
original file. The error message states that the file is
read-only; however, the read-only attribute is not checked
for that file. It is also the case that user permissions
are not to blame, as one can easily delete the database
file by hand outside of the compacting process.
Therefore, the crux of the problem is why Access cannot
delete the file.
This happens only on the Network versions, not local
copies of the database .
My conclusion is that Access is getting ahead of itself by
attempting to delete the file prior to actually
relinquishing control of it while compacting, and the
reason it is getting ahead of itself is that these large
database files have to cross over the network. The
network is fast, but there is just enough lag time to
cause Access to think that it can delete the file, yet its
handle to the file is not totally relinquished.
Anyone have a solution to this?
Any help would be GREATLY appreciated.
Thanks, Jay