> >Any examples you can think of?
>
> Sometimes we can't persuade our superiors in the Accounts Dept that they can live without their beloved Auditable Series for product serial numbers, document numbers, etc. As long as we can help them to understand why it's a real dog of an idea to use their auditable numbers as database keys (as they learned in Accountant School in 1954), we can give them an auditable series that has a life of its own.

It least I have convinced my customers that the 'missing
numbers' simply have a database entry that says 'Cancelled'
and now they are happly, especially as I added the ability
to 'Cancel' an entry when THEIR customer rings up to make a
change to an order!

Yes I could process the missing numbers differently, but in
a multi-user system you need to know who is currently
'locking' the stock, even if eventually that allocation is
later rolled back. ( Transactions don't help here,
Multilevel transacation - now there is a wish list item! )

The point is an auditable series could be nice, but it is
application dependent. The correct place to assign it is
when the 'work in progress' is commited, and at that point a
simple generator can provide the number, but I would not
want to burden Firebird with the details of applying it, and
an AUTOINC field would probably get in the way.

All we are talking about for AUTOINC is adding 'macro' code
to a database, I still see it as part of the tools rather
than part of the server. The people requesting it are just
trying to reduce typing, so how ever that code is added
would be acceptable.

The ongoing step of getting the INSERT that populated the
AUTOINC field ( and all other automatic fields ) to return
the populating values is a different wishlist item, and
something that could provide answers to client side
problems. For me, the re-read of the record is fine because
I know it's PK, so I would not rate it a high priority.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services