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

[Mac671]

A test rig that worked fine started thowing the floowing error for me.

See screen capature.

Problem doesn't appear on the development PC.

The code that I'm using is using the default settings for logging to the access database that ships with TS. All worked fine for a few weeks now it keeps ... breaking.

An error occurred calling 'LogMultipleResults' in 'ITSDBLog' of 'zNI TestStand Database Logging'
An error occurred executing a statement.
Statement: STEP_RESULT.
Description: The changes you requested to the table were not successful because they would create duplicate values in the index, primary key, or relationship. Change the data in the field or fields that contain duplicate data, remove the index, or redefine the index to permit duplicate entries and try again.
Number: -2147217887
NativeError: -105121349
SQLState: 3022
Reported by: Microsoft JET Database Engine

Source: TSDBLog

[dug9000]

Are you perhaps using Access? If so perhaps your database is too big (I think Access is limited to 2GB).

-Doug

[Scott_Richardson]

Questions:

1) What version of TestStand are you using?

2) What NI schema are you using? If not default, what schema is it based from?

3) Are you logging results after a UUT completes or are you using OTF?

4) Is this issue easy to reproduce, and how often does it fail?

5) Are you logging results to an Access database from one process on one computer, multiple processes on one computer, or processes on multiple computers?

I know that we fixed the following issue in TestStand 2010

253717

Primary Key GUIDs that database logging feature generates might not be globally unique

The TestStand Database Logging feature uses the Microsoft Windows UUIDCreate() function to generate unique GUIDs for the Primary Keys of database records. Microsoft changed the behavior of the UUIDCreate() function to use a random number generator to generate GUIDs. With this change, it is possible that GUIDs are not globally unique from one computer to another. Alternatively, the Windows UUIDCreateSequential() function generates GUIDs based on the MAC address of the computer and a timestamp, which ensures that a GUID the UUIDCreateSequential() function provides is globally unique.

[Mac671]

Hello,

As far as I remember the DB size was approx ~ 1.5 GB, I don't have access to that test station till Wednesday so I'll double check but it could be as simple as exceeding the DB size, I'll verify that when I'm on-site again.

To answer a few questions from Scott:

1) I'm using TestStand 2012 ( as it came with the installation disks shipped in the first quarter of this year ).

The test station is offline so no updates have been applied since the install.

2) I'm using the default NI Schema and an Access DB. ( No modifications have been made )

3) I'm using the On-The-Fly feature logging feature both to ATML and the DB.

ATML works with no issues, DB used to work fine until it refused.

4) Fails every time when I start the sequence, disabling logging to the Database sorts the issue out.

5) I originally used the BatchUUT.seq example that ships with test stand.

I have developed a test that has three test sockets that have a common Initialize, Run Tests in parralel and have a sequence of common test steps.

Scott:

The issue you've sent speaks of UUIDCreate; I'm gettin issues with the STEP_RESULT .... I think these things are not related.

Secondly I'm suing TS 2012 so a fix should have been propagated to my version.

So to answer your question I'm using multiple processes on one computer.

I will emphasize that everything worked fine up to a certain point ... so I'm guessing Doug might be right on the money with the fact that I've chosen a misfortunate Database ( Access ) for the job.

Regards,

Maciej

[Scott_Richardson]

I agree that you should not be hitting the said issue that I mentioned because you are using 2012.

The default schema uses recordsets and auto-counter values for primary keys, so it seems odd that the error is reporting that there is a duplicate value in the index, primary key, or relationship.

If this is a database size issue, it seems odd to receive the error that you mentioned.

If this is not a size issue, the only thing that I can recommend trying first is to temporarily create a new empty copy of the database and log to it to see if that logs successfully. Then you could investigate what it is about the data in the empty table that is somehow conflicting with the original table.

[Mac671]

Hello Scott, 

You might be pointing to the nature of my issue; perhaps it isn't the 2 GB treshlod, but the auto-counter has overflown.

The test I'm running is a life test of a product, that means one test runs for many hours and I've been logging tons of data as we're trying to break the product and later analize as much gathered information as we can.

Since I've been running this test for a very long time logging many STEP_RESULT entries it could be the case that the auto-counter has reached a maximum value and has overflown and the DB is trying to insert an index that is allready used.

I will try to set up an empty database to see if logging to an empty DB works (I'm relatively certain it will as I don't get this issue on my development Laptop, but than again it has not been running as many tests as the test rig).

I'm just not on-site till Wednesday so I can't get back with any more info before mid-week.

Thanks a lot for your input!

Much appreciated will keep you posted.

Regards,

Maciej