>Hilmar,
>
>The reason is that when a user starts a new record and begins editing it, then, is called into a meeting without saving, the transaction is not resolved for quite some time. During that time, if I am not mistaken, there will be a lock on the bottom of the file.
Yes, correct. Well, your problem is also related to primary keys, right? What I do with primary keys is the following.
1) I usually use primary keys that have no meaning to the user - just sequentially assigned by the computer. Therefore, it doesn't matter if a number is skipped. (The function for these sequential numbers is invoked in the field's default value.)
2) For numbers which the user does see (this might be the primary key in your case; for me, it is things like document numbers, which I don't use as the PK), I only assign the number the moment the record is saved. Here, you might briefly use a transaction - this allows you to revert changes in the table which holds your sequential numbers, in case something goes wrong. In this case, I assign the field value from a form method.
HTH,
Hilmar.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)