Kbase 21610: Why NO-ERROR Option Appears To Fail With CREATE Statement
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/16/2008 |
|
Status: Verified
SYMPTOM(s):
** <file-name> already exists with <field/value...>. (132)
Sometimes the NO-ERROR option of the CREATE statement appears to fail to trap errors.
CAUSE:
The cause of the errors, is an attempt to create two records with the same unique index values. This solution explains the expected behavior using a 4GL programming example.
FIX:
Consider the following code:
DEFINE TEMP-TABLE ttable
FIELD cField AS CHARACTER
INDEX iField IS UNIQUE PRIMARY cField.
CREATE tTable NO-ERROR.
CREATE tTable NO-ERROR.
MESSAGE ERROR-STATUS:ERROR VIEW-AS ALERT-BOX.
You might incorrectly expect the NO-ERROR option of the second CREATE statement to set the ERROR-STATUS:ERROR System handle attribute to TRUE and find it puzzling when that does not happen.
Since the two CREATE statements succeed just fine, the NO-ERROR option has no reason to trap a non-existing error. Thus, the ERROR-STATUS:ERROR is not set to TRUE.
What fails in the example is the indexing of the created records not the creating itself. The indexing on the first statement happens when the second CREATE bumps the first created record out of the record buffer, and it then gets written to the database table. This succeeds because there are no index uniqueness violations yet.
The second CREATE also is not indexed until it is written to the database (since no fields were changed). But it does not get written to the database table until the transaction scope ends, which in this case is the entire program. So, at the end of the program, we bump out the second created record, it fails indexing, and the indexing error message gets generated to indicate this indexing failure:
** <file-name> already exists with <field/value...>. (132)
NOTE: this behavior is the same whether we use a TEMP-TABLE or a regular database table.