>>I think this code would be extremely dependent on whether the file was fragmented or not. If the file is fragmented, there's no guarantee that the next physical sector would contain data that used to belong to the file.
>
>I don't think so Fred. If the PACK was run and there's now a .BAK file, it may have been written by the operating system as a non-contiguous set of chunks. The operating system figures out which chunk contains byte # whatever as the file is traversed. This must be the case or no non-contiguous word document could be re-streamed into it's original form.
>
>Be that as it may, if the pack has been done and there is now a .BAK file, it should be a simple matter to rename the .bak to .dbf and append the "deleted" records back into the new file.
>
>I avoid all such low-level manipulations of the DBF and the CDX like the black plague. It's difficult enough to ensure data integrity now, without some low-level hacking going on.
>
>I also don't believe giving the user the ability to delete is safe. It's better to manage record deletion and recovery using a datetime field. Then delete anything over a year old and pack - only as maintenance activities.
>
>That way records that might have been maliciously "deleted" by some user of the application are still there, and under our control, not the users.

I think you're right, this would have to work on the .BAK file, as the "new" file may would have no way to perceive the packed records that are no longer in the new file. (I think this is what I first stated in this thread)