Save a report file to the varchar(max) column in database table

[LwNewTestStand]

I can save the UUT, Step, and Numeric Measurement results to database following the procedure described in "Creating a TestStand Database Schema from Scratch" ( http://www.ni.com/white-paper/6484/en/ ). But I also want to save the report file (in ASCII Text format) to the SQL Server database ( to column VarChar(max) in UUT_Result table ). Is it possible? If so, what is the procedure that I can follow through?

Thanks

[Basil-B]

Hi,

So do you want to log it as a string text file to the database? This whitepaper might help: http://www.ni.com/white-paper/14595/en#toc2 for logging additional results. You could do it by simply creating a new column in the database table.

[Scott_Richardson]

You would need to ensure that the report is generated first and then store the text is some global location and then have the database logging routine pull in that data. There is no simple way to do this. The database logging feature and the report generation feature do not know about each other.

The only suggestion that I can give is to have the report generation store the report to a separate table in the database using similar qualifying information such as the SN and all.

[LwNewTestStand]

Hi Basil,

Yes, I prefer saving the report as a string text file. Later it can be queried out of database as plain text message.

Thanks for the link. It looks I can create a new database table, include a column as type parch(Max), and then save the report file in ASCII format to this column using method 1 "Additional Result".

Now the problem is that how to get the report file content into the custom result as Scott mentioned "database logging feature and the report generation feature do not know about each other".

Thanks

Leo

[Basil-B]

Hi Leo,

Are you able to save the report as a single ASCII string?

[LwNewTestStand]

Hi Basil,

Actually this is the part I am looking for help: How to get the report content (either in ASCII, XML, or other format) during sequence execution so it can be saved to database using the methods mentioned in the link you provided before?

"During sequence execution" may not sound right. The report can only be generated after the test has finished. I am thinking it may be possible to modify the default SequentialModel.Seq as such:

After "Write UUT Report" callback and before "Log To Database Callback", retrieve the report content and save it to "Additional Result". So the report content can be saved to database (please refer to the following screen-shot).

But I am quite new to TestStand and don't know how to accomplish this. Can you evaluate this suggestion and if possible, carry out some experiments, and give me a procedure to follow?

Thanks,

Leo

[Daniel-E]

Leo,

The report text is stored in a variable called Locals.Report in the process model. One way to approach this might be to modify the UUT container to have a new field called ReportData and store the Locals.Report value in there. Then, in the datbase logging options, you could log Logging.UUT.ReportData to the database.

However, to take a step back, are we sure this is the best approach for your application? The database already contains the same information that the report would have, and you can easily write a tool to query the database for the information of interest. Depending on the end goal and what the intended use of the data is, it might make more sense to focus development efforts in that direction.

[LwNewTestStand]

Hi Daniel,

Thanks for pointing out that the "Locals.Report" variable contains the report text. I will try out the approach as you suggested.

About the reasons to save report to database, I think in certain situations, the end users may prefer inspecting the report itself to find out the detailed test information about a specific UUT. It's possible to let users to use SQL query to get all the pieces together. But in the production environment, when something went wrong with a specific unit, the test engineers were frequently asked to provide the test log file for debugging purpose. The query results were required more likely when large amount of samples were under analysis or for general reporting purpose.

Another reason is that I don't plan to save non-numeric test results (like power on, check SIM card, send GPIB command A to perform measurement on test point B) into table columns, especially not into numeric-limit tables. It seems there has no request or demand to plot histograms for non-numeric test results. So these non-numeric test information can only be found in the report file since we don't need to dissect them into table columns.

However, I still appreciate your reminding about whether saving report to database is the best practice. I will spend some time rethinking the rationalities behind this design idea even I can get it working.

Thanks,

Leo

[LwNewTestStand]

Hi Daniel,

As a newcomer to TestStand, I don't know how to "modify the UUT container to have a new field called ReportData and store the Locals.Report value in there". Can you list some steps that I can follow through?

Thanks,

Leo

[Daniel-E]

Hey Leo,

Actually, I found a KnowledgeBase article on our website which describes this exact process, and it's not necessary to modify the UUT container. I tried this method and was successful in saving the ASCII report to the table. This KB mentions a ModelNumber parameter as its example. Instead, for our situation, I made a new Local variable in my process model called "ASCIIReport" and stored the value of Locals.Report in there as soon as the report is generated. Then I log this Locals.ASCIIReport variable to the database using the method described in the KB. It appeared to work properly.

Also, please note that this method is only valid for the TestStand 2010 and older process models. In newer versions of TestStand, we've changed the way reporting and database logging works to use a plugin architecture, and this is partially what Scott was referring to when he mentioned that these two features don't "know" about each other. If you're currently using the TestStand 2012 or newer process model, or if you plan to migrate to those models in the future, further work will be required to log the text report to the database. The method in the linked KB should work for the legacy models, however.