Kbase P86563: STOP + Error 76 in log file because of FIND table WHERE INT(table.charField)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
7/8/2004 |
|
Status: Unverified
FACT(s) (Environment):
Progress 9.1D
SYMPTOM(s):
STOP condition occurs on client side
** Invalid character in numeric input <character>. (76)
error 76 message not shown on client side
error message 76 only shown in the database log file
Progress 9.1D09
Remote connection to database (client server using -S)
NEGATED SYMPTOM(s):
Shared memory connection to database
CAUSE:
A stop condition is raised because something similar to the code bellow has hit a record with a value that could not be converted to integer:
FIND table WHERE INT(table.charField) = <integerExpression> NO-ERROR.
The fact that error 76 is not reported to the client side with a remote connection (using -S) is considered as a non expected behavior, which has been reported to development.
However, the fact that a STOP condition is raised despite the usage of the NO-ERROR option is an expected behavior by design. Indeed, in this case, the point that fails is not the FIND Statement itself but the evaluation of the WHERE clause. You can compare this case with a RUN myProg,p NO-ERROR that cannot catch a STOP condition that would occur because myProg.p cannot be compiled (with a 4GL syntax error in it).
FIX:
The following code allows to catch the STOP condition, however, it does not help the client side to catch the error number (76) because the error has not been passed back from the _mproserve remote server (as explained above):
DO ON STOP UNDO, RETRY:
IF RETRY THEN DO:
MESSAGE "stop condition" SKIP
ERROR-STATUS:GET-MESSAGE(1) /* reports error 76 only with shared memory connection*/
VIEW-AS ALERT-BOX INFO BUTTONS OK.
LEAVE.
END.
FIND customer WHERE INT(customer.name) = 1 NO-ERROR.
END.
Now, since doing "FIND customer WHERE INT(customer.name)" results in a WHOLE-INDEX situation, you should better do a FOR EACH without the condition in the where clause, then test at each iteration if you can convert the field to INTEGER (with a ASSIGN NO-ERROR and test ERROR-STATUS:ERROR) and if the result is compliant with what you need. If not then to NEXT. With will result in the same performance and you wil be able to handle this error without raising a STOP.