A piece of code that's been running for years, just blew up, presumably because it's the first time the customer has hit this code since they upgraded to 18.2.
I have a very boring Generic/ While (found) and (this) and (that)) loop.
The outer loop is on a table called "tfBalDue" it's a temp table with open payments to post.
Inside this loop the system posts data to the "Payments" table. Again, boring, normal code. tfBalDue and Payments are in no way related. (they share the values in the Account# field, but are not related
There is a bunch of
Code:
Set Field_Changed_Value of hPymts Field Payments.PI_Total_Due to TFBDue.Bal_Due
followed by the magical
Code:
Get Request_Validate of hPymts to iRetVal
Now in some dark place inside the runtime, the record in the tfBalDue gets CHANGED all out of the blue. After "request_assign" is called from the "Notes" DD between one statement and the next BOOM! it just randomly finds the next record in the tfBalDue table.
This in turn causes my simple While (found) loop to go into a race condition, where it runs away and repeatedly posts the same transaction a bazillion times, until they hit the power button on the PC.
The "patch" I worked out that seems to cover this up is:
Code:
Move TFBalDUE.Recnum to iOldRecnum
Get Request_Validate of hPymts to iRetVal
If (iOldRecnum <> TFBalDUE.Recnum ) Begin
Move iOldRecnum to TFBalDue.Recnum
Find eq TFBalDue.recnum
End
This covers this up, and will get the customer working again on Monday. BUT i really want to know WHY this happened.
DAW, Do you have any suggestions? it happens in the runtime. and I have no way to narrow it down any further.
If nothing else, I'll demonstrate it in person at Synergy.