Using skipDeleteActions with doDelete still calls the delete actions

Recently we came across an issue where running code like this:

    Unit unit;
    select firstonly forupdate unit where unit.UnitId == ‘cl’;

This results in the delete still being called on Tables\UnitConvert (via the cascaded delete action on Tables\Unit).

This is because SkipDeleteActions() only works when using a set based operation (like delete_from) – so if you set it when calling delete() or doDelete() (row based operations) it will not make any difference and the delete actions will still be called – instead you need to use delete_from for this skip property to be respected.

Checking the AX kernel source code around these skip properties, we found something related that was interesting – the skipDataMethods() flag is respected for row based operations, but only if skipDatabaseLog, SkipEvents and skipDatamethods have all been set for that table buffer (and for delete() in addition skipDeleteActions must be set). Originally in AX3 this wasn’t like this – row based operations just ignored these properties.

–author:  Tariq Bell
–editor: Tariq Bell
–date: 18/05/2011
Comments (1)

  1. Joris says:

    This is not surprising at all. I had a case with AX Support in 2009 about RECORDINSERTLIST not skipping the datamethods (although set to skip) when an alert is set on the table you're inserting. This case was open for months, several calls with sustained engineering, and in the end the issue was recognized but refused to be fixed, and the support case was closed.

    Incident number 9597358

    Easy test: set an alert on salesparmtable for example. You'll get a "record already exists" error when opening the posting screen for any sales posting.