Kbase 17136: Possible Reason for kmdiscon (130) Error in 8.2 and above.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/15/2008 |
|
Status: Unverified
FACT(s) (Environment):
Progress 8.2x
SYMPTOM(s):
SYSTEM ERROR: kmdiscon - key changes pending. (130)
CAUSE:
This run-time error can be caused by code that references a default database or temp-table buffer in a user-defined function (UDF)
The following code, when executed, will cause error 130 in any Progres 8.2x client. It will also cause the error if the customer table is replaced with a temp-table.
def var v_ix as int no-undo.
function get-cust-name returns char.
find last customer no-lock no-error.
return (if available customer then customer.name + "A"
else "A").
end.
do v_ix = 1 to 10:
create customer.
assign customer.cust-num = 100 + v_ix
customer.name = get-cust-name().
end.
The error comes up because the function is attempting to change the record in the Customer buffer while a change to an indexed value (in this case, Customer.cust-num) is pending. One of the main purposes of a multi-element
ASSIGN statement is to defer index updates in this way.
Prior to Progress 8.2, it was not possible to change the contents of the record buffer in this way. With the introduction of UDFs it is now possible, and a new set of potential coding bugs are available.
FIX:
The workaround is to use a local buffer for the function. In practice, except where global side-effects are desired, programmers should *always* use local buffers for table access in internal procedures and UDFs. This applies to both database tables and temp-tables.