>>>Hi everybody,
>>>
>>>AFAIK there is no way in multi-user environment to have ID field incremented correctly without using extra table to keep the last ID (if we're not using autoincrement field). Using go bottom, grab the last number and start from there doesn't prevent two users from taking the same ID. Even if we put a check right after for the existance of ID.
>>>
>>>What do you think? Given only one table and no auto-increment is it possible to correctly auto-increment in multi-user environment?
>>>
>>>Thanks.
>>
>>This maybe a little weak, but at least you do not have to lock the entire table.
>>
>>

>>LOCAL i, nRecNo
>>GOTO bottom             && start at the bottom
>>DO WHILE NOT RLOCK()    && try to lock the record
>>    DOEVENTS            && if failed, try again
>>    GOTO BOTTOM         && always stay at the bottom, the next time it maybe a new record.
>>ENDDO
>>i=id                    && got the lock, get the its ID
>>nrecno=RECNO()          && remember the record number
>>INSERT INTO temp VALUES (i+1,"Test")      && insert new record with new ID
>>UNLOCK RECORD (nRecNo)  && unlock old record
>>

>>
>>Unlock the old record after inserting the new record to prevent the other users from using the same ID as you.
>
>The current mechanism is to put the table in the order, go bottom (BTW, using IDX), grab the last ID, if the record is deleted, don't increment, otherwise increment. I was thinking if locking the bottom record would be sufficient in this scenario and I don't think so...

I see. Well, I just pulled off the top of my head at the moment.

Personally, I think using a secondard table to hold the last number used is a safer and better way to go. The reuse of deleted number can cause problem in the real world. Just because it was deleted in the computer does not mean it does not still exist in paper form elsewhere.