Im not sure what you mean by concurrent selects. The first select happen
before you enter the form then you do a bunch of stuff and then you close
the form. The whole thing would be something like this.
--YourFileName.RMD
--SET YOU VARS
SET VAR vWhatEver INTEGER = NULL
SELECT (MAX(PONumber)+1) INTO vPONumber INDIC ivPONumber FROM POHeader
INSERT INTO tPOHeader +
(PONumber,PODate,POTime,POVendorID) +
Values +
(.vPONumber,.#DATE,.#TIME,.vVendorID)
EDIT USING YOURFORM NAME
--Do Some Stuff
IF vButton = 99 THEN
GOTO DONE
ENDIF
LABEL DONE
--CHECK TO SEE IF NUMBER IS STILL GOOD
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 your form you have a close button with a eep that reads
-- Button.EEP
-- RAZZAK
CLS
SAVEROW
SET VAR vButton = .%1
CLOSEWINDOW
RETURN
and you fire of this eep like this
Button.EEP USING 99
I think Dennis has a good idea.
I hope that helps. If not well I gave it a try. Have a good one
On 9 Jun 2004 at 13:29, ELOEN wrote:
> Victor,
>
> for my understanding and correct me if I am wrong, step 4 is
inaccurate, as
> in a multi-user environment 2 concurrent selects COULD produce undesired
> insert of a PONumber (and a TransID in "RRBYW8 / Enter new Sales Order"
as
> well).
>
> So here goes the usefulness of NEXT function or UPDATE command, that can
> take this role because they are made to hold these "multi user" cases.
>
> Polychronis
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> > Victor Timmons
> > Sent: Tuesday, June 08, 2004 5:44 PM
> > To: RBASE-L Mailing List
> > Subject: [RBASE-L] - Re: Consecutive numbering
> >
> >
> > 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
> >
>
>
Victor Timmons
Tiz's Door Sales, Inc
425-258-2391
