Have you forgot to include the full lookup string for 'Logging' eg Locals.Logging.
We are getting the exact same error as Anh. 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 sequence file Database.seq. This is a sequence file that ships with TestStand which we have NOT modified. See the attached screenshot of the sequence and the error.
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. Perhaps a bug was introduced?
I am now seeing the exact same error, preventing us from logging to the database. This happened right after updating to 4.1. When you hit "break" in the error dialog and browse the properties, the property "logging" does indeed exist, along with the subproperties in the result filter expression it is complaining about, so the error seems bogus. Any idea what to do? I did a "update sequence files" on all of our sequences we use, thinking there might be type conflict somewhere, didn't help though.
David et al,
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.
According to the TestStand 4.1 Release Notes there were some changes made to the Logging property. Documented under Behavior Changes (pp 13) :
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 KnowledgeBase 4LK9CPT3: Known Compatibility Issues and API Changes for TestStand 4.1.
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.
I looked at the screenshot attached and noticed that you are using a custom schema. Since you are upgrading, this schema was made to use the 4.0.x version of the Logging property. 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.
What I reccomend is that you use the entire process model from TestStand 4.0 even though you are running TestStand 4.1. 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). 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.
In our case, we are using a highly customized process model, lots of edits. So we are already using the "4.0" process model, although it's data types might have been updated as a result of the 4.1 install.
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? It would require some sort of mappings as to what new variables map to the old ones? Is this information available?
Why were the properties renamed?
Is there any mechanism, or means of reading about "compatibility issues" prior to installing new versions? 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. We've had issues like this in the past that are kind of show stoppers for our testing and that is a bad thing.
The information you are requesting is available in the TestStand 4.1 Release Notes, which you can find in the "Manuals" folder in TestStand or online at ni.com (search TestStand release notes).
It looks like you have two possible solutions moving forward:
1) Use the 4.0 database.seq file.
2) Use the new default schema and customize it how you like, then update your database.
Let me know if you have any questions about the release notes.
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. 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.
When upgrading, I uninstalled 4.0, then installed 4.1, on all stations. So a copy of the database.seq was not readily available unless I reverted on one or more stations to 4.0. I have reverted to teststand 4.0 on a couple of our stations, since we needed to get running again. 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.
As for the solutions moving forward, I appreciate your options, but here are my concerns:
For option 1, I could install 4.1 again, and use the 4.0 database. This would be a temporary solution, until the next upgrade, when we run into the problem again upon upgrading. This is not the greatest option, as we have a volume license agreement. The whole reason we bought the volume license agreement is to get automatic updates as they are available. This is becoming less of an attractive option as of late, so we may re-evaluate our licensing options.
For option 2, our schema was made from a copy of a schema included with teststand, and has been modified quite a bit. So the "customize it as you like" 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. He may be getting a PO soon, or not...
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.
I do have a couple questions. 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. I would more expect a change like this to be going between major versions, such as 4.0 to 5.0. On the surface, a 4.0 to 4.1 upgrade seemed harmless to me, but turns out not to be the case. It actually prevented us from logging results to our database, kind of important in our application. From the verbage of the change, this looks to be a trivial property name change, from one name to a very similar one. What was the purpose of this change? Was this change really that necessary? This seems on the surface to be a "if it ain't broke, don't fix it" scenario, but of course, I could be wrong (as has been recently demonstrated).