Yes, exactly. My "zap" procedure is done once a year.

>Every case is different. :-) But the concept is very good, especially if you add and delete records frequently. Zap should never be used on a regular basis, only for maintenance purposes a few times per year.
>
>>My case is a little different from what you describe. But I thank you for your input.
>>
>>>I fear that you have driven yourself into a corner. Instead of deleting records, you should have a logical field called for instance Reusable. So instead of deleting a record, you set this field to true. And instead of inserting a new record, you first look for a reusable record. This is how for instance SQL server works internally, AFAIK. Something like this

>>>select top 1 pk from mytable where reusable order by reusable into array laPk
>>>if _tally>0 && A reusable record is found
>>>   update mytable set field1=myvalue1, field2=myvalue2, reusable=.T. where pk=laPk
>>>else
>>>   insert into mytable (field1, field2, pk) values (mavalue1, mavalue2, generateGuid())
>>>endif

>>>My pk is always a guid, created by the generateGuid() function. Remember, a Primary key shall not be meaningful, but guaranteed to be unique, which is what guid stands for, Globally Uniqie IDentifier.
>>>
>>>
>>>>Thank you. I will have to figure out a different approach. I will try PACK.
>>>>
>>>>UPDATE: Pack does not work either.
>>>>
>>>>>No. ZAP cannot be used against a buffered cursor/table.
>>>>>
>>>>>>Do you know (of course, I will test it today) if ZAP can be issued against a Cursor Adapter cursor? Because I am trying to avoid opening the table with USE command but rather do everything via CA cursor.
>>>>>>
>>>>>>>After DELETE you'll have table with 10,000 deleted records which can make even SEEK() slow. On other hand ZAP requires exclusive access to the table. I would go with later, if possible.
>>>>>>>>
>>>>>>>>I am opening and updating tables using Cursor Adapter. In one of the procedures I need to zap all records in a table. I can fill the CA cursor with all records, delete records, and then call tableupdate(). But my questions is, how practical this approach if the table can have up to (max) 10,000 records. This is a VFP database (not SQL Server).