How to display sequence file version in report?

[_xs_]

We would like to add the sequence file version number (Edit>>Sequence File Properties...) to our reports and record it in the test result database.  How do you access this property from a step in the sequence? 

[trussell]

You can use two Teststand API Calls.

1.  Get object reference object

Note:  Create a local variable to store the object reference that will be returned.

Object Reference:  Runstate.Engine

Object Class:  Engine

Action:  Call Method

Method:  GetSequenceFileEx

2.  Use reference to get sequence file revision

Note:  This will return the sequence file revision.

Object Reference:  <use local variable above>

Object Class:  PropertyObjectFile

Action:  GetProperty

Property:  Version

Hope this helps. 

[trussell]

Also,

If you want this revision to show up in the report, then just do a string limit test. 

[Eric M]

OR use RunState.SequenceFile.Data.Version.

For the Report Header:

In a ModifyReportHeader callback, add a statement step that has this expression:

Parameters.ReportHeader += RunState.SequenceFile.Data.Version

This will append the SequenceFile Version to the header string. You will probably want to play with placement and may decide to insert more than just the version.

Also, note that the ModifyReportHeader callback is only called when a Sequence is used to generate the report body. See the bottom of the Content tab of the Report Options Dialog (Configure>>Report Options) for this setting.

For Database Logging:

If you haven’t done this before, you will need to customize the schema and the database to include this additional “result”. I recommend adding a column to the UUT_RESULT table for this sort of information. If you have taken the TestStand I: Introduction course, this process is covered in Lesson 11. Otherwise, there is background information in the TestStand Help and Chapter 6 of the TestStand Reference Manual. The key will be found in Configure>>Database Options.

Regards,

Eric

[_xs_]

Hi Trussell:
Thanks for your response.  If I use a string limit test for this, how do I prevent it from becoming a maintenance pain?  Won't I have to maintain the limits everytime the sequence file version changes?

[_xs_]

Thanks EricM:

What are the drawbacks to changing the database schema?  It seems like I would have to touch a lot of things to make this work.

Is this better than using the following scheme:

Create a Statement Step named Version Number with the expression Step.Result.ReportText= RunState.SequenceFile.Data.Version.  This step should be at the beginning of the Setup for the main sequence.

This will display the Sequence File Version on the report and record it in the results database in the STEP_RESULT table.

This seems like the simplest thing that could work. 

The most obvious drawback is that every developer in our organization would need to use the same name for this step or we won't get consistent reporting out of the database.
 

[trussell]

If you do a string test and select for the data source the location that is holding the sequence revision and do not put anything in for the limit, the test will always pass and will be entered into the results list.  This is kind of back door'ish way of doing it.  As your sequence file changes revision it is simply documented into the data log file.

[trussell]

Better yet, just use the runstate variable mentioned above and use that as the data source with the string limit test and that should give you everything you need without doing a series of API calls.

[_xs_]

When I try to compare the version string to the empty string, I get a failure.  Are we using different versions of TestStand?  When tested with TestStand 3.1f1 I get:

String Value Test
Status:	Failed
String:	0.0.0.6
Limits:
String:	''
Comparison Type:	Ignore Case

I can set Step Failure Causes Sequence Failure to false and have the sequence pass, but I know I will create confusion when the operator sees the step failed.

[Eric M]

_xs_,

Your idea to use a Statement step would avoid the issue of the step passing or failing. It would, as you suggested, also require your developers to use the same step in SetUp for uniformity in your reports. This may take some doing.

There are no inherent problems with customizing a schema except when mistakes are made. It will take some work to get your system set up to log the version number, if it is not included in a step's results. However, the beauty of using a schema is that once you have made the change to the schema and the database, you don't have to remember to always use any additional step. Also, the schema can be exported as a file so that it can then be imported on another system.

Of course, that system would also need its database customized, too. To handle this, you can build and execute SQL scripts in TestStand to build a database according the specifications of the schema.

For now, your idea about using a statement step is easy in the short term.

Regards,

Eric