NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

An error occurred calling 'LogResults' in 'ITSDBLog' of 'zNI TestStand Database Logging'

I'd appreciate it if I could get some help regarding the following error.

----------------------------------------------------------------------------------------------------------------------------------------------

Error Message: An error occurred calling 'LogResults' in 'ITSDBLog' of 'zNI TestStand Database Logging'
An error occurred executing a statement.
Schema: SQL DalsaTE Rev02 - CamsatPearl - No Step Logging
Statement: ResultsUut.
Description: Connection failure
Number: -2147467259
NativeError: 0
SQLState: 08S01
Reported by: Microsoft OLE DB Provider for SQL ServerDescription: Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.
Number: -2147217887
NativeError: 0
SQLState: 08S01
Reported by: Microsoft OLE DB Provider for SQL Server

Source: TSDBLog
Error Code: -2147467259

Step: Log Results to Database

SequenceFile: C:\Users\Public\Documents\National Instruments\TestStand 2012\Components\Models\ModelPlugins\NI_DatabaseLogger.seq

----------------------------------------------------------------------------------------------------------------------------------------------

 

1. I was using OTF and TestStand 2012

2. The issue occurred when I tried resetting (disabling and then enabling) Windows network adapter during the test. It happend quite often but not every time. The adapter was enabled when the error occurred.

 

Thanks.

0 Kudos
Message 1 of 14
(5,353 Views)

I was using non-OTF actually.

0 Kudos
Message 2 of 14
(5,346 Views)

Hi yhwang21,

 

Did you properly configure your database options to log to your SQL database? Here's a tutorial on how to do so: http://www.ni.com/tutorial/3604/en.

Sunayna R.
Applications Engineering
National Instruments
0 Kudos
Message 3 of 14
(5,318 Views)

Hi Sunayna,

 

When the failure ocurred, I pinged the IP address of the database, which showed response. I was also able to login to the database server.

I think the database has been properly configured. I have 2 test sequences. The only difference between them is that one has an additional step to reset network. As long as I didn't reset the database network during test, the failure would never occur. Once it occurred, a restart of TestStand followed by running the sequence without network reset step would fix the issue.

I was thinking if it could be related to database initialization in TestStand. It appeared that reseting the network changed something and prevented TestStand from connecting to the database.

 

Thanks.

0 Kudos
Message 4 of 14
(5,315 Views)

I think you're on the right track -- everytime you reset the network, you might be disabling your database setup. Try setting it up following these links, it's possible you might have set it up incorrectly in TestStand.

 

http://www.ni.com/tutorial/14595/en

http://www.ni.com/tutorial/51953/en

Sunayna R.
Applications Engineering
National Instruments
0 Kudos
Message 5 of 14
(5,225 Views)

The TestStand database logging feature maintains a connection to a database for each execution. The connection is typically opened when the UUT logs the first UUT result and the connection is maintained throughout testing subsequent UUTs. If the network adapter is reset, I suspect that the connection handle is invalidate, so when TestStand attempts to use the connection again, it fails and you see the unexpected error.

 

From an internal implementation detail that you in general should not rely upon, the connection for each execution is stored in a reference object property on the execution that is accessible on the context for the execution, for example: RunState.Root.RunState.Execution.TSDatabaseLoggingDatalink42dcdc47_79c8_11e5_82baecf4bb551134  The GUID value may differ depending on the results processing configuration settings. If after you reset the network adapter, I suspect that if you delete this property on the execution, the database logging framework should retry to obtain a new connection when subsequently logging results.

Scott Richardson
National Instruments
Message 6 of 14
(5,182 Views)

Hi Scott, 

 

I did a few retested and noticed that the failure didn't seem to occur on the first UUT I tested. So I was able to reset the network adapter and had no problem at the end fo the test logging test results.

However, the failure would show up starting from the second UUT, which followed your suspicion that something had been changed after the first UUT logs.

 

I've checked the database connection string and it did not change and was still correct. I'll have to check the GUID value and see if it gets deleted after the reset. Are there other connection handles that could also be changed?

 

Thanks.

0 Kudos
Message 7 of 14
(5,169 Views)

I am not aware of any handles related to database logging that are maintained between UUTs that would come into play for the use case as you described.

Scott Richardson
National Instruments
0 Kudos
Message 8 of 14
(5,130 Views)

Hi Scott,

 

I took at look at the variable RunState.Root.RunState.Execution.TSDatabaseLoggingDatalink<GUID>, and noticed that it did not get deleted during the network adpater reset. Before logging the 2nd UUT result, if I released this reference object (value changed from "IDispatch" to "nothing"), the test results would be logged successfully. Regarding this finding, 

1. Do you know the reason behind this?

2. Would it cause some other effects to Database logging?

3. If it is safe to release this object, how should I properly address the variable name in order to change its value, especially the GUID part. I found one article (http://digital.ni.com/public.nsf/allkb/4BEAC4D20C7896AE86257123005F15FA) in which it mentioned to use TSDatabaseLoggingDatalink<SchemaName>. However, the SchemaName does not seem to be the same as GUID. 

 

Appreciate your help.

0 Kudos
Message 9 of 14
(5,102 Views)

1. The purpose of the object on the execution is an implementation details to optimize performance. Connecting to a database takes time, so the database logging feature caches the connection to the database so that the same connection can be used to log each subsequent UUT.

2. I am not aware of any negative affects to releasing this reference between the logging of each UUT results, other than the overhead of making the database logging feature reconnecting to the database.

3. I think it should be safe if done after logging completes for a UUT and before starting the next UUT.If you are using a parallel or batch model, there is n DB logging configuration option which can require that all the executions use the same session, so releasing on one execution will not fix the issue if the other executions are still holding onto the same session. If you are using those models and that option, then I might have to dig deeper on the implementation and any additional requirements to properly release all references.

 

The GUID was added in 2012 when we moved to a plug-in model. The reason why is that the results collection dialog could define multiple instances of the same plug-in and each instance could be connecting to a different database, so we have to uniqify the property name. This is just an implementation requirement and we chose to use a GUID. If you wish to reset it, you will have to traverse the subproperties and compare to a subset of the property name to determine that it is a data link reference.

Scott Richardson
National Instruments
0 Kudos
Message 10 of 14
(5,075 Views)