Kbase P178166: Index assignment delayed when value doesn't change from INITIAL
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/02/2011 |
|
Status: Unverified
SYMPTOM(s):
Index assignment delayed when value doesn't change from INITIAL
** <file-name> already exists with <field/value...>. (132)
The following code doesn't return the duplicate record error until the third iteration of the loop.
DEFINE TEMP-TABLE ttCust
FIELD CustNum AS INTEGER INITIAL 2
INDEX CustNum IS PRIMARY UNIQUE CustNum.
DEFINE VARIABLE iCount AS INTEGER NO-UNDO.
DO iCount = 1 TO 3:
CREATE ttCust.
ttCust.CustNum = 2.
END.
FACT(s) (Environment):
All Supported Operating Systems
Products / Versions
Progress 6.x
Progress 7.x
Progress 8.x
Progress 9.x
OpenEdge 10.x
CAUSE:
This is expected behavior because the initial value of the indexed field is not being changed, therefore the index manager is not actually assigning the values to the index until the buffer is released on the subsequent execution of the CREATE statement.
FIX:
In order to avoid this problem one should use the RELEASE <buffer> or VALIDATE <buffer> statements after the value is assigned to the field and implement some form of error handling to avoid allowing the user to see the resultant error.