>>Luckily, I never actually needed this (therefore no code, no testing, just an excercise of mind), though it was real close at the time.
>
>My way:
>I have a config table wich stores the next invoice number in a field (next_inv). The program works like this
>1. The user presses add button
>2. The program returns the next_inv number with no further validation s, AND shows a message: "provisional"
>At this point, all the users that intend to create a new invoice are presented with the same value (current next_inv value), but advertised the number is not "Real"
>3. The user fills all fields. if decides to cancel, nothing happen. the next_inv field remains unchanged; it hasn't been touched yet.
>4. When a user decides to save, then lock the config file, get the real next_inv number, assign it to the invoice's number field and increment. While this is happening, no other user could assign the same number as the current, and we're sure that this user won't abort. Once incremented, release the file and let the other users fight for it in order to get their real numbers.
>5. Once saved, change the message from "Provisional" to "real" or simply "".
>
>It assures no gaps and real numbers assignment in an scenario where you don't use the temporary number as a key to maintain a relation with a grid or something. If that is the case, you should solve the problem of changing the provisional number for the real one when saving.

That's what I'd use if I could explain to my users why there's a provisional and real number. Luckily, as I said, I have went around this problem so far. Issuing the actual number at Save sure solves the matters and keeps things simple. Well, I guess all the complicated theory I've stated is probably just a reserve, because if I had an user where such a thing would be necessary, I'd surely enforce such a rule ("you'll get the invoice number when you finish it") and explain it with some high tech system reasons. Unfortunately, I have no users who issue more than ten invoices a day ;(.