Kbase P24362: Error 132 occurring more frequently after upgrading from 9.1C to 9.1D
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  24/02/2010 |
|
Status: Verified
SYMPTOM(s):
Error 132 occurring more frequently after upgrading from 9.1C to 9.1D
** <tablename> already exists with <value>. (132)
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
CAUSE:
Although there can be an increased occurrence of this error in 9.1D, it is not a bug.
Error 132 is caused by 4GL coding whereby the code is possibility trying to create a second record using the same Unique key that another record is already using.
It may be assumed that the code should run fast enough that it will not hit this situation. However, with increased load on the machine there is an increased chance that this error could occur.
For example. If you have a piece of code within a database trigger that is assigning the unique value but is using a technique like this:
DEF VAR i AS INT NO-UNDO init 10000000.
REPEAT:
if not can-find(first customer where customer.custnum = i) then leave.
i = i + 1.
END.
ASSIGN customer.cust-num = i.
It's possible under high load that you could get two users trying to assign the same customer number.
FIX:
Re-code your application to use a Sequence instead of trying to determine which is the last value used. Using a Sequence you will ensure that you are the only person who can have that value. e.g:
DEF VAR i AS INT NO-UNDO init 10000000.
REPEAT:
assign i = NEXT-VALUE(MySequence)).
if not can-find(first customer where customer.custnum = i) then leave.
END.
ASSIGN customer.cust-num = i.