Results 1 to 8 of 8

Thread: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Feb 2009
    Location
    Queens, NY, NY
    Posts
    7,429

    Default 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
    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.

    Michael Mullan.
    Danes Bridge Enterprises.

    ++++++++++++++++++++++++++++
    There is just today. Tomorrow is a concept
    that is mostly theoretical. -- GM Wylie
    ++++++++++++++++++++++++++++

  2. #2
    Join Date
    Feb 2009
    Location
    Hengelo (NL)
    Posts
    1,891

    Default Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.

    There was a runtime patch for something similar to this.
    https://www.dataaccess.com/BugTracke...ArticleID=7195

  3. #3
    Join Date
    Feb 2009
    Location
    Queens, NY, NY
    Posts
    7,429

    Default 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.
    Michael Mullan.
    Danes Bridge Enterprises.

    ++++++++++++++++++++++++++++
    There is just today. Tomorrow is a concept
    that is mostly theoretical. -- GM Wylie
    ++++++++++++++++++++++++++++

  4. #4
    Join Date
    Feb 2009
    Location
    Queens, NY, NY
    Posts
    7,429

    Default Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.

    is this fix also in 18.2.71.1?

    MM.
    Michael Mullan.
    Danes Bridge Enterprises.

    ++++++++++++++++++++++++++++
    There is just today. Tomorrow is a concept
    that is mostly theoretical. -- GM Wylie
    ++++++++++++++++++++++++++++

  5. #5
    Join Date
    Jan 2009
    Location
    Richmond, VA
    Posts
    5,854

    Default 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?

    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 (build 18.2.70.0). That change is included in the 18.2.71 update.
    Best regards,

    -SWM-

  6. #6
    Join Date
    Feb 2009
    Location
    Queens, NY, NY
    Posts
    7,429

    Default Re: 18.2 Bit me. Request Validate -> Request_assign -> new record in unrelated buffer.

    No, but thanks!
    Michael Mullan.
    Danes Bridge Enterprises.

    ++++++++++++++++++++++++++++
    There is just today. Tomorrow is a concept
    that is mostly theoretical. -- GM Wylie
    ++++++++++++++++++++++++++++

  7. #7
    Join Date
    Feb 2009
    Location
    Fresno, CA, USA
    Posts
    181

    Default 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,
    Isaac Davidian
    Datatech

  8. #8
    Join Date
    Feb 2009
    Posts
    1,039

    Default 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:
    https://www.dataaccess.com/BugTracke...ArticleID=7195

    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: "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."

    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 send clear to DDO in the class? Do I misunderstand something completely?

    Bengt

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •