>>Yes, but VFP won't let that slip. The suggestion I offered was simply to validate upon leaving the textbox. Another step in insuring uniqueness would be to issue a tableupdate() as soon as uniqueness is verified in the textbox. This would rule out the use of Tablerevert and other buffering functions, but you could get around this by using SCATTER before the tableupdate.
>
>Using tableupdate() right after the field is validated in the textbox.Valid would prevent the user from choosing Save or Revert by clicking buttons. Some people here advocate writing your own code, and not relying on your Primary index and RI code, to ensure uniqueness of the key. They say it's better in heavy multi-user environments. The code they write to generate the primary keys takes care of that.

This entire thread underlines why many of us are using ONLY surrogate keys, which can be updated invisibly from a table. Any field the user edits is not included in the primary index. If the user is entering a primary key in a multi-user environment, there is ALWAYS going to be a period of time while the key can be duplicated by another user.

Barbara (now stepping off her soap-box)