On 04/10/2012, at 6:45 AM, Chuck Hill wrote:
I'm not one of those people, and I did consider that. What I've done instead is used the opportunity to look at ERXSequence and NativeDatabaseSequence in particular. This is one of those perennial "invoice number" situations, where all I really need is an increasing integer sequence. Integer primary key fit that bill, and I was happy to double up on it, but I'll probably use an additional native database sequence instead.
I would NOT be in favour using the PK as in invoice number. That IS offensive! :-P
Heh. I guess it depends on your requirements for an invoice number.
The PKs generated by EOF are not guaranteed to be an unbroken sequence.
No, but they're guaranteed to be unique, which would be sufficient—for me, anyway. If the _unbroken_ sequence (by which I assume you mean "no numbers missing") is important, then you'd need something more sophisticated than a native database sequence anyway, wouldn't you? Say I generate an invoice which I need to scrap—it has too many mistakes in it, and it's easier to delete than edit. Then I've lost that number in the sequence and can't get it back.
So, what's your beef with sparse sequences for invoice numbers (some local tax/legal issue?), and just out of interest, how would you solve the problem then?