Hi David,

Basically it's the same technique, applied a little differently. The concept of making a copy of the data before you attempt to remove the deleted rows is the major point here. PACK can't handle that.

Only problem I see with what you suggest is the possible "bloat" of the DBC with all the additional (albeit temporary) tables. I might consider copying the files to a new database, possibly also maintaining the links -- somehow. Anybody else have some thoughts here?


>Hi Evan:
>
>I was searching through the VFP help index, and I came up with another alternative method for safe handling of deletions.
>
>First of all, I did have a few problems using the Copy To command, primarily because my tables are part of a DBC. The relational links between my tables seemed to get broken for some reason. However, I was able to relink everything. In one case, the index seemed to become corrupted. I probably did something wrong or missed a step or two.
>
>Anyway, I experimented with the COPY FILE command, and find this to be an easier solution for me. First, I duplicate the dbf, fpt, cdx, and dbc files and give them different extensions. For example, I can duplicate customer.dbf and rename the duplicate to customer.db1 or customer.bak (or anything else). This way, I only have to write one command. For example: Copy File *.DBF To *.Db1
>This command will duplicate all .dbf files, but change the extensions to DB1. I do this for every data file (dbf,fpt,cdx,dbc,dct,dcx), giving each file type a different extension (for example: duplicate fpt files could end with .FP1). This has the effect of making a backup copy of all of my tables and the database container files. After I make these duplicate files, I issue the pack command on the original files. If something fails or corrupts during pack,
>I can delete the original database and tables, and rename the extensions of the duplicate files to the original VFP extensions. This will in effect restore my original and uncorrupted database. This entire process is very conservative as far as the amount of necessary coding.
>
>The only drawback is that you end up with a complete duplicate of your database, which can take up a lot of space. However, the duplicates can be deleted after one is sure that the PACK did not do any damage. I prefer to have clients run the delete routine on an infrequent basis, and just let the deletions hang around for a while (especially if there are not many of them). Fortunately, the deletions can be ignored with SET DELETED ON. I usually have a screen which indicates how many deletions are waiting for removal. This way, a client can determine when it's necessary to reduce the file size.
>
>Anyway, the above is a possible alternative for PACK enthusiasts. There maybe drawbacks to it that I have not thought of, since I just thought this up tonight...:)
>
>Dave