Chuck,

1) Scatter is doing nothing, unless there is code later which gathers this data. Since this is a record you are recycling, you should not need to gather the OLD data.

2) If SET DELETED ON then you will never find a deleted record. I just checked it (VFP6, SP3)

3) If you are planning to recycle deleted records then definitely add an index on Deleted(). Locate will find the index and use it.

4) If you aren't getting errors with TableUpdate() then you must have buffering on. Check the code where you load the tables (Data environment? Load() event?) to see what the buffering type is. You may also need to check the form buffering, as the data environment defaults to form buffering.

5) How are you assigning IDs? When you get duplicates are they blanks or duplicates of 'real' IDs?

Barbara


>That's why I am asking, is SCATTER doing nothing here?
>>I'm not sure what the 'SCATTER' is doing. You might check the "Blank" command to blank all fields in the recalled record.
>
>I thought that even with SET DELETED ON would still allow LOCATE FOR DELELTED() to locate a deleted record?
>>Don't forget that if Set Deleted is ON that you will never find a deleted record - something I've forgotten on occasion.
>
>There are no index for the deleted, just using the Primary key on the ID field. Yeah, I have been getting errors since this coding sometimes cause dupe records for some reason.
>>I'm assuming that you either have a very small file or an index on deleted() since you're using 'LOCATE'.
>
>
>I am using =TableUpdate(.T.) (in the Save button) and =TableRevert(.T.) (in the Revert button), so is that RECORD OPTIMISTIC buffering?
>>You don't mention if you're using buffering at all. If you are not, then you are running a serious risk of having 2 records with blank ID fields because 2 users have clicked the ADD button at the same time. Buffering is a GOOD THING and (IMHO) should always be used.
>
>So, how does this code look? Is it too simple or need more revision? Again, thanks for the reply.
>