Grid Control New features

 Grid Control New features

Fast data entry: 

This feature lets users enter data in a grid ahead of the server. Therefore, it minimizes the need for users to wait for the server to validate one row in the grid before they move to another row. Users can also paste copied tables from Excel directly into grids in the system.

Mathematical formulas:

Users can now enter mathematical formulas into numeric cells in a grid. For example, you can enter =15*4. To make the system recognize a value as an expression, start the value with an equal sign (=).

General improvements:

Various enhancements have been made to improve the usability of the grid. For example, in the existing grid, users might run into situations occasionally where the grid headers and data are misaligned, or the grid jumps while users scroll through data or create new records. These issues do not occur with the new grid control.

Reorder columns:

Users can now reorder columns by dragging them. Hover the mouse pointer over the column header and then drag the gripper control that appears on the left side of the column.

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