Insert(true) vs Insert() - Using TRUE what's the difference and use cases

samantha73samantha73 Member Posts: 94
edited 2021-06-04 in NAV Three Tier
Hi Guys
I have seen both codes where some people use for Insert and Modify: true. Apparently from what I understand true invokes triggers but what I don't understand is when to use and when not to. For example, creating new order standard code is below, what's the benefit of true here on Insert/Modify?:

SalesHeader."Document Type" := SalesHeader."Document Type"::Order;
SalesHeader."No." := '';
SalesHeader.VALIDATE("Sell-to Customer No.",CustNo);
SalesHeader.VALIDATE("Location Code",LocCode);
SalesLine."Document Type" := SalesHeader."Document Type";
SalesLine."Document No." := SalesHeader."No.";
NextLineNo := NextLineNo + 10000;
SalesLine."Line No." := NextLineNo;
SalesLine.INSERT(TRUE); //Run Trigger Code
SalesLine.VALIDATE("Location Code",LocCode);
SalesLine.VALIDATE("Unit Price",UnitPrice);


  • Developer101Developer101 Member Posts: 523
    INSERT(TRUE) and MODIFY(TRUE) will execute the code in the oninsert and onmodify trigger of the tables respectively. So any code in the triggers will be executed when creating sales header and sales lines, in your case sales order. Having TRUE will execute the code on the triggers making sure the same logic executes when sales order is being by the code as by manually by the user. If you omit TRUE then the logic behind the triggers wont execute and sales order will be created without the checks.
    United Kingdom
  • bbrownbbrown Member Posts: 3,268
    In the case of Sales Header (and other documents), that OnInsert trigger calls the "No. Series" logic. That first INSERT(TRUE) above is used to assign the "No." value to the new record.

    There are no bugs - only undocumented features.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    A simple rule, is that if you don't know if you should use the TRUE or not, then use TRUE. As you progress you will learn where you can leave it out.
    David Singleton
  • bbrownbbrown Member Posts: 3,268
    David's comment also applies to VALIDATE on fields.
    There are no bugs - only undocumented features.
  • TheJBirdTheJBird Member Posts: 15
    A simple rule, is that if you don't know if you should use the TRUE or not, then use TRUE. As you progress you will learn where you can leave it out.

    Fully agree on this.

    Always go for "TRUE" by standard. It's only if you explicitly don't want to run this code, then you run with FALSE (or leave out).
  • samantha73samantha73 Member Posts: 94
    Thanks for all the replies ..I think I do know where to start... some say a little bit of knowledge is a dangerous thing :).. and will experiment a bit most things it's one thing to read the documentation and another to apply correctly. Where I see you don't need TRUE/Validate is when writing to custom tables or wonders about the performance hit using TRUE and validate if you are inserting a huge amount of records
  • DenSterDenSter Member Posts: 8,304
    Don't think of performance, because having incomplete transactions is a WAY bigger problem than having to wait half a second for a shipment to post. You can fix performance issues in other ways. Whether you run the triggers or not has nothing to do with whether you are in a standard or custom table.

    OnValidate triggers are used for getting related data into other fields. The decision to validate or not is when you want to take care of those in your code yourself. For instance, you can validate a City field and that pulls in post code and such. If you are setting those fields yourself, there is no need for calling the validation trigger.

    Same as Insert(true) or Modify(true). Those triggers do things and the only reason why you would NOT run them is when you are doing those things in your own code.

    You'll get different opinions here though, I've had very heated discussions about this topic. Some ppl will vehemently say to NEVER run triggers, where I say you should absolutely run them as much as possible. For instance, validating the Quantity on the Sales Line will calculate amounts and discounts and such. If you don't validate, you will have to program that calculation yourself.

    My approach is to first do a task manually, and then do it in code. Creating a new Sales Order for instance. You open the page with a blank record, and as soon as you leave the No field, it inserts the order with a new number from the number series. That's the first 4 lines in the code you posted. Validate the Customer and the Location pulls in all sorts of important information. That's just three more lines of code. In 6-7 lines of code, you have a complete sales order, all you need to do is add some lines. I don't see any reason why anyone would ever program all of that.

    Here's a good tip: turn on the debugger and do things in BC. Step through the code to get a feel for what it does.

Sign In or Register to comment.