Author Topic: ORD.NUM.ASSIGN Bug?  (Read 4968 times)

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
ORD.NUM.ASSIGN Bug?
« on: July 03, 2007, 02:41:09 PM »
The SB+ paragraph ORD.NUM.ASSIGN is used throughout the Prelude app to generate the next sequential order number.  Today, while looking at this paragraph for a customer request, I stumbled across what appears to me to be a bug.  In this paragraph (at least in v19), there is logic to verify that the order key that has been generated does not reference an active order.  Problem is, if your order numbers are anything more involved than a sequential, unpadded number, this check does not work.

When an order number is sequentially generated, an accumulator in a CONTROL record is incremented.  Then, if there are any accoutrements (like padding, prefix, et al.), those are added on and the completed order number is returned in @VALUE.  Before returning this value, the following lines are executed:

READ TEST FROM "ORDER",@PARMS(1)<1>:@PARMS(40)<1>
IF @RTN.FLAG = 1 THEN
  @RTN.FLAG = 0
END ELSE
  GOTO 1000
END

The GOTO 1000 causes a new number to be generated if the order exists in the active order file.  The problem, however, is the key that is being used to read the ORDER record; @PARMS(40)<1> has the sequentially assigned number, but it does not have padding or a prefix.  The completed order number is actually in the common variable @VALUE.  So I'm thinking this line should instead read:

READ TEST FROM "ORDER",@PARMS(1)<1> : @VALUE

Of course, being stock Prelude code I'm not about to go changing it without customer approval, but I figure if any Prelude folks are lurking in here, you might want to give that some attention.  Certainly, because the assignment of order numbers is sequential there's very little chance that this will manifest itself badly under normal circumstances.  However, is something wacky happens and the accumulators get reset for whatever reason, it would be good to know with certainty that this check is working properly.
« Last Edit: July 03, 2007, 04:06:48 PM by precisonline »
-Kevin
Accidents "happen"; success, however, is planned and executed.