Comparing xrec and rec in nav 2009 sp1 build 29626

ara3n
ara3n Member Posts: 9,258
edited 2010-06-01 in NAV/Navision Classic Client
I found this issue with 2009 sp1 finsql.exe with build 29626. xRec and Rec are the same in onmodify trigger when validated from code. It works when manually modified from form.


My code looks at follows.

On purchline onmdify trigger()

if xRec."Direct Unit Cost" <> "Direct Unit Cost" then
Error('Direct Unit Cost value has changed.');



My code in CU

Purchline.get("Document type","No.");
Purchline.validate("direct Unit Cost",23);
Purchline.modify(true);

The error is not triggered.

Anybody knows why?
Ahmed Rashed Amini
Independent Consultant/Developer


blog: https://dynamicsuser.net/nav/b/ara3n

Comments

  • ara3n
    ara3n Member Posts: 9,258
    It works on another computer where nav was installed. In the server where this happens the client was installed but nav was started from a local folder.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • ta5
    ta5 Member Posts: 1,164
    Hi Rashed
    xRec and Rec are the same if not triggered from GUI. Isn't that always the problem? I guess, I have seen this before.
    Regards
    Thomas
  • lvanvugt
    lvanvugt Member Posts: 774
    Thomas, you are fully right. See also my blog post Validating Data #5: Data- and XMLports, which in a way touches to same issue.
    Luc van Vugt, fluxxus.nl
    Never stop learning
    Van Vugt's dynamiXs
    Dutch Dynamics Community
  • ara3n
    ara3n Member Posts: 9,258
    you are right.

    I had removed the code to check xrec and rec.

    Was this a recent change in the executables?
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • lvanvugt
    lvanvugt Member Posts: 774
    No, it has always been like this.
    Note: removing the code checking Rec against xRec might bring cause unwanted behaviour in some instances. Be sure you really want to do this. This kind of check: 
    IF xRec."..." <> ".." THEN
    in general is done, to only execute code when the user really has changed the value. If the user has retyped a valu (so actually it stays the same) the code will not be executed.
    Luc van Vugt, fluxxus.nl
    Never stop learning
    Van Vugt's dynamiXs
    Dutch Dynamics Community
  • ara3n
    ara3n Member Posts: 9,258
    Yes I know this wasn't standard code. I twas my own code that was comparing xRec to Rec.


    It's been a while that I have built a mod that compared Rec to xRec. But this should behave the same way if you are entering an order or creating the record through code. The whole point of validating the field is that you are ensuring that same business logic is run.

    I'll have to report this MS.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • ara3n
    ara3n Member Posts: 9,258
    I've put it as suggestion.

    https://connect.microsoft.com/dynamicss ... ous-record
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • lvanvugt
    lvanvugt Member Posts: 774
    Good initiative, but I am not sure it really makes sense as probably a lot of code has been written to take this behaviour into account.
    Luc van Vugt, fluxxus.nl
    Never stop learning
    Van Vugt's dynamiXs
    Dutch Dynamics Community
  • ara3n
    ara3n Member Posts: 9,258
    This will be an issue going forward especially using webservice.

    You want to guarantee that the same logic is run when creating a record manually or through code validating the record and calling

    modify(True);
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • lvanvugt
    lvanvugt Member Posts: 774
    True. Maybe you should provide that info on your msconnect post.
    Luc van Vugt, fluxxus.nl
    Never stop learning
    Van Vugt's dynamiXs
    Dutch Dynamics Community
  • Belias
    Belias Member Posts: 2,998
    i was stuck about a modification on tracking lines (too hard to explain): the tracking specification was not behaving correctly during the creation of the double reservation entries when entering a transfer order exit...some time later, i've seen standard code that compared xrec and rec, and i suddendly remembered a post talkin about xrec...thanks a lot guys, i did a bad workaround to solve my problem, and now i can fix it correctly! \:D/
    -Mirko-
    "Never memorize what you can easily find in a book".....Or Mibuso
    My Blog
  • lvanvugt
    lvanvugt Member Posts: 774
    Great! And thanx for the feedback as these things are good to know.
    Luc van Vugt, fluxxus.nl
    Never stop learning
    Van Vugt's dynamiXs
    Dutch Dynamics Community
  • jflynn
    jflynn Member Posts: 34
    If I key a new order from “sales&marketing” , “order processing”, “orders” the system is reflecting the payment discount.

    If I key a new order from “sales&marketing” , “sales”, “customer” and here you choose in the customer card menu item “sales” and “order” then hit F3 for insert, the system is not reflecting the correct payment discount.

    During debugging I found that inserting a new order this way, xRec was actually equal to another order and this code in the Sales Header.Payment Terms Code OnValidate
    would cause unpredictiable results depending on the "bogus" value is xRec.

    IF xRec."Document Date"="Document Date" THEN
    VALIDATE("Payment Discount %",PaymentTerms."Discount %")
    END;

    As a work around, I modified the Sales Header on Insert trigger and added this line afer
    InsertMode := TRUE;
    //
    xRec := Rec;
    //

    I was able to duplicate this in Cronus NAV 2009 sp1. You have to be in the debugger to see that xRec is different the Rec because of the date logic in Cronus.

    Any pros or cons on this temporary fix would be appreciated.

    Joe
    Joe

Categories