An error occured evaluating the database logging Result Filter Expression

[Anh Doan]

Hi,
I use TestStand 4.1, and MySQL for the database.
In Database Options - Result Filtering Expression, when I select "Ignore Passed/Done/Skipped", or "Passed/Done Only", or "Exclude Flow Control", and run a simple sequence that has a For Loop, and an If steps, I got a Run-Time Erroras follows:
Details:An error occurred calling 'LogResults' in 'ITSDBLog' of 'zNI TestStand Database Logging'An error occurred evaluating the database logging result filter expression.Schema: MySQL Insert (NI)Unknown variable or property name 'Logging'.Error accessing item 'Logging'.Source: TSDBLog
Error Code:-17306; Unknown variable or property name.
Location:Step 'Log Results to Database' of sequence 'Log To Database' in 'Database.seq'
How can I fix this error?
Thank you
Anh

[Dr. Doiron]

Hi Anh,
 
Here are some resources I found by searching "17306" at ni.com that I think will be helpful to you:
 
<a href="http://digital.ni.com/public.nsf/allkb/193E1F81321003F986256ACE008121A3" target="_blank">Why do I Receive Errors -17306 and Error -17322 in TestStand?</a>
&nbsp;
<a href="http://forums.ni.com/ni/board/message?board.id=330&amp;message.id=3149&amp;requireLogin=False" target="_blank">Error code -17306; Unknown variable or property name</a>
&nbsp;
It looks like 'Logging' might not be the correct lookup string, double check that and let me know if this is the problem or not.
&nbsp;
&nbsp;

[Ray Farmer]

Hi,
Have you forgot to include the full lookup string for 'Logging' eg Locals.Logging.
Regards
Ray Farmer

[hansf]

Hello,&nbsp;We are getting the exact same error as Anh.&nbsp; We did not get this error until we to updated from TestStand 4.0 to TestStand 4.1. The error occurs in sequence Log To Database of&nbsp; sequence file Database.seq.&nbsp; This is a sequence file that ships with TestStand which we have NOT modified.&nbsp; See the attached screenshot of the sequence and the error. &nbsp;It looks like the variable Logging is supposed to be created in the first step of the sequence. This step and several other steps in the TestStand 4.0 version of Log To Database were ActiveX calls, while in TestStand 4.1 they are expressions.&nbsp; Perhaps a bug was introduced?&nbsp;Hans&nbsp;


TestStand 4.1 Database Logging Error.JPG:
http://forums.ni.com/ni/attachments/ni/330/20876/1/TestStand 4.1 Database Logging Error.JPG

[david_jenkinson]

Hello,I am now seeing the exact same error, preventing us from logging to the database.&nbsp; This happened right after updating to 4.1.&nbsp; When you hit &quot;break&quot; in the error dialog and browse the properties, the property &quot;logging&quot; does indeed exist, along with the subproperties in the result filter expression it is complaining about, so the error seems bogus.&nbsp; Any idea what to do?&nbsp; I did a &quot;update sequence files&quot; on all of our sequences we use, thinking there might be&nbsp; type conflict somewhere, didn't help though.&nbsp;David Jenkinson Message Edited by david_jenkinson on 08-14-2008 12:27 PM

[Josh W.]

David et al,&nbsp;I think what has happened is that there is an incompatibility between the custom Database Schema you are using and the new TestStand 4.1 Process Model.&nbsp;Info&nbsp;According to the <a href="http://www.ni.com/pdf/manuals/372519m.pdf" target="_blank" title="TestStand 4.1 Release Notes"> TestStand 4.1 Release Notes</a> &nbsp;there were some changes made to the Logging property.&nbsp; Documented under Behavior Changes (pp 13)&nbsp;:&nbsp;
Logging.StepResultProperty is deprecated. Instead, use Logging.PropertyResult to reference the property of a step result the database logger is processing. In addition, the context includes the Logging.PropertyResultDetails container, which contains information about the property Logging.PropertyResult references.
You can also find this information in <a href="http://digital.ni.com/public.nsf/allkb/434A751B66D419F6862574500053BDBF?OpenDocument" target="_blank"> KnowledgeBase 4LK9CPT3: Known Compatibility Issues and API Changes for TestStand 4.1</a> .
&nbsp;
Also, on the previous page of the release notes, there is a long note at the end of the page which can be summarized as: Mixing components from earlier versions of TestStand with components in TestStand 4.1 may not work.
&nbsp;
Possible Solutions
I looked at the screenshot attached and noticed that you are using a custom schema.&nbsp; Since you are upgrading, this schema was made to use the 4.0.x version of the Logging property.&nbsp; According to the release notes, the Logging property has changed in TestStand 4.1, and I believe that this is what is causing your problem.&nbsp;
&nbsp;
What I reccomend is that you use the entire process model from TestStand 4.0 even though you are running TestStand 4.1.&nbsp; Make sure that you use not just the process model sequence file itself (such as sequentialmodel.seq), but also the other dependent files (such as Database.seq).&nbsp; It may work if you just use the 4.0 version of Database.seq rather than the 4.1 version of that sequence file, however I have not tested it, and there may be incompatibilities between the 4.0 version of that file and the 4.1 model sequence file.

[david_jenkinson]

Josh,In our case, we are using a highly customized process model, lots of edits.&nbsp; So we are already using the &quot;4.0&quot; process model, although it's data types might have been updated as a result of the 4.1 install.&nbsp; &nbsp;So it seems our resolution may be to either use the old database.seq (which I can't presently find for some reason), or update all of our property strings to the new ones in our schema, whatever those properties may be?&nbsp;&nbsp; It would require some sort of mappings as to what new variables map to the old ones?&nbsp; Is this information available?&nbsp;Why were the properties renamed? &nbsp; &nbsp;Is there any mechanism, or means of reading about &quot;compatibility issues&quot; prior to installing new versions?&nbsp; We are on a license agreement, and although I like the additions of some of the features of new versions, I wonder sometimes if it is worth the seemingly inevitable compatibility issues between versions. &nbsp; We've had issues like this in the past that are kind of show stoppers for our testing and that is a bad thing.&nbsp;David Jenkinson

[Dr. Doiron]

Hello David,&nbsp;The information you are requesting is available in the TestStand 4.1 Release Notes, which you can find in the &quot;Manuals&quot; folder in TestStand or online at ni.com (search TestStand release notes). &nbsp;It looks like you have two possible solutions moving forward:&nbsp;1) Use the 4.0 database.seq file.2) Use the new default schema and customize it how you like, then&nbsp;update your database. &nbsp;Let me know if you have any questions about the release notes.

[david_jenkinson]

When upgrading, I uninstalled 4.0, then installed 4.1, on all stations.&nbsp; So a copy of the database.seq was not readily available unless I reverted on one or more stations to 4.0.&nbsp; I have reverted to teststand 4.0 on a couple of our stations, since we needed to get running again.&nbsp; Luckily we are using perforce so I was able to recall a label I make prior to the upgrade, containing all of our sequences/processmodel/type palette etc.&nbsp;As for the solutions moving forward, I appreciate your options, but here are my concerns: &nbsp;For option 1, I could install 4.1 again, and use the 4.0 database.&nbsp; This would be a temporary solution, until the next upgrade, when we run into the problem again upon upgrading.&nbsp; This is not the greatest option, as we have a volume license agreement.&nbsp; The whole reason we bought the volume license agreement is to get automatic updates as they are available.&nbsp; This is becoming less of an attractive option as of late, so we may re-evaluate our licensing options. &nbsp;For option 2, our schema was made from a copy of a schema included with teststand, and has been modified quite a bit.&nbsp; So the &quot;customize it as you like&quot; part might not be so trivial to duplicate, especially since most of those edits were not done by me, but by a person who is no longer with us full time, but on a part time, contracted as needed basis.&nbsp; He may be getting a PO soon, or not... &nbsp;&nbsp;Our other option is to just continue using teststand 4.0, which kind of makes the advantage of the volume licensing moot, but that can be remedied.&nbsp; &nbsp;I do have a couple questions.&nbsp; A problem like this has the tendancy to cause real headaches in critical test applications, which has the tendancy to make certain individuals look bad.&nbsp; I would more expect a change like this to be going between major versions, such as 4.0 to 5.0.&nbsp; On the surface, a 4.0 to 4.1 upgrade seemed harmless to me, but turns out not to be the case.&nbsp;&nbsp; It actually prevented us from logging results to our database, kind of important in our application.&nbsp; From the verbage of the change, this looks to be a trivial property name change, from one name to a very similar one.&nbsp; What was the purpose of this change?&nbsp; Was this change really that necessary?&nbsp; This seems on the surface to be a &quot;if it ain't broke, don't fix it&quot; scenario, but of course, I could be wrong (as has been recently demonstrated).&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

[Dr. Doiron]

Hello David,&nbsp;I have a few points.&nbsp;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)&nbsp;2) The Volume License Program has a number of different advantages, from ni.com:&nbsp;&quot;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&quot; &nbsp;You can use a previous version of the software, although it is not recommended.&nbsp;&nbsp;3) In the release notes we specifically mention why these options were changed, page 16 has most of the information, the main reason being: &quot;TestStand 4.1 updates the default database schema in the following ways to
support logging additional results:&quot; There is some great added functionality that required this change to implement.&nbsp;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.&nbsp;Please let me know if you have any other questions.&nbsp;

[david_jenkinson]

Just an added bit of info, I have attached a screen shot of our error, which indicated it doesn't like our database filter expression.&nbsp; I've copied the error message, our filter expression, and the property browse tree in the screen shot to show that the property does indeed exist, though the error message seems to indicate otherwise.&nbsp;


teststand4.1 database error.png:
http://forums.ni.com/ni/attachments/ni/330/20890/1/teststand4.1 database error.png

[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? &nbsp;&nbsp; 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). &nbsp; Would the changes be limited to changes in our schema, as in what teststand variable the fields point to in the tables?&nbsp; Will search/replace work for this?&nbsp;David J.