MS Access Multiuser - Can't delete file after compacting it.

Author

Can't delete file after compacting it.

Sirocco

2005-04-07, 8:04 pm

Here's an interesting and completely unexpected problem I didn't see
discussed on this thread, but this seems to be the right thread: I just
added a new form to my mdb file, which is opened by a new click button, and
it works just fine. When I close the form and immediately close the
database, the database goes through the compact/repair process as desired
but the uncompressed copy of the database can't be deleted by Windows - I
get an Access error message to this effect, and the compacted version is
named "db1". This is then followed by a "Dr. Watson" application error and
the application closes. I never even knew that during compaction, the
uncompacted version is deleted and then replaced by a compacted version of
the same name.

Anyway, what's weird is that I've been developing/using this database for
several years, in a 20-user XP environment, and this is just another day at
the office. I add/modify things all the time, with no problems. The
database file is not read-only, although it seems that the Archive checkbox,
which is ordinarliy unchecked, is becoming checked - would this keep it from
being deleted? (And why is it becoming checked off?) And the form I
added is like others in the database, with no code other than that used to
close the form. This was a simple, ho-hum, no frills change to the file.

Another detail: the problem only happens if I edit any one of the fields on
the new form. If I open the new form, but then immediately close it, then
close the database, no problem. I included a "Refresh" in the form
closing, so it's simply Refresh, then close form. Why would editing a
field in a form, then closing the database, and compacting it, affect the
permissions of that file, or whatever, so that Windows can't delete the
uncompressed file AND cause a Dr. Watson error???

All this applies to the same front end running on an NT or XP machine.

Any comments or advice would be much appreciated.

tina

2005-04-08, 7:02 am

sounds like your new form, or the database itself, is corrupted. also sounds
like you have a monolithic database (meaning not split into frontend and
backend) on a server with multiple users using it at the same time. that
setup is an invitation to corruption, and if you have been lucky enough to
avoid it in the past, that's not a guarantee that your luck will continue -
in fact, it may have run out already.

recommend that you don't continue to enter data into a database that cannot
be compacted without generating errors. you can try creating a new blank
database, and importing all the db objects *except* the form that's causing
problems. then compact and repair the new database. if successful, back up
the db, then recreate the new form from scratch in the new database - while
you have it open exclusively, so nobody else can access it.

strongly recommend you split the database into a fe/be. be (tables) remains
on the server; each user gets a copy of fe, linked to the be tables, on
his/her PC (usually as a .mde file). then you can easily and safely modify a
"master" copy of the fe to your heart's content, replacing the user copies
as needed. (if i got the wrong clues from your post, and you *do* have a
fe/be setup already, just disregard the comments directed at that issue.)

hth

"Sirocco" <NB2002@arczip.com> wrote in message
news:uiahkT6OFHA.3336@TK2MSFTNGP10.phx.gbl...
> Here's an interesting and completely unexpected problem I didn't see
> discussed on this thread, but this seems to be the right thread: I just
> added a new form to my mdb file, which is opened by a new click button,
and
> it works just fine. When I close the form and immediately close the
> database, the database goes through the compact/repair process as desired
> but the uncompressed copy of the database can't be deleted by Windows - I
> get an Access error message to this effect, and the compacted version is
> named "db1". This is then followed by a "Dr. Watson" application error
and
> the application closes. I never even knew that during compaction, the
> uncompacted version is deleted and then replaced by a compacted version of
> the same name.
>
> Anyway, what's weird is that I've been developing/using this database for
> several years, in a 20-user XP environment, and this is just another day
at
> the office. I add/modify things all the time, with no problems. The
> database file is not read-only, although it seems that the Archive
checkbox,
> which is ordinarliy unchecked, is becoming checked - would this keep it
from
> being deleted? (And why is it becoming checked off?) And the form I
> added is like others in the database, with no code other than that used to
> close the form. This was a simple, ho-hum, no frills change to the file.
>
> Another detail: the problem only happens if I edit any one of the fields
on
> the new form. If I open the new form, but then immediately close it, then
> close the database, no problem. I included a "Refresh" in the form
> closing, so it's simply Refresh, then close form. Why would editing a
> field in a form, then closing the database, and compacting it, affect the
> permissions of that file, or whatever, so that Windows can't delete the
> uncompressed file AND cause a Dr. Watson error???
>
> All this applies to the same front end running on an NT or XP machine.
>
> Any comments or advice would be much appreciated.
>
>
>
>

Sponsored Links