Is Generic Insert faster than Generic Recordset?

[Winther]

Hello.

We have build test system which tests 4 units using the batch model. When the tests have finished we use a modified Generic Recordset Schema to send the results to an SQL server.

The 4 tests generate about 2000 results and it takes 30 seconds, sometimes a bit more, to write the data in the database.

This seems very slow to me, but maybe this is as fast as I can expect it to be?

Would it have made a difference if we had used the Generic Insert Schema instead?

We have allready changed the statement from "SELECT * FROM..." to "SELECT TOP 0 * FROM..."

[A.Rohde]

Hi Winther

I assume you have already referenced the following document "Why Do I Encounter Delays in Execution When Logging to a Database with TestStand?"

http://digital.ni.com/public.nsf/allkb/904986636B5FC7D78625773E004E065F

Since you have changed the SQL Statement.

In the bottom of the page note the following statement:

The Generic Insert schema, which also ships with TestStand, uses an INSERT statement, such that the necessary data to log is directly inserted into the table without the need to query for a recordset.

So the answer to your question is: Yes the Generic Insert should be faster than Generic Recordset.

Best regards,

Anders Rohde

Applications Engineer

National Instruments Denmark

[Winther]

Thanks for the answer Anders.

I have learned that to use the INSERT statement we will have to change the DB tables. Now they are using the auto increment option in the ID coloumn.

So instead we start the "Log to Database" sequence in a seperate thread and let the next test begin while it finishes.

[A.Rohde]

Hi Winter

You are right that you need a different database for the generic insert than generic recordset. If you are having problems to create a database for the generic insert have a look at the following link:

http://zone.ni.com/devzone/cda/tut/p/id/6484

But the possibility to log in an other thread while program is running is also a possibility to limit the writing time for writing to the database after the program has finished as you mention. Let me know if you have any problems with implementing either of the solutions.

Best regards,

Anders Rohde

Applications Engineer

National Instruments Denmark

[Winther]

Hi Anders.

The solution with a seperate thread for logging is implemented and working.

We only had one problem - we had to put synchronization controls around the Logging sequence. If it was logging results from a passed test and the next test failed in the first measurement, the failed test would start logging before the last one was finished. This caused the results to get mixed up in the database.

[A.Rohde]

Hi Winter

Thanks for sharing your expirence with the implemented solution. I'm glad to hear you got it to work.

Best Regards,

Anders Rohde

Applications Engineer

National Instruments Denmark