18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.
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[/code]
followed by the magical [code] Get Request_Validate of hPymts to iRetVal[/code]
Now in some dark place inside the runtime, the record in the tfBalDue gets [B]CHANGED [/B][SIZE=2][SIZE=3]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 [/SIZE]the[SIZE=3] next record in the tfBalDue table. [/SIZE]
[SIZE=3]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. [/SIZE]
[SIZE=3]The "patch" I worked out that seems to cover this up is: [/SIZE]
[/SIZE][code]
[B]Move TFBalDUE.Recnum to iOldRecnum
[/B] Get Request_Validate of hPymts to iRetVal
[B] If (iOldRecnum <> TFBalDUE.Recnum ) Begin [/B]
[B] Move iOldRecnum to TFBalDue.Recnum [/B]
[B] Find eq TFBalDue.recnum [/B][B]
End[/B][/code][SIZE=3][SIZE=2]
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.
[/SIZE][/SIZE]
Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.
There was a runtime patch for something similar to this.
[url]https://www.dataaccess.com/BugTracker/PrintBug.asp?ArticleID=7195[/url]
Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.
That appeared to resolve the issue. I'll need to test further to be sure.
MM.
Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.
is this fix also in 18.2.71.1?
MM.
Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.
Michael,
Yes, did you see my follow on post in the announcement?
[quote]
[COLOR=#333333]There was one minor "oops" in the information provided. Back after the release of 18.2 some developers reported instances of error 4527 under certain circumstances and we changed that in both DataFlex 19.0 and in an updated runtime for DataFlex 18.2 ([/COLOR][URL="https://www.dataaccess.com/BugTracker/PrintBug.asp?ArticleID=7195"]build 18.2.70.0[/URL][COLOR=#333333]). That change is included in the 18.2.71 update.
[/COLOR][/quote]
Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.
Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.
Stephen,
We have been experiencing problems with the 4527 error, cannot refind record, on a table who's record buffer is empty. The table is a child of a parent of the main table being saved. Customer was still on 18.2.69.
We tried updating the 18.2.71, but that has not solved the problem. We have removed the child data dictionary completely, and we still encounter the error. Or should I say, the customers get the error, we still can't duplicate it in our office.
Any ideas?
Thanks,
Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.
This error has turned up now and then, and today I managed to recover it. I have a view with a list of items which need to be ordered from suppliers. Some items are picked from the list and an order is generated for these in a bp. The order is shown on the screen in a separate view. If that order is deleted in that view and a new order is generated from the "item to buy" view, error 4527 occur.
The problem is solved if Send Clear of Orderheader is replaced by Send Clear_All of Orderheader in the bp where the order is generated. However, I have a lot of parallell cases in my program and it is not easy to find them all so I hoped to find a better solution.
The error is described here:
[URL]https://www.dataaccess.com/BugTracker/PrintBug.asp?ArticleID=7195[/URL]
As far as I understand, the problem should have been fixed in vdfvm18.dll ver. 18.2.70.0. I use vdfvm18.dll ver. 18.2.71.0 and I still get the error.
In that article, it is also suggested: "[COLOR=#000000][FONT=tahoma]The best solution is to send clear to the DDO after deleting a record from it to set the DDO back to a defined state and remove any traces of the deleted record from its buffer."
[/FONT][/COLOR]Where should that send clear statement be placed? I tried with Clear Orderline in Delete_Main_File of the order line dd class. It cleared the record buffer, but I still get the error. And how can it be possible to [B]send [/B]clear to [B]DDO[/B] in the class? Do I misunderstand something completely?
Bengt