>>>>>Hi,
>>>>>
>>>>>I'm having some trouble attempting to APPEND or INSERT INTO a table contained in a DATABASE. The table has a primary key and I've deleted some of the previous records and then when I attempt to add new ones that might have the same key as some of the deleted ones, I get the UNIQUENESS OF KEY VIOLATED error. I believe DELETED is set off. The only way I can get this to work is to PACK the table, but then I have to open it exclusivly, and that poses some problems sometime.
>>>>>
>>>>>Has anyone delt with this before in a good way?
>>>>
>>>>Jim
>>>>
>>>>One way is to erase the contents of a 'deleted field' and re-use the existing field. Just basically fakeing the user to thinking it is a new record. It is sometimes called 'recycling'.
>>>>
>>>>HTH,
>>>>Tom
>>>
>>>This is not exactly the solution for his problem. Because the uniqueness is violated because the key already exists in another deleted record.
>>>
>>>Vlad
>>
>>You did not understand. You 're-cycle' the record. Since you need to use that key again you just blank out the rest of the fields and re-use the record. This is one way of doing it, not the only way but it let's you use that key without packing the table.
>>
>>Tom
>
>Yes, but in this case you must look first if there is a deleted record with the same key. If not, you must search once again for a deleted record. I don't say it's not good, but I think it can be done with just one seek for a deleted record, unless there is a good reason to recycle keys. (Usually it must be faster to look for a deleted record than to look for a specific key.)
>
>Vlad

Depending on how you generate a key value (there are several ways) if you truely want to make sure it is Unique you need to seek() to be sure it is unique first before you create it in the primary field. Random generation by VFP is 99% reliable but that 1% can bite you hard. So, it all boils down to the circumstance, not the general methodology. If you increment (which some people say is the only way) from a stored counter you don't have to worry about this. Anyway....

Tom