Allocating when the record is created is much simpler: just invoke an expression like:

SerialNumber("TableName")

in the field's default value. You don't need a thing in your framework!

Numbers can be skipped, as you say (mainly, if the user cancels the record), but that isn't a problem in practice. I have done so for years now.

In the cases where the number is seen by the user (say, an "Invoice number"), and therefore, you don't want to skip numbers, it is better to assign the number when the record is saved, and include it in a transaction, in case the save fails.

>I have encountered a problem with my application framework and would appreciate input from other developers before deciding which way to go.
>
>When allocating a unique identifier (or primary key, usually an integer value) to each new record, is it better to allocate a) immediately the record is created, or b) just before the new record is comitted to the table (eg. using TABLEUPDATE())?
>
>As I see it, with method a) new child records can be added in same 'add' session, and have a parent id value that can be assigned immediately without having to save the parent record first. However, if the new record (perhaps child records as well) is discarded before saving, there will be a gap in the allocated number sequence (not that important IMO). Are there any pros/cons that I need to consider?
>
>For the record I do not use the autoincrement feature in VFP8, I get the next available id for a particular field via a separate control table.
>
>I would be interested to hear how other developers approach this issue.
>
>Many thanks,
>Alan