By holes I mean skipped numbers, as in user A creates a record gets number 100,
before he saves, user B creates a record he gets 101, user A decides to bail out without saving. The Pk table can't put the counter back to 100, because 101 is taken. You can have the Pk generator search this holes but it can be confusing to get lower numbers than the last PO you made, like user B getting 100 after finishing 101.

In general schemes like this are used to generate a unique ID rather than a consecutive number without wholes. Another option is to force the user to save the header (parent) table record before adding any child records, and only assign him a number until he does this. You'd have to take the code out of the DBC's stored procedures into a .prg and call it programmtically in your save method, oh and leave the default value blank for the table.

>yes, that's the problem. what I want is a PO number that increments one time, then stays at that number until I save something to the record with that number, so there are no holes (if my definition of holes is the same as yours).
>
>
>>Most PK generators don't allow you to go back once they've assigned a number, because of issues when dealing with multiple users, it can create holes, are you sure that's not the problem?
>>
>>>I have an incremental number generator (primary key) that I use for a P.O. number. I'm using Optimistic Buffering. The problem is that when I simply exit without saving and enter again, it increments again. The buffer doesn't clear until I close foxpro. what command can i use in the exit click event that will CLEAR THE BUFFER?