Thanks Dan,

On the Add form, when the user clicks the Add button the row is added. An
EEP is run "After Saving Row" which updates the PO number. This is some old
and not very elegant but it's been working for quite a while at a number of
plants. (The user is allowed to change the next available PO number to
something else. Note: Incrementing a number as shown below is not mutli
user friendly.) 


-- PONUM.EEP  Assign the Next Available Number to PO's
--
IF SEL3 = "1" AND CFPONUM > "0" THEN
 SET ERR MES OFF;SET BELL OFF
 SET VAR CKPONUM INT;SET VAR CKPONUM = .VCFPONUM
 SET V VERR = .VDERR
 SET ERR MES ON;SET BELL ON
 IF VERR = 0 THEN
  IF CFPONUM = .VCFPONUM THEN
   UPD CONFIG SET CF_PONUM =(CF_PONUM + 1)
  ELSE
   SET V XMSG =(.VCFPONUM & "Out of Sequence. Use Anyway?")
   DIA .XMSG ANS VLAST YES AT 10
   IF ANS = "YES" AND VLAST = "[ENTER]" THEN
    UPD CONFIG SET CF_PONUM =((INT(.VCFPONUM)) + 1)
   ELSE
    UPD CONFIG SET CF_PONUM =(CF_PONUM + 1)
   ENDIF 
  ENDIF
 ENDIF
 SET VAR CFPONUM =(CTXT(CF_PONUM)) IN CONFIG
ENDIF
RETURN

>>>

Dennis
*****


At 06:18 AM 1/24/2004 -0800, you wrote:
>Maybe if you could post your code that creates the po we could give you some
>advice.
>
>Sometimes someone else might point out something that you missed. It has
>happened to me!!
>
>Dan
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dennis
>Fleming
>Sent: Friday, January 23, 2004 6:32 PM
>To: RBASE-L Mailing List
>Subject: [RBASE-L] - Re: Why we love this job
>
>
>Ben/Dan,
>
>I actually clear a required field on Add so you can't add twice unless you
>reenter a Vendor ID. Since the hardware guys always blame the s/w guys, I
>usually tell the user it must be a bad NIC card and the "add request" is
>looping in the faulty comm card. Hmmm. That must be it!
>
>Dennis
>*****
>
>
>At 07:06 AM 1/23/2004 -0800, you wrote:
>>Dennis,
>>
>>I'm sure you've thought of this, but the only time I've experienced
>>similar is when something (or my own frail logic <g>) wouldn't let a
>>routine break out of a loop.
>>
>>Or maybe your user just had his finger depressing the left mouse
>>button for a few minutes while he took a call        ;-)
>>
>>Ben Petersen
>>
>>On 22 Jan 2004 at 20:19, Dennis Fleming wrote:
>>
>>> This is one I haven't seen before, and why the world of programming is
>>> always so "exciting"
>>>
>>> Mutli user Runtime 6.5++
>>> At this location about six work stations. A user adds a purchase order
>and
>>> the system "locks up". When they come back in, the application has added
>>> PO's number sequentially from 3000 to 6000. As though the user clicked
>the
>>> Add button 3000 times. The application increments a counter in the db for
>>> the next PO number, but I am stumped on this one.
>>>
>>> Ran Reload and Autochk, and no errors.
>>>
>>> Any ideas?
>>>
>>> Dennis
>>> *****
>>> Dennis Fleming
>>> IISCO
>>> http://www.TheBestCMMS.com
>>> Phone: 570 775-7593
>>> Fax:   570 775-9797
>>>
>>
>>
>>
>Dennis Fleming
>IISCO
>http://www.TheBestCMMS.com
>Phone: 570 775-7593
>Fax:   570 775-9797
>
>
>
Dennis Fleming
IISCO
http://www.TheBestCMMS.com
Phone: 570 775-7593
Fax:   570 775-9797

Reply via email to