Re : On the Fly report fills UUT_RESULT informations at the end of the test

[Jean-Louis]

Scott,

The UUT_RESULT table contains two types of informations :

1) Informations known at the beginning of the execution

• STATION_ID
• BATCH_SERIAL_NUMBER
• TEST_SOCKET_INDEX
• UUT_SERIAL_NUMBER
• USER_LOGIN_NAME
• START_DATE_TIME

2) Informations known at the end of the execution

• EXECUTION_TIME
• UUT_STATUS
• UUT_ERROR_CODE
• UUT_ERROR_MESSAGE

Could it be possible to fill in the database the informations of category 1) at the beginning of the execution and udpate the UUT_RESULT record at the end of the execution with the informations of category 2) ? 

[herrlin]

I had a similar need to have UUT Results updated prior to the end of the testing so that I could query the results.  I have a long test, so I chose to use On-The-Fly logging so that I could review step results prior to the completion of the test as a whole.  Similar to this thread I ran into the problem of not being able to query the UUT results because several of the important fields are not populated until the entire test is complete. So I thought I would document my solution with some example code.

To get my example code to work you will have to do the following.

1. Use the schema I provided to create a database (DB) – the schema is the generic insert schema modified to use a station global for the UUT GUID. – should be able to do this right from TestStand(TS)
2. Configure DB options in TS to use On-The-Fly logging and the schema provided.
3. Add a station global named UUTGUID (StationGlobals.UUTGUID)
4. Add your DB connection info to the first step in the Get GUID sequence

The one part of my solution that I am not 100% in favor of is the use of a Station Global but I was not able to figure out an alternative in the time allotment that I wanted to spend on this.  If anyone has another method other then the Station Global I would love to hear it.

Other mentionables

• Using TestStand 4.5.0310
• Using SQL Server Express 9.0.5000
• Using SQL Server Reporting Serves (SSRS) - for report generation

[Roger_C]

Hi,

@Jean-Louis,

Did you found a solution for filling the UUT_RESULT table? In my opinion you're absolutely right that it's not logic not to fill the uut_result-table with the information already known at the start. The only design considerations I can think of is that it's possible to change the variables in a sequence programmatically  (for example UUT_SERIAL_NUMBER ) during the execution causing an inconsistent state (DB versus result-collection) However this could be resolved by adding an extra update state on the end of the execution (the same statements like in the current implementation)

@Herrlin,

The solution you provided looks good. Unfortunately I can't use it because I'm using MySQL (MariaDB to be exactly) which doesn't have the datatype UNIQUEIDENTIFIER for the ID-columns. Also I'm wondering what happens when I use this solution with multiple sockets. Is it possible that the StationGlobals.UUTGUID can contain invalid values? The GetGUID-sequence will be executed in parallel and there is no guarantee that the order in which the database-engine will execute the statements will be same order as in the sequence. (it's not an atomic action)

@everybody 😉

Best solution in my opinion would be to implement the update of the uut_result-table in the DBlog.dll. The "model plugin-UUT Start"-sequence in the NI_Databaselogger.seq calls the method "NewUUT" of the TSDBLog-object class. The UUT-container (with for example UUT_SERIAL_NUMBER) and StartDate/Time are part of the parameters-list of the "model plugin-UUT Start"-sequence and are passed as object-references into the method "NewUUT". So the data is available in the DLL.

I was wondering if it's difficult to implement this into the provide source-code and build a new DBLog.dll. (I'm a Newbie in C++)

The source-files are available in /Program Files (x86)/National Instruments/TestStand 2013/Components/Models/TestStandModels/Database/DBLog

I found the NewUUT method in the TSDBLog.cpp but I still haven't found the exact place were the resulting DB INSERT statement is executed ... 

Somebody an idea how to do this?

Thanks,

Roger