Microsoft Dynamic AX 2009 : .Performance (part 4) - Transaction Performance - Set-Based Data Manipulation Operators - The delete_from Operator

3.1.3 The delete_from Operator

The delete_from operator is similar to the insert_recordset and update_recordset operators in that it parses a single statement to the database to delete multiple rows. The following X++ code shows the deletion of all sizes for an item.

static void DeleteSizes(Args _args)
{
    InventSize  inventSize;
    ;
    ttsbegin;
    delete_from inventSize
        where inventSize.itemId == '1000';
    ttscommit;
}

This code parses a statement to SQL Server in a similar syntax to DELETE <table> WHERE <predicates> and executes the same scenario as the following X++ code, which uses record-by-record deletes.

static void DeleteSizes(Args _args)
{
    InventSize  inventSize;
    ;
    ttsbegin;
    while select forupdate inventSize
        where inventSize.itemId == '1000'
    {
        inventSize.delete();
    }
    ttscommit;
}

Again, the use of delete_from is preferred with respect to performance because a single statement is parsed to the database, rather than the multiple statements that the record-by-record version parses.

Like the downgrading insert_recordset and update_recordset operations, the delete_from operation could also be downgraded, and for similar reasons. Downgrade occurs if any of the following is true:

• The table is entire-table cached.

• The delete method, the aosValidateDelete method, or the aosValidateRead method is overridden on the target table.

• Alerts have been set up to be triggered by deletes into the target table.

• The database log has been configured to log deletes into the target table.

Downgrade also occurs if delete actions are defined on the table. The Dynamics AX application runtime automatically handles the downgrade and internally executes a scenario similar to the while select scenario shown in the preceding example.

You can avoid downgrades caused by the previously mentioned functionality, unless the table is entire-table cached. The record buffer contains methods that turn off the checks that the application runtime performs when determining whether to downgrade the delete_from operation. Here are the skip descriptions:

• Calling skipDataMethods(true) prevents the check that determines whether the delete method is overridden.

• Calling skipAosValidation(true) prevents the checks on the aosValidateDelete and aosValidateRead methods.

• Calling skipDatabaseLog(true) prevents the check that determines whether the database log is configured to log deletion of records in the table.

• Calling skipEvents(true) prevents the check that determines whether any alerts have been set to be triggered by the delete event on the table.

The preceding descriptions about the use of the skip methods, the no-skipping behavior in the event of downgrade, and the concurrency model for the update_recordset operator are equally valid for the use of the delete_from operator.