Can Compact and Repair be "undone"

[Guest]

I was having an issue with one of my database files that "Compact and Repair"
fixed last time. When I did it this time it "compacted" my table of
approximately 300 entries down to three. Is there any way to get them
back????

 

[Joseph Meehan]

I was having an issue with one of my database files that "Compact and
Repair" fixed last time. When I did it this time it "compacted" my
table of approximately 300 entries down to three. Is there any way
to get them back????

Will back up is always the way. I doubt if you can get them back.
Doing a compact does actually delete the files. Why it deleted those files
would be interesting to know. I have never heard of it doing that. My
guess is you had some corruption of the file to begin with.

 

[(PeteCresswell)]

I was having an issue with one of my database files that "Compact and Repair"
fixed last time. When I did it this time it "compacted" my table of
approximately 300 entries down to three. Is there any way to get them
back????

Dunno about getting them back, but in the future you should use a different
procedure than compacting in place.

What I do:
------------------------------------------------------------------------------
1) Use WinZip to create a .zip archive containing the current version of the DB.
e.g. ReturnsApp.121c.mdb ==> WinZip ==> ReturnsApp.121c.zip

2) Immediately drag/drop/move ReturnsApp.121c.zip to my home directory's
'OldVersions' subdir on a backed-up LAN server.

2) Rename the DB to "x..." e.g. ReturnsApp.121c.mdb ==> xReturnsApp.121c.mdb

3) Open xReturnsApp.121c.mdb using the /Decompile command line argument

4) Compile xReturnsApp.121c.mdb and then close it.

5) Use Database Utilities|Compact-Repair to compact/repair xReturnsApp.121c.mdb
into ReturnsApp.121d.mdb.

6) Move xReturnsApp.121c.mdb. to the trashcan - but only empty the trashcan
occasionally when disk space is getting tight.
-------------------------------------------------------------------------------

Looks kind of unwieldy in writing, sounds obsessive - but it only takes a couple
of minutes and it's saved my sorry butt more than once over the years.

The big thing is to capture the app *exactly* as it is before compacting and
save all the captured versions.

Every so often, you'll come up with a corrupted version that's unrecoverable in
it's current state and which started getting flaky a few (or even many...)
compactions ago. That's where the old versions come in. Sometimes you can
export 98% of the latest version to text files and use them to build a virgin
copy of the app into which you retrieve the other 2 percent from one or more of
the really old/totally uncorrupted versions.

Qualifying development versions with letters lets me keep track of which version
is which from hour-to-hour without unduly incrementing the numbers - which are
tied into documentation as to what changes are in what versions. When I
finally put something into production, I take off whatever letter is there and
kick up the number for the next round of changes.