Bulk Database Operations Recordset D365FO/AX 2012

 

Recordset operations or set based operators



We all noticed that AX 2012 and D365FO get slow from time to time when we performed insertion or update operations on huge numbers of records one by one, and to overcome this issue, Microsoft has a feature to update or insert in bulk in a single statement.
 
We have 3 types of Bulk Operations
  • insert_recordset
  • update_recordset
  • delete_from

insert_recordset :


insert_recordset copies data from one or more tables directly into one resulting destination table on a single server trip. Using insert_recordset is faster than using an array insert. However, array inserts are more flexible if you want to handle the data before you insert it.

insert_recordset is a record set-based operator, which performs operations on multiple records at a time.

Syntax :


The list of fields in the destination table must match the list of fields in the source tables.
Data is transferred in the order that it appears in the list of fields.
Fields in the destination table that are not present in the list of fields are assigned zero-values as in other areas in X++. System fields, including RecId, are assigned transparently by the kernel in the destination table.

insert_recordset DestinationTable ( ListOfFields )

select ListOfFields1 from SourceTable [ where WhereClause ]

[ join ListOfFields2 from JoinedSourceTable

[ where JoinedWhereClause ]]

Example : 


The records, "myNum" and "mySum", are retrieved from the table another table and inserted into the table myTable. The records are grouped according to "myNum", and only the "myNum" records with a value less than or equal to 100 are included in the insertion.

insert_recordset myTable (myNum, mySum)
    select myNum, sum(myValue)
        from anotherTable
        group by myNum
        where myNum <= 100;


update_recordset :

The X++ SQL statement update_recordset enables you to update multiple rows in a single trip to the server. This means that certain tasks may have improved performance by using the power of the SQL server.

update_recordset resembles delete_from in X++ and to UPDATE SET in SQL. It works on the database server-side on an SQL-style record set, instead of retrieving each record separately by fetching, changing, and updating.


If the update method is overridden, the implementation falls back to a classic looping construction, updating records one by one just as delete_from does for deletions. This also means that the construction works on temporary tables, and whole-table-cached tables by using the looping construction.

Example :

MyTable tableBuffer;
;
update_recordset tableBuffer
setting field1 = field1 * 1.10;

delete_from :

You can delete multiple records from a database table by using a delete_from statement. This can be more efficient and faster than deleting one record at a time by using the xRecord.delete method in a loop.


If you have overridden the delete method, the system interprets the delete_from statement into code that calls the delete method one time for each row that is deleted.

Example :

static void DeleteMultiRow1aJob(Args _args)
{
    MyWidgetTable tabWidget;
    ;
    delete_from tabWidget
        where tabWidget .quantity <= 100;

}

But these set-based operations will roll back to row-by-row operation when either of the following condition is true:

  • it is not an SQL table (Eg. temporary table)
  • Database log is enabled for the table
  • Alert is set up for this table
  • Record level security is enabled for the table
  • AOSValidation method is overwritten

when using insert_recordset
the .insert() method is overwritten

when using update_recordset
the .update() method is overwritten

when using delete_from
the .delete() method is overwritten
DeleteAction is defined



To prevent it from fallback to row-by-row operation, the following method can be used if:

  • Delete action is defined, use skipDeleteActions
  • Database log is setup, use skipDatabaseLog
  • Alert is setup, use skipEvents
  • Method is overloaded (.insert(), .update, .delete()), use skipDataMethods



Support Faryal's Cusine


Difference Between Replacement key, Alternate key, Surrogate key in AX 2012 and D365FO


  Replacement key, Alternate key, and Surrogate key



WHAT IS A REPLACEMENT KEY INDEX?

While a surrogate key is great for lookup and database performance, it is not useful for the end-user because it gives no indication of the table’s purpose, or what related tables it is linked to. For this reason,  Dynamics 365 Finance & Operations has added the ‘Replacement Key’ index property for tables. The replacement key index is a dropdown of alternate keys that have been specified for the table. There can be any number of alternate keys for a table but only a single replacement key. More than one field can be specified under a replacement key, and it is these fields that will be displayed to the end-user on a form instead of the surrogate key field.

A replacement key is an alternate key that the system can display on forms instead of a meaningless numeric primary key value. Each table can have a maximum of one replacement key.


The replacement key is chosen by setting the ReplacementKey property on the table. The drop-down list offers every alternate key as an available value.

WHAT IS AN ALTERNATE KEY?

A table can have any number of alternate keys. An alternate key may be a natural key or a single field primary key used in foreign or primary key relations with other tables. In either case, to set one, the user must create a new index and then set AllowDuplicates to “No” and AlternateKey to “Yes”. If AllowDuplicates is not set to “No” then AlternateKey should be greyed out and uneditable

WHAT IS A SURROGATE KEY?

In Dynamics 365 Finance & Operations, a surrogate key is the auto-generated primary key for a table in the database. The surrogate key is linked to the already existing RecId field within any table. This means that the surrogate key is a unique 64-bit integer value that is mandatory for the table and cannot be changed or have duplicates. The fact that it is a 64-bit integer (int64) value means table operations normally perform faster than other types of fields such as string fields. This is the main strength of surrogate keys.

Support Faryal's Cusine


Virtual Fields Vs Computed Fields

  Virtual Field: A virtual field in D365FO is a field that doesn't have a direct representation in the database. It's a field that y...