🚀 go-pugleaf

Hi Francesco,

Sure the mechanism i wrote in my previous mail needs a lock on the table. In
the application we are working on we do heavy use of table locks to compute
progressive numbers like the "fattura" one (i think fattura is "invoice" in
english, yes i'm italian). I know that the procedure that computes the
invoice progressive number permits to a user lo take a number adding the row
to the invoice table. This permits to release immediately the lock on the
table itself.
In the same way other users can take their number. If a user releases the
number (for example because he changed his mind about the invoice) he may
create an hole into the sequence of numbers. This hole can be filled by a
subsequent number request by another user, given that we are working on the
same day. If we go to the next day and there are holes in the numbering of
the documents here it starts an automatic recovery procedure that alerts the
users and performs corrections. Sure this is a particular case, because
invoices are actually processed after few days, so we can do modifications
to the numbering before the real process. (The application is really huge
and the server cannot lose time doing too much coherence testing, better do
this in the new day session). If you don't have these needs you sholud
always solve the consecutive numbering problem. The MAX+1 or generator
method seems to me to be the better since now, and sure you need to lock the
table to perform the query and to add the new row. But if your users can
delete what they've created, you must find something like what i told you...

Ciao... Umberto Uderzo

"Formentz" <francesco@leotron.com> ha scritto nel messaggio
news:3b456e91$1_2@dnews...
> Hi Umberto,
> here there is the same problem, I'll have to lock the table before using
the
> query you wrote, because if there are 2 readings before the row has been
> inserted, 2 new records will have the same id, and then one will be
rejected
> by the index.
> Another thing, I don't know how to translate 'fattura' in english, but you
> are italian (aren't you? :-), and you surely know what I mean.
> This fattura must have consequent numbers and consequent dates, so I can't
> have a fattura with previous number but later date, and this should be the
> case if a previous number is picked with a later date.