The past posts (post 1, post 2, post 3, post 4) about performance focused on RecordInsertList class. This class is very usefull to boost performance, but there are some situations when records have relationships, where this class may not fit very well. For example, imagine that you have two tables: ParentFoo and ChildFoo. Suppose that ChildFoo has a field called ParentFooRecId (I guess I don t need to explain what this field is for :p ). Notice that in this scenario, you will be unable to use the RecordInsertList, because this RecordInsertList can just hold elements of one type. Besides in order to insert the ChildFoo records, you must have the ParentFoo record id.

Unit of Work

This pattern maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems. (Martin Fowler blog) A simple definition of Work means performing some task.  From a software application perspective Work is nothing but inserting, updating, and deleting data. For instance let’s say you have an application which maintains customer data into a database. So when you add, update, or delete a customer record on the database it’s one unit. In simple words the equation is. 1 customer CRUD = 1 unit of work (Article from codeproject)

While using applications, we are doing a lot of database operations behind the scenes: inserting new elements, deleting and updating existing ones. It may be expensive to perform a datatabase call for each of the changes required. In order to reduce this overhead, we can use Unit of Work pattern. The pattern is quite simple, somehow it will keep track of the changes that are being made and at some point, all the changes will be made at once at the database.

Accordingly to MSDN magazine, the Unit of Work responsabilities are:

• Manage transactions.
• Order the database inserts, deletes, and updates.
• Prevent duplicate updates. Inside a single usage of a Unit of Work object, different parts of the code may mark the same Invoice object as changed, but the Unit of Work class will only issue a single UPDATE command to the database.

Back to dynamics AX world, there are some points that you must keep in mind

• Server tier is required
• Requires optimistic concurrency
• Database transaction is implicit and automatic
• Does not bypass record level security
• Does not support temporary tables

You can find another post about employing UnitOfWork in Ax at daxmusings blog

Example

Lets create a table called FooParent which just has three fields: ParentId, Name and Description. Then, lets create another table called FooChild that contains four fields: ChildId, Name, Description and FooParent. Please, see the below picture.

 Notice that a relation has been created at the FooChild table. This relation is mandatory in order to use the Unit of Work pattern. Now it is time to test two different approaches: calling many insert statements through a loop versus using Unit Of Work pattern to control the insertion

So, lets write a method at a class that will insert 10k record of FooParent and 10 records of FooChild though a naive loop.

public class FooController
{
}

public static server void insertThroughManyInsertCalls()
{
    FooChild  child;
    FooParent parent;
    int i;
    
    for (i = 0; i < 10000; ++i)
    {
        parent.ParentId = int2str(i);
        parent.Name = 'Any name for parent' + int2str(i);
        parent.Description = 'Any description for parent' + int2str(i);
        parent.insert();
        
        child.ChildId = int2str(i);
        child.Name = 'Any name for child' + int2str(i);
        child.Description = 'Any description for child' + int2str(i);
        child.FooParent = parent.RecId;
        child.insert();
    }
}

And lets write a job that call this method.

static void ManyInsertCalls(Args _args)
{
    FooController::insertThroughManyInsertCalls();
}

 And what is going on if we look at trace parser???

  Well, 20k database calls and almost 5 seconds to execute them seems like a big waste. Lets rewrite the code using Unit of work pattern.

public static server void insertWithUnitOfWork()
{
    FooChild   child;
    FooParent  parent;

    // Instantiating the UnitOfWork.
    // Notice that this method runs on server
    UnitofWork unitOfWork = new unitOfWork();
    int i;

    for (i = 0; i < 10000; ++i)
    {
        parent.ParentId = int2str(i);
        parent.Name = 'Any name for parent' + int2str(i);
        parent.Description = 'Any description for parent' + int2str(i);

        child.ChildId = int2str(i);
        child.Name = 'Any name for child' + int2str(i);
        child.Description = 'Any description for child' + int2str(i);

        // You will just be able to call this method if there is a relation
        // called FooParent at FooChild table
        child.FooParent(parent);

        // Marking these buffers to be inserted by UnitOfWork
        // The buffers are not being inserted at the database right now.
        unitOfWork.insertonSaveChanges(parent);
        unitOfWork.insertonSaveChanges(child);
    }

    // Finally, asking UnitOfWork to insert the records at the database.
    unitOfWork.saveChanges();
}

 I don t believe this piece of code has worked, what is trace parser saying?

Indeed the magic happened!!!

Although the number of insert calls remain 20k, the time fall down from 5 seconds to 1.5 seconds. Now we are more than 3 times faster than the naïve approach that calls the insert statement 20k times through a loop.

If we look at trace parser, we can see that UnitOfWork insert statements are faster than calling the insert many times.

Summary

This post has briefly explained a very simple usage of UnitOfWork pattern in Ax 2012. This pattern may be very useful and safe to be employed in many situations. We have a meaningful performance improvement without hurting good principles.

Feel free to download and test the project that is attached to this post.

Finally, remember that:

1. UnitOfWork must run on the server tie
2. The child must have a relation explicity defined in AOT to the parent
3. No record will be inserted into the database until the saveChanges method is called.
4. You can enjoy the methods: insertOnSaveChanges, deleteOnSaveChanges, updateOnSaveChanges, saveChanges

UnitOfWork.xpo

So far, during my previous posts (post 1, post 2, post 3), we realized how to use RecordInsertList with regular and temporary tables on Ax. Before covering a new theme on performance, I would just like to highlight the behavior of the add and insertDatabase methods.

I suppose that you would not think that some calls to the add method do execute insert transactions on the database. The call to insertDatabase assures that all the buffers added to the list will be inserted, so, it will probably execute a bunch of other insert statements in order to have all the buffers inside SQL Server, as promissed by the API.

Depending on the feature you are implementing, you may want to use ttsBegin and ttsCommit to avoid that in case of exceptions or any unexpected problem, that some records will be inserted while others not.

Behind the scenes, the add method execute the bulk insert as soon as the number of records being hold by the list achieves a specific value. The math to calculate this value will depend on the server buffer size that has been configured at Dynamics Ax Server Configuration and on the size of the buffer records themselves.

Example 

Before you call me a liar, lets see a practical example using ours MyInvoice table (sorry for not choosing Foo table). In the below code, you can see that I have added 10k buffers to the list, but insertDatabase method has not been called. Then, a select count is executed against the table and the result is printed at infolog. Surprisingly, infolog shows that 9940 records exist in the database. These records have been successfully inserted by the add method.

static void callingAddManyTimesWillInsertSomeRecords(Args _args)
{
    int              i;
    MyInvoice        myInvoiceRecord, insertedRecords;

    RecordInsertList invoicesToBeInserted = new RecordInsertList(tableNum(MyInvoice));

    delete_from insertedRecords;
    
    for (i = 0; i < 10000; ++i)
    {
        myInvoiceRecord.InvoiceAmount = (i + 1) * 100;
        myInvoiceRecord.CurrencyCode = 'REA';
        myInvoiceRecord.Qty = (i + 1) * 10;
        myInvoiceRecord.InvoiceId = int2str(i + 1);

        invoicesToBeInserted.add(myInvoiceRecord);
    }

    select count(RecId) from insertedRecords;
    
    info(strFmt('Although insertDatabase method has not been called, there are %1 registers in db', 
                insertedRecords.RecId));
}

Is add method inserting the register at the database for every call? If you have read my previous posts, you know the answer for sure. Anyway, lets run a small job that will reveal the answers for those who haven t.

The below job is really straightforward, it instantiates the list of RecordInsertList, adds a single buffer to the list and prints at infolog the number of records that have been inserted into the database.

As you can see, no record has been inserted by a single call to add.

static void callingAddJustOnce(Args _args)
{
    MyInvoice        myInvoiceRecord, insertedRecords;

    RecordInsertList invoicesToBeInserted = new RecordInsertList(tableNum(MyInvoice));

    delete_from insertedRecords;

    myInvoiceRecord.InvoiceAmount = 100;
    myInvoiceRecord.CurrencyCode = 'REA';
    myInvoiceRecord.Qty = 10;
    myInvoiceRecord.InvoiceId = '1';

    invoicesToBeInserted.add(myInvoiceRecord);

    select count(RecId) from insertedRecords;

    info('Probably, no record has been inserted by add since it has just been called once');
    info(strFmt('Number of records inserted is %1', insertedRecords.RecId));
}

Summary

 This post finishes my navigation through RecordInsertList class with a performance perspective for now. I tried to explain that add method will insert the records in to the database, so, for some features you may want to use ttsBegin and ttsCommit to avoid partial insertions of the set of buffers that must be persisted. My first example called add method many times without a call to insertDatabase and it showed that some records were indeed inserted. My next example called the add method just once it demonstrated that the record was not into db, since add method does not use a record by record insertion approach. This kind of approach would not provide a fast performance.

Please, feel free to download and test the project that is attached to this post.

On my next post, I will explore the UnitOfWork pattern and how to use it in Ax. Ax 2012 does support this pattern.

PrivateProject_RecordInsertList_AddMethod.xpo

In my previous post we analyzed the behavior of RecordInsertList when the insert method has been overriden. Now, lets play with RecordInsertList against a TempDb table. Is that possible?

I want to show that there are performance benefits of using RecordInsertList to make bulk insertions at a TempDb table, although it is not so fast as regular tables. You must pay attention to the fact that we can not use the RecordInsertList with a TempDb on the cliente tier. It is really dangerous to do that because the code is going to compile, but users will get a really ugly and deceiving runtime exception

I will let temporary tables explanation for a future post, so, right now I will just assume that you have some basic understanding on this theme.

Example

Lets see some X++ code. In the below example, I am trying to instantiate a collection of MyInvoiceTmp. This code compiles without problems, but, unfortunatelly, if we try to execute it, a runtime exception will be thrown because TmpDbs cannot be used with RecordInsertList on the client tier. The infolog message says that we cannot just use them together, but, in fact we can and there are performance benefits if we do so.

So, first of all, I have created a table called MyInvoiceTmp with 4 fields and I set its TableType as TempDb on AOT.

Then, I wrote some code to use it. Notice that I had to pass the TempDb buffer as parameter to the constructor of the RecordInsertList. Since that buffer is not the first constructor parameter, I also had to pass some boolean parameters before the buffer.

static void testAddInsertsRecordsIntoDbOnTheClient(Args _args)
{
    MyInvoiceTmp        tempRecord;
    
    // This code compiles, but it generates a runtime
    // exception with a misleading message saying
    // that tempDb can not be used together with
    // RecordInsertList
    RecordInsertList    invoicesToBeInserted = new RecordInsertList(tableNum(MyInvoiceTmp), // table id
                                                                    false, // skip insert
                                                                    false, // skip database log
                                                                    false, // skip events
                                                                    false, // skip aos validation
                                                                    false, // skip RLS validation
                                                                    tempRecord); // buffer where records will be inserted
}

And when we try to run this code, we get an error.

 Although the message says we can t use temporary tables for such operations, indeed we can. We just need to be careful because the code must be executed on the server.

 The below implementation demonstrates how to use RecordInsertList together with TempDb tables. I would like to highlight the "server" mark on the method declaration, which enforces that the method must be executed on the server tie. So, I have created a job which calls a static method.

  Here is the job:

static void insertRecordSetListTempTbOnServer(Args _args)
{
    MyInvoiceTmp::testInsertOnServerForTempTable();
}

 And here is the static method:

public static server void testInsertOnServerForTempTable()
{
    int              i;
    MyInvoiceTmp        myInvoiceRecord;
    int              startTime, endTime;

    RecordInsertList    invoicesToBeInserted = new RecordInsertList(tableNum(MyInvoiceTmp), // table id
                                                                    false, // skip insert
                                                                    false, // skip database log
                                                                    false, // skip events
                                                                    false, // skip aos validation
                                                                    false, // skip RLS validation
                                                                    myInvoiceRecord); // buffer where records will be inserted

    startTime = WinAPI::getTickCount();

    for (i = 0; i < 10000; ++i)
    {
        // Initializing the buffer with dummy values
        myInvoiceRecord.InvoiceAmount = (i + 1) * 100;
        myInvoiceRecord.CurrencyCode = 'REA';
        myInvoiceRecord.Qty = (i + 1) * 10;
        myInvoiceRecord.InvoiceId = int2str(i + 1);

        // Instead of inserting the record into the database, we will add
        // it to the RecordInsertList array
        invoicesToBeInserted.add(myInvoiceRecord);
    }

    invoicesToBeInserted.insertDatabase();

    endTime = WinAPI::getTickCount();

    info(strFmt('It took %1 miliseconds to insert 10k registers with a RecordInsertList approach at a temptbl',
                endTime - startTime));
}

Instead of getting an ugly infolog error message, we can see that the method was executed in about 2.4 seconds. This is better than running over a loop of insertions record by record, but it is not as good as the result for a regular table.

 So far, we have seen that there are performance benefits for using RecordInsertList, even with a TempDb. But looking at this number at infolog can be tricky, because the number depends on what processes are running right now on my machine.

We must have a second opinion What is happening behind the scenes? What does Trace Parser say about this?

Accordingly to Trace Parser, we have done 10k inserts. How can this be better than just doing a record-by-record insert through a loop? Why has the time at infolog been better?

If we play a bit more with the results at Trace Parser, we can see that everytime we called the add method, RecordInsertList added the buffer at a list. And when this list achieves a specific size, the RecordInsertList inserts all the records that are in this list at SQL Server.

The below picture shows that when the add method is called around 71 times, it inserts all the records being hold by its collection at sql server. So, the records are not inserted just when we call the insertDatabase method. Better than that, they are not inserted using a record by record approach.

Due to this fact, you are probably going to reach better results using the RecordInsertList with a TempDb than calling the insert method inside a loop.

 Summary

Throughout this post we saw an example about how to use TempDb and RecordInsertList together. We have realized that, currently, such mix can just be made on the server tier and that there are advantages from performance side.

The attached xpo contains a project that will allow you to play with the example shown in this post.

My next post on the performance series will continue to analyze the RecordInsertList class. I will show what is happening everytime we call the add method and what happens when we call the insertDatabase method.

PrivateProject_RecordInsertListWithTempDB.xpo

From MSDN:

This class allows you to insert more than one record into the database at a time, which reduces communication between the application and the database.

Records are inserted only when the kernel finds the time appropriate, but they are inserted no later than the call to the insertDatabase. add and insertDatabase methods. The RecordInsertList.add and RecordInsertList.insertDatabase methods return the accumulated number of records that are currently inserted, which allows you to keep track of when the records are actually inserted.

The array insert operation automatically falls back to classic record-by-record inserts when non-SQL based tables are used (for example, temporary tables), or when the insert method on the table is overridden (unless it is explicitly discarded).

RecordInsertList is similar to RecordSortedList, but it has built-in client/server support (it automatically packs data from one tier to another when needed), and it lacks the sort order features that are available in RecordSortedList.

 In my words:

The RecordInsertList class supports inserting many records of a given type into the database at once, avoiding the overhead that could happen if we have a loop that inserts a single record per iteration.

When the  insertDatabase method is called, Dynamics Ax Runtime packs the buffers to be inserted and send them to SQL Server. At SQL Server, the package is extracted and SQL Server will insert them record by record. Since many buffers are being packed together, we save a lot of round trips from AOS to SQL Server. The number of packages will be calculated accordingly to the size and quantity of the records to be inserted and to Ax server buffer size. If the insert or the aosValidateInsert methods are overriden at the table, then, insertDatabase will execute the "record by record" insert. The package approach will also not be employed if the table has a container field or a memo field. Nevertheless, during the instantiation of the RecordInsertList, either the insert and the aosValidateInsert can be skipped. Please, be very careful when skipping these methods.

The usage is pretty straight forward. First of all, you need to instantiate the a RecordInsertList specifying the table id of the table where the records will be inserted. Then, add the buffers at the list using the add method. Finally, call the insertDatabase method in order to insert all the records at once.

Example

Suppose that we have a table called MyInvoice with 4 fields: CurrencyCode, InvoiceAmount, Qty and InvoiceId. Given to a requirement, we need to insert 10k registers into the database. Inserting thousands of registers into the database during the daily activities of ours customers may be painfull since they need to share server resources with tens, may be hundreds, of other users.

Slow mode

 We could add 10k records into this table through the below loop. The insert statement is being called at the end of each iteration. This is really expensive!!!

static void insertIntoMyInvoiceThroughLoop(Args _args)
{
    int       i;
    MyInvoice myInvoiceRecord;
    int       startTime, endTime;

    startTime = WinAPI::getTickCount();

    for (i = 0; i < 10000; ++i)
    {
        // Initializing the buffer with dummy values
        myInvoiceRecord.InvoiceAmount = (i + 1) * 100;
        myInvoiceRecord.CurrencyCode = 'REA';
        myInvoiceRecord.Qty = (i + 1) * 10;
        myInvoiceRecord.InvoiceId = int2str(i + 1);

        // Record by record insert operation
        myInvoiceRecord.insert();
    }

    endTime = WinAPI::getTickCount();

    info(strFmt('It took %1 miliseconds to insert 10k registers with a record-per-record insert approach', 
                endTime - startTime));
}

After running this job on my test machine for a couple of times, the time spent was around 5 seconds, as you can see on the infolog window below.

We should also take a look at Trace Parser in order to realize what is going on behind the scenes. Notice that the insert statement has been executed 10k times and the job spent almost 3 seconds just with these statements. Trace Parser is a powerful tool that makes very easy for developers to assess performance and to find bottlenecks. For the sake of simplicity, I will not give any details about Trace Parser in this post.

Fast mode

 If you are not comfortable with such amount of time, we could enjoy RecordInsertList. At the end of each iteration, the buffers are just added to the collection. Finally, when all the buffers have been added to the collection, the insertDatabase method is called. The below job shows the usage.

static void insertIntoMyInvoiceByRecordInsertList(Args _args)
{
    int              i;
    MyInvoice        myInvoiceRecord;
    int              startTime, endTime;
    
    // This collection will store the records that must be inserted into the database
    RecordInsertList invoicesToBeInserted = new RecordInsertList(tableNum(MyInvoice));

    startTime = WinAPI::getTickCount();

    for (i = 0; i < 10000; ++i)
    {
        // Initializing the buffer with dummy values
        myInvoiceRecord.InvoiceAmount = (i + 1) * 100;
        myInvoiceRecord.CurrencyCode = 'REA';
        myInvoiceRecord.Qty = (i + 1) * 10;
        myInvoiceRecord.InvoiceId = int2str(i + 1);

        // Instead of inserting the record into the database, we will add
        // it to the RecordInsertList array
        invoicesToBeInserted.add(myInvoiceRecord);
    }

    // After fulfilling the array with the elements to be inserted, we are
    // read to execute the insert operation
    invoicesToBeInserted.insertDatabase();
    
    endTime = WinAPI::getTickCount();

    info(strFmt('It took %1 miliseconds to insert 10k registers with a RecordInsertList approach', 
                endTime - startTime));
}

 Now, infolog presents a pretty better value.

Again, it worths analyzing Trace Parser results. The insert statement was executed just 141 times and the job spent 297 miliseconds to insert the 10k registers into the database.

What happens when the insertDatabase inserts a register that causes a failure? 

 If some of the insert statements fail, we have no clue about which insert statements were correctly executed.

For example, I have inserted a register with the invoiceId equals to '100'. So, one of the insert statements must fail because it will also try to insert a record with the '100' value for this field.

An infolog error message will popup to inform about the problem and if query the db, some of the records were indeed inserted.

static void insertByRecordInsertListWithFailures(Args _args)
{
    int              i;
    MyInvoice        myInvoiceRecord;
    
    // This collection will store the records that must be inserted into the database
    RecordInsertList invoicesToBeInserted = new RecordInsertList(tableNum(MyInvoice));

    // this record will cause a failure due to a dupplicated invoiceid. This field must be unique
    myInvoiceRecord.InvoiceId = '100';
    myInvoiceRecord.InvoiceAmount = 0;
    myInvoiceRecord.Qty = 0;
    myInvoiceRecord.CurrencyCode = 'REA';
    myInvoiceRecord.doInsert();
    
    for (i = 0; i < 10000; ++i)
    {
        // Initializing the buffer with dummy values
        myInvoiceRecord.InvoiceAmount = (i + 1) * 100;
        myInvoiceRecord.CurrencyCode = 'REA';
        myInvoiceRecord.Qty = (i + 1) * 10;
        myInvoiceRecord.InvoiceId = int2str(i + 1);

        // Instead of inserting the record into the database, we will add
        // it to the RecordInsertList array
        invoicesToBeInserted.add(myInvoiceRecord);
    }

    invoicesToBeInserted.insertDatabase();
}

Sql server shows that 71 registers have been inserted by the insertDatabase method, plus the one insert that we did at the beginning of the method

Summary

This post demonstrated how to boost bulk insert operations through RecordInsertList class. Avoid doing adopting an insert per iteration approach. Besides improving the performance, the usage of this helper class will not scratch good OO design. Be aware about the behavior when a failure occurs.

The attached xpo Project contains the code of this post.

My next post of the Ax Performance series will highlight the scenario where the insert method has been overriden and we try to use the RecordInsertList. 

PrivateProject_RecordInsertList.xpo

In my previous post of this series, I highlighted that we can use RecordInsertList in order to execute bulk insert operations and that executing a single insert per iteration is extremelly expensive and should be avoided.

Now, lets take a look at a particular scenario where we try to use the RecordInsertList helper class to improve the performance, but the insert method of the table has been overriden.

Example

In this example I am using a table called MyInvoiceInsertOverriden which has some fields and that has overriden the "insert" method. Just because this method has been overriden, we will not enjoy the full benefits from RecordInsertList helper class. Below, you can see both the AOT node for this table and the insert method that has been implemented.

public void insert()
{
    // Dummy code
    this.InvoiceId += '0';
    
    super();
}

So, lets employ the RecordInsertList approach again. Will the "record by record" insert call from the AOS side be avoided? Will Dynamics AX send a small amount of packages to SQL Server?

static void insertIntoMyInvOverridenByRecordInsLst(Args _args)
{
    int                             i;
    MyInvoiceInsertOverriden        myInvoiceRecord;
    int                             startTime, endTime;

    // This collection will store the records that must be inserted into the database
    RecordInsertList                invoicesToBeInserted = new RecordInsertList(tableNum(MyInvoiceInsertOverriden));

    startTime = WinAPI::getTickCount();

    for (i = 0; i < 10000; ++i)
    {
        // Initializing the buffer with dummy values
        myInvoiceRecord.InvoiceAmount = (i + 1) * 100;
        myInvoiceRecord.CurrencyCode = 'REA';
        myInvoiceRecord.Qty = (i + 1) * 10;
        myInvoiceRecord.InvoiceId = int2str(i + 1);

        // Instead of inserting the record into the database, we will add
        // it to the RecordInsertList array
        invoicesToBeInserted.add(myInvoiceRecord);
    }

    // After fulfilling the array with the elements to be inserted, we are
    // read to execute the insert operation
    invoicesToBeInserted.insertDatabase();

    endTime = WinAPI::getTickCount();

    info(strFmt('It took %1 miliseconds to insert 10k registers with a RecordInsertList approach with overriden insert',
                endTime - startTime));
}

Now, lets see how many insert SQL statements have been executed through Trace Parser.

 Wait!!! What is going on??? 10k insert statements!!!

Unfortunatelly, Ax has executed one call to SQL Server per insert statement. This situation happened because we have overriden the insert method at the table.

The constructor of RecordInsertList allows skipping the insert method call, by passing true to the second parameter, BUT I STRONGLY recommend you to do not try this because the insert method will not be executed. Since there is an insert method, it probably contains important instructions.

Anyway, lets try skipping this method and lets make sure that we will not execute 10k insert statements from AOS side.

static void insertIntoMyInvOverridenSkipInsert(Args _args)
{
    int                             i;
    MyInvoiceInsertOverriden        myInvoiceRecord;
    int                             startTime, endTime;

    // Notice that the second parameter is being passed as true to inform that 
    // the insert method must be skipped
    RecordInsertList invoicesToBeInserted = new RecordInsertList(tableNum(MyInvoiceInsertOverriden), true);

    startTime = WinAPI::getTickCount();

    for (i = 0; i < 10000; ++i)
    {
        myInvoiceRecord.InvoiceAmount = (i + 1) * 100;
        myInvoiceRecord.CurrencyCode = 'REA';
        myInvoiceRecord.Qty = (i + 1) * 10;
        myInvoiceRecord.InvoiceId = int2str(i + 1);

        invoicesToBeInserted.add(myInvoiceRecord);
    }

    invoicesToBeInserted.insertDatabase();
}

 This time, if we look at Trace Parser results, just 141 insert statements have been executed from the AOS side. Please, keep in mind that the insert overriden method has not been executed and this skipping may be extremelly dangerous for the consistency of yours data.

 Summary

While programming with a performance focus, you should always measure your implementation performance because some assumptions may be wrong.

Although sometimes we have the means to overcome a performance downgrade, we must do the trade off analysis.

In some situations RecordInsertList will not provide all the performance benefits that we would expect. For sure, you could by-pass these situations by writing some code, but the damage can be huge.

The attached file contains the code of this post.

My next post will cover how to use RecordInsertList with temporary tables.

PrivateProject_RecordInsertList.xpo