An error occured evaluating the database logging Result Filter Expression

[Doiron]

Hello David,

I have a few points.

1) The solution to use the 4.0 database.seq would not really be temporary in that you could take that sequence to future versions as well, it would just require you to migrate that file with all the other files you will already be copying to the new system (assuming you are reusing sequence files)

2) The Volume License Program has a number of different advantages, from ni.com:

"The National Instruments Volume License Program is available for small groups, sites, or entire organizations with five or more licenses of an application software package. Program participation includes discounts on software purchases and training courses, automatic software upgrades, access to an elevated level of technical support, and flexibility in software budgeting and purchasing"

You can use a previous version of the software, although it is not recommended. 

3) In the release notes we specifically mention why these options were changed, page 16 has most of the information, the main reason being: "TestStand 4.1 updates the default database schema in the following ways to
support logging additional results:" There is some great added functionality that required this change to implement.

I can definitely understand where it might seem like 4.0 to 4.1 is a minor change, however minor revisions are noted by a 3rd number, ie 4.0, 4.0.1, 4.0.1f1. We do recommend that before upgrading any version that you check the release notes though specifically for these reasons.

Please let me know if you have any other questions. 

[david_jenkinson]

Hello,

If I were to attempt to adjust our code to the changes implemented in 4.1, what would I need to change?    I see that the property changes quoted in the release notes are different than the properties contained in our filter expression, from which the error message seems to be originating (see previous screen shot).  

Would the changes be limited to changes in our schema, as in what teststand variable the fields point to in the tables?  Will search/replace work for this?

David J.

[david_jenkinson]

>1) The solution to use the 4.0 database.seq would not really be temporary in that you could take that sequence to future versions as well, it would just require you to migrate that file with all the other files you will already be copying t>o the new system (assuming you are reusing sequence files)

We perform our migrating, or copying of our sequence files using perforce, and they are contained in a tree seperate from the teststand program heirarchy.  We don't normally replicate the contents of the teststand program heirarchy itself, since the contents of these directories are handled by the program install.

We have however changed the default teststand configuration directory, so we could more easily source control our process model, custom type palettes, station globals etc.   I am wondering if it will work to move the 4.0 database.seq in that config directory, to more easily replicate to other stations, and point to it in the process model within the "log to database" sequence.

[david_jenkinson]

So I tried the procedure emailed to me by Marshal, which was:

 To install the attached database.seq:
1. Rename database.seq to something like database_4-1.seq in Program
      Files\National Instruments\TestStand 4.1
      \Components\NI\Models\TestStandModels\Database
2. Copy the attached file into Program Files\National Instruments\TestStand
      4.0\Components\NI\Models\TestStandModels\Database
3. TestStand should automatically generate all the other supporting files
      associated with Database.seq

I got a prompt looking for where database.seq was, because the call to this sequence was pointing to the 4.1 directory.   I browsed to the database.seq in the 4.0 directory.  I get the same error.  It is attached.

It still seems unable to reconcile the filter expression, although the properties pointed to by the expression exist.  I'm not even sure it makes it to the actual logging operation. 

I am on vacation for the next two weeks, and seeing as this solution is left unresolved (at least on the two stations that have not be reverted to 4.0), it will probably remain so until then.  Please do not close my support issue I opened regarding this in my absence.  

I am also wondering what kind of changes would be necessary to our database schema (or other files) to make it work with 4.1.  

Regards

David Jenkinson

[Doiron]

Hello David,

Marshall and I are going to be looking into this with you offline, you know how to contact us. When we have a solution method we will post here for all customers to see.

[Doiron]

Hello David and all other Customers who might be experiencing this issue,

I just wanted to inform you that a Corrective Action Request has been filed with out Research and Development Department regarding this issue. We have identified the issue and are going to be validating a fix.

Thank you for bringing this to our attention.

[Josh_W]

Since several customers have run into this issue, we want to validate the fix as thorougly as possible. 

If you would like to help us validate the fix please post to this thread that it is OK for us to contact you directly by e-mail, and once we have your permission the forum Admin can contact you through your profile information.

[hansf]

Feel free to contact me via email.  Dave J is on vacation till Sept 2.

Thanks,

Hans

[bilby42]

Hi Dr Doiron,

I too have been trapped by the "error occurred calling LogResults in ITSDBLog of zNITestStand Database Logging", after we upgraded our production facility from TS 4.0 to TS4.1.

I have a couple of comments followed by a query.....

1/ I tend to agree with David J, regarding using the TS4.0 Database.seq instead of the TS4.1 Database.seq. It seems that this is just asking for future problems when we upgrade to TS4.2, 4.3, 4.4 etc etc. I would much rather fix the property name inconsistancy.

2/ I also became complacent, thinking a 4.0 to 4.1 upgrade would not be too extreme. Certainly I read the release notes, but due to the complexity of the TS system did not fully comprehend that several low level system parameters I was inadvertantly using would be "depreciated", hence breaking my system.

3/ I far prefer your second solution provided in this thread, i.e. "Use the new default schema and customize it how you like, then update your database". I have already done this with my customised process models, i.e. I've added my customisations to the default TS4.1 Batch process model and saved it as my new process model default.



Now for my question................
Due to good management (or luck), I've documented both my process model additions and my database schema additions. We based our database schema on the TS3.1 "Generic Recordset (NI) and write to a local Access database on each test system. I thought I would simply need to repeat my customisations with the new TS4.1 "Generic RecordSet", but to my dispair found it to be completely different to the old TS3.1 version.

Specifically we only used the old table statements "UUT_RESULT", "STEP_RESULT", "STEP_PASSFAIL", "STEP_NUMERICLIMIT" and finally "STEP_STRINGVALUE". We added a couple of columns to each of these statements to complete our customisation.

Unfortuately, I now find the TS4.1 "Generic Recordset (NI)" is missing "STEP_PASSFAIL", "STEP_NUMERICLIMIT" and "STEP_STRINGVALUE". STEP_NUMERICLIMIT2 seems very similar to the old STEP_NUMERICLIMIT but some of the columns are renamed.

I've found a button on the database schema tab labelled "reload NI schemas". This brings up a menu that allows loading of schemas from "TS4.1 and later" or "TS4.0 and earlier". Hence, do I simply reload the TS3.1 default schema and add my changes to recreate my system, or will I just add a whole new raft of incompatibilities?


Regards,
Tom Rolfe.

[hansf]

Hello,

Dave J and I work on the same test system.  We have made extensive changes and additions to the database schema including converting to MySQL, adding new tables, and adding many new statements.  Even though we know what those changes are, it would require an extensive amount of work to replicate the changes and then to verify that the changes were replicated correctly.  Since there is no way to verify the database statements before runtime, we would need to run tests that exercise each statement and then verify the data is stored correctly in the database tables.  That will be very time consuming for us.

Hans