>>>>>>-- 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