Make sure DELETE IS ON before the SORT to scratch.dbf

>As others suggest, periodic packing is good. There are some things that can be done when that maintenance. You can rebuild the index headers and physically sort the table on its primary key. The users can do it every couple of weeks - whats a few moments to clean up the files. ChkDsk on my XP takes an hour.
>

>close data
>use MyTable exclusive
>delete tag MyMainKey
>sort on MyMainKey to scratch
>zap
>append from scratch
>index on MyMainkey tag MyMainkey
>use

>For the other tags, just delete and index - sort or your work-horse key only.
>HTH
>
>
>If you don't delete the tag and "INDEX" it again - you're not really cleaning the header. "REINDEX" does not rebuild the header. Just as there is value in running ChkDsk (even if no errors occur), there is value in discrete low[er] levels of DBF maintenance. My users have not reported corrupted files (for a long time now) - and the only thing I can point to is a well maintained network and this "old fashion" xbase script.
>AND IT JUST TAKES A FEW MINUTES (if not just a few seconds) - Go to a P4 and it's less than a second!
>
>>Traditionally I have handled by data files as .dbf. i.e. when adding records I would use append, when deleting I would delete and pack.
>>
>>I am now in a project where the data file could be very large in the order of 100,000 records. I am aware that delete/pack starts to become very time consuming with large data files.
>>
>>I have never used Select SQL for my data management. Would the various features of Select SQL permit deleting records more quickly than delete/pack ?
>>
>>Mike Smith