✏️ Explanatory Question

What is the difference between insert/update/delete and their doInsert/doUpdate/doDelete counterparts in Dynamics 365 Finance & Operations? When would you use them, and what do skipDataMethods and skipDatabaseLog do?

👁 1 Views
📘 Detailed Answer
🟢 Easy
← Previous What are the key best practices for writing select statements in X++? Cover the use of field lists, firstOnly, group by, exists join, and why you must avoid method calls in the where clause and nested selects in loops.
💡

Answer with Explanation

D365 F&O • X++ INTERVIEW

doInsert / doUpdate / doDelete & Skip Methods in Dynamics 365 Finance & Operations

Question 27 — Bypassing overridden CRUD logic responsibly and skipping database log / data methods.

Interview Question

What is the difference between insert/update/delete and their doInsert/doUpdate/doDelete counterparts in Dynamics 365 Finance & Operations? When would you use them, and what do skipDataMethods and skipDatabaseLog do?

Model Answer (Short)

The standard insert(), update() and delete() methods run all the business logic on a table — validations, overridden code, and framework hooks. The doInsert(), doUpdate() and doDelete() methods perform the same database operation but bypass any overridden logic, writing straight through the kernel. You use them when you deliberately want to skip that logic — for example, updating only a few add-on fields without re-triggering the full standard update(). For set-based operations, skipDataMethods bypasses overridden CRUD methods, and skipDatabaseLog avoids writing to the database log when logging isn't needed for that operation.

Detailed Explanation

Standard vs. do* methods

  • insert/update/delete — run overridden logic, validations and framework behaviour.
  • doInsert/doUpdate/doDelete — perform the raw DB operation and bypass overridden method code.
  • Use do* methods when you intentionally want to skip the overridden logic (e.g. update only an add-on field).
  • Use them with care — skipping validations can create inconsistent data if misused.

Skip methods for set-based operations

  • skipDataMethods(true) — bypasses overridden insert/update/delete during bulk operations, preventing the row-by-row fallback.
  • skipDatabaseLog(true) — skips the database log for that operation when logging isn't required.
  • Related helpers include skipEvents() and skipAosValidation() for events and AOS validations.
  • Call these on the buffer before the set-based statement to keep it truly set-based.
RULE OF THUMB
Skip overridden logic = do* / skipDataMethods  •  Skip logging = skipDatabaseLog

Prerequisites (Rule 5)

  • Visual Studio with the Dynamics 365 developer tools.
  • A custom model / package for your objects.
  • Awareness of the table's overridden methods, database log settings and validations.
  • A transaction scope (ttsbegin/ttscommit) around the operation.

Code Example — doUpdate to skip overridden logic

AbcOrderHeader header;

ttsbegin;
select forUpdate header
    where header.OrderId == 'ORD-0001';

if (header)
{
    // Update only an add-on field WITHOUT re-running the overridden update()
    header.AbcSyncFlag = NoYes::Yes;
    header.doUpdate();   // bypasses the table's overridden update()
}
ttscommit;

skipDataMethods on a set-based update

AbcStagingTable staging;

staging.skipDataMethods(true);   // ignore overridden update() -> stays set-based
staging.skipDatabaseLog(true);   // do not write to the DB log
staging.skipEvents(true);        // do not raise data events

ttsbegin;
update_recordset staging
    setting Processed = NoYes::Yes
    where staging.Processed == NoYes::No;
ttscommit;

doInsert for a straight-through insert

AbcStagingTable staging;

ttsbegin;
staging.LineNum   = 1;
staging.Processed = NoYes::No;
staging.doInsert();   // inserts without running the overridden insert()
ttscommit;

Standard vs. do* vs. Skip Methods

Approach Runs overridden logic? Scope Typical use
insert/update/delete Yes Single record Normal CRUD with full logic
doInsert/doUpdate/doDelete No Single record Skip overridden logic deliberately
skipDataMethods No Set-based (bulk) Keep bulk ops truly set-based
skipDatabaseLog N/A (skips logging) Single or bulk Avoid DB log overhead when safe

Points the interviewer wants to hear

  • do* methods perform the DB op but bypass overridden method logic.
  • Use them to update add-on fields without re-triggering the standard method.
  • skipDataMethods keeps set-based operations from falling back to row-by-row.
  • skipDatabaseLog avoids DB log overhead when logging isn't needed.
  • Use all of these carefully — skipping validations can corrupt data.

Likely Follow-up Questions

  • What is the risk of using doUpdate() instead of update()?
  • Why does skipDataMethods matter for update_recordset?
  • When is it safe to call skipDatabaseLog?
  • How do do* methods relate to the set-based fallback conditions?

Key Takeaway

Use doInsert/doUpdate/doDelete to perform a database operation while bypassing overridden logic, and skipDataMethods / skipDatabaseLog to keep bulk operations set-based and log-free when appropriate — always weighing the risk of skipped validations.

D365 F&O Interview Series — Question 27 of many
← Previous What are the key best practices for writing select statements in X++? Cover the use of field lists, firstOnly, group by, exists join, and why you must avoid method calls in the where clause and nested selects in loops.