Has anyone created a database of step types and their properties?

[Mark_Ireton]

This question relates to analysis of results that have been logged to a database using a custom schema. In order to query results based on step types and step properties, I'd like to create some tables in my database that describe the steps. Let's say I create a custom step type called MyStepType that has a property called Channel. With the right database schema, I could then query the results to get all step results of the type MyStepType where Channel = 3. Extending this to other step types and properties would allow me to analyze results based on any combination of properties or step types. Since I am logging a huge volume of data, I want the result tables to be normalized. So each step
would have a foreign key that points to a step type with properties of certain values rather than logging the step properties with every result. One of the problems is how to populate the step type data in the database and keep it in sync with the TestStand step types. I'm thinking about writting a custom utility to export the step types and their property names to a database using the TestStand API. A simpler (but error prone) solution is to manually enter step properties in the database. Any ideas or comments? (marki@tek.com)
P.S. I know this is a rather obscure topic...

[Carlos L]

According to your first sentence, I understand the results have already been logged and you want to retrieve some data that meet specific conditions. This can be easily done using SQL statements (using a WHERE clause) disregarding the schema you use.
After reading the second part of your explanation, it seemed to me that you are trying to create a database schema similar to the default one in TestStand 2.0. I am attaching an image with the default tables and relationships between them. As you will see, while in TS 1.0.x there were just 2 tables, in TS 2.0 there are many more tables. There is one table, called STEP_RESULT, which contain all the results that are common to every step type. The other tables are divided by step types. For i.e., the STEP_PASSFAIL table wil
l contain the results (properties) that belong to the Pass/Fail Test Step type only. As you can see, the layout of the tables is better structured and therefore easier and faster to handle. If you created a new step type, you'd just need to create a new table that would contain the properties that belong just to that particular step type. This table should be related to the STEP_RESULT table in the same way the others are.
The last part of your description talks about logging your new step type data to the database (if I understood correctly). In TestStand 2.0 this would be a simple task since you can easily define what you want to log by creating a schema that matches your database (you could refer to the user manual for more information). In TestStand 1.0.3 it is not that straightforward since you'll need to modify the "Database.seq" sequence file where you'll use database steps to log
the additional data.
I hope this will help in what you are trying to do. Otherwise, I think g
iving an example (such as a layout of the tables you'd like to use along with the results you'd like them to have) would be very helpful to fully understand what you are trying to accomplish.