Holding test result in case of SQL failure

[bwv1043]

Hello.

I'm trying to design a system where a test station (TS deployed environment) performs test and writes test result to SQL server (different PC) via LAN.  If the network goes down between the test station and SQL server then is there a way TS can hold the test result until the connection to SQL server is restored?

I'm using TestStand 4.2.1, LabVIEW 2010, SQL Server Express (for experiment) on Windows 7 environment.

Thanks

Steve

[snowpunter]

If you're using On-The-Fly Logging then it should produce an error when the connection drops and it can't connect to the database when it tries to log a result. You can handle that error in a SequenceFilePostStepRuntimeError callback, i.e. poll the DB and log the data once the connection is restored.

[bwv1043]

snowpunter

Thanks for the response.  I don't plan on using "on the fly logging" to minimize the test time however you gave me a good idea, that is, simply handle DB connection error.

My system is designed for production line environment where it is not desirable to stop testing the next UUT.  I wonder if I could save the data in a binary file when I cannot connect to DB.  Then I simply continue testing next UUT.  When the DB connection is restored then I would retrieve the previously saved data and write them to DB.

Is this feasible (anyone)?

[Perry_S]

Hi HelloChicago,

That sounds very feasible. Would it not be simpler to log the data in a binary file for the entire process and then at the end export the data to your data base. If your network is up it would then go smoothly. If it is down you could then follow snowpunter's suggestion. I only suggest this because you will only have to deal with the network failing event once. I hope that this helps.

Regards,

Perry S.

[dug9000]

The TestStand APIs:

Engine.SerializeObjects(, SerializationOption_UseBinary)

Engine.UnserializeObject()

Can be used to serialize and unserialize properties as binary data. You might want to then write the data to a file for later processing. The answer is it's doable, though not trivial.

-Doug