>>>>>>>-- snip --
>>>Bret:
>>>I like to use Primary keys that are invisible to the user, and therefore do not depend on user input in any fashion. Certainly you need to have a field with your 'massaged' item_no data for indexing purposes, but does this really need to be your primary key? You can have multiple indexes, after all, and use them in different places.
>>>
>>>The biggest problem I see is that this field will remain blank after a new record is added until the user enters the correct item_no and then the data is re-entered (in the valid() event?) into your key field. If 2 users add records close together, the second may be trying to add a record with an empty key field when one already exists.
>>>
>>>Barbara
>>Would pessimistic row buffering avoid an error here? I think my colleagues are pessimists about such things anyway.
>
>Bret, I don't think pessimistic buffering would help, because a second user would be ADDING a record, not ACCESSING an existing record, so there would be no lock. And when they did an APPEND BLANK, they'd still have two records with blank primary keys.
>
>Barbara
You should not be appending into you file until all the information is validated.

The best way that I know of is to enter the information on your form, then when the
data is validated, calculate your id_key ....

SELECT ID_KEY_FILE
DO WHILE NOT FLOCK()
WAIT WINDOW 'Waiting for ID file' NOWAIT
ENDDO

new_id=Id_key_file.last_id+1
REPLACE last_id with last_id+1
UNLOCK

then..

INSERT INTO YourFile VALUES (new_id,Thisform.Data1,Thisform.Data2...)