Maybe this is what your looking for. Its based on Razzaks sample 8 for 7.1
and our system here.
1. Create a temp table and base you form on it
2. In you code that starts the form based on the temp table do something
like this and base it on the Real table
SELECT (MAX(PONumber)+1) INTO vPONumber INDIC ivPONumber FROM POHeader
3. Then somewhere in your code before you start your form do an INSERT in
the temp table and start the form
INSERT INTO tPOHeader +
(PONumber,PODate,POTime,POVendorID) +
Values +
(.vPONumber,.#DATE,.#TIME,.vVendorID)
4. When you leave the form check to make sure the number is still good. If
the number is still good Append the temp table to the real table if not
get the next number run an update and then append and exit the form
SELECT (MAX(PONumber)+1) INTO vPONumber2 INDIC ivPONumber2 FROM POHeader
IF vPoNumber2 = vPoNumber then
APPEND tPoHeader TO PoHeader
ELSE
UPDATE tPoHeader SET PoNumber = .vPoNumber2
APPEND tPoHeader TO PoHeader
ENDIF
On 8 Jun 2004 at 11:06, ELOEN wrote:
> Larry,
>
> My small experience is that NEXT function is good choice in a multi
user
> environment, but I have not used it with real deletions.
> My only experience were consecutive, bank cheque numbers with an added
> check digit. In my case I had to use a table with all the values of
cheques
> in order to relate them with the payments. So what I 've done was to lay
on
> UPDATE .. WHERE ... AND LIMIT = 1 to a table with all the given,
continue,
> *ordered* range of values.
> A number was occupied if it had the right columns filled.
> Also to avoid the -unavoidable miss of the UPDATE execution I had it
> repeated, if an error was after the execution.
> A deletion cleans the right fields and gives it back to *first* use.
> (After some time I changed this: In case of user error it was better to
> clean the fields but to "give the number for use" at the end of the
day,
> together with a daily report)
>
> In your case, if your goal is only a consecutive number with no other
> implication, I would use NEXT function, have deleted numbers to a table
> handled by INSERT, SELECT and DELETE and also a daily routine to check
the
> integrity of consecution.
>
> Just some thoughts
>
> Polychronis Kontos
> Athens, Greece
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> > Lawrence Lustig
> > Sent: Monday, June 07, 2004 10:33 PM
> > To: RBASE-L Mailing List
> > Subject: [RBASE-L] - Re: Consecutive numbering
> >
> >
> > > Would you have to limit access to the table to a
> > > single user at a time, at
> > > least in a multi-user environment? This would be to
> > > assure that no 2 users
> > > hitting the table simultaneously get the same
> > > number, if that's possible, as
> > > well as other potential problems related to many
> > > users accessing the table.
> >
> > There's no guarantee that this would be true, and I
> > have to allow for simultaneous entries on different
> > machines more or less at the same time.
> >
> > I believe the NEXT() function should handle conflicts,
> > taking out the necessary short term lock on the
> > AUTONUM column in my dummy table.
> > --
> > Larry
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Friends. Fun. Try the all-new Yahoo! Messenger.
> > http://messenger.yahoo.com/
> >
>
>
Victor Timmons
Tiz's Door Sales, Inc
425-258-2391
