Options

NAV 2013 R2 Changecompany is not working

connamicsconnamics Member Posts: 11
edited 2015-07-17 in NAV Three Tier
Hello together,

we made a Upgrade from NAV 2009 R2 to Nav 2013 R2 everything is working, but i try to test our individual Client Programmins. In this Function we Copy Records from one Company to another. For this we use the Standard Function CHANGECOMPANY and Transferfields. The function is calling from the System, i tracked it step by step over the Debugger, but in the Destination Company nothing is inserted.

??????
Has anybody more Information regarding the Function CHANGECOMPANY() in NAV 2013 R2 ?

Comments

  • Options
    TomH_DKTomH_DK Member Posts: 13
    Hi,
    I have just tested the CHANGECOMPANY at NAV 2013 R2, by a simple code copying a customer from one Company til another, and it Works fine.


    Customer_loc.CHANGECOMPANY('CRONUS TRIMIT 2013 Test BASIS');
    Customer_loc := Rec;
    Customer_loc.INSERT;
    MESSAGE('Copied.');
  • Options
    geordiegeordie Member Posts: 655
    Is your environment single or multiple tenant? In case of multiple, are both companies in the same tenant?
    Did you try using the boolean return value as a check?
  • Options
    connamicsconnamics Member Posts: 11
    Hello together,

    thanks for your tests and answer. I found the Problem.

    CustomerRec.Changecompany(Companyname);
    CustomerRec.Transferfields(Rec);
    IF NOT CustomerRec.INSERT THEN
    CustomerRec.MODIFY;

    This Code are not working. The last 2 Lines.
  • Options
    davmac1davmac1 Member Posts: 1,283
    Why are you using transferfields? There have been problems reported with transferfields in the past.

    The recommendation you received was to make newrec:=Rec.
    Seems nice and simple.
  • Options
    connamicsconnamics Member Posts: 11
    Thanks everybody.

    @BlackTiger

    CustomerRec.CHANGECOMPANY(Companyname);

    The Variable Companyname is a Parameter from the Funkction.
  • Options
    MauddibMauddib Member Posts: 269
    Just for anyone who comes across this thread while looking for this error like I was.

    TRANSFERFIELDS used with CHANGECOMPANY appears to be a problem in 2015, but not 2009. If you use TRANSFERFIELDS with the second parametre set to FALSE, the problem goes away.

    Why this is I do not know, but there is clearly some difference between how 2009 and 2015 respond to the TIMESTAMP field in SQL at the time of MODIFY. Adding the FALSE parameter seems to work so I am now doing this in my code base - I just hope there are no consequences of this not detailed in the manual :)
Sign In or Register to comment.