Thanks Jim,
The locking description is too vague, I think. It starts by saying "Perform an insert or append operation", but since 4 rows later it says "append operation completes", it should, at least say "BEGIN an insert...". It does not specify where the reading of the current value occurs, i.e. is it before or after the header lock. The first thing the insert process should do is to not allow any other insert to start, and the start is to me the read of the current autoinc value.
Doru

-

>Doru,
>
>Here are 2 bugs I found that *might* be related:
>From the VFP8SP1 fix list
>- Using the APPEND FROM command with an autoincrementing field now generates new values for this field. New values are automatically generated in sequential order based on the last generated value. This occurs regardless of whether the APPEND FROM or APPEND FROM ARRAY command includes values specified for the Auto Increment field.
>
>From the VFP9SP2 fix list
>- VFP8: It is possible to force update of an AUTOINC field in appended record.
>
>Also, for the record, here`s how the record locking was described when AUTOINC was first introduced:
>"When you turn on autoincrementing for a field, the start and incremental values, Next Value and Step, are stored in the table (.dbf) header in the unused or reserved portion of the field subrecord for the specified field. Next Value is stored as a 4-byte integer. The Step value is stored as a 1-byte integer with a maximum value of 255. The value actually used to increment the field value is the sum of the value stored in the .dbf header and the incremental value. The operation sequence occurs as follows:
>• Perform an insert or append operation.
>• Lock header.
>• Increase the currently stored increment value by the Step value and apply to the field.
>• Store the new value, which is the value of the newly added record, in the .dbf file header.
>• Unlock header when insert or append operation completes. The header contains the last incremented value.".
>
>cheers
>
>
>>>>Gaps occur in normal scenarios, but we have a case with duplicate autoinc keys in one of our apps. This was more a test for autoinc, and I will probably revert to assigning the key from our key registry. Do you know when you'd get duplicate keys with autoinc?
>>>
>>>I've no idea.
>>
>>Do you think caching could create autoinc duplicates?