From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-22-2008 12:21 PM
07-23-2008 09:07 AM
07-23-2008 09:52 AM
Hi,
Have you forgot to include the full lookup string for 'Logging' eg Locals.Logging.
Regards
Ray Farmer
08-13-2008 03:04 PM
Hello,
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?
Hans
08-14-2008 12:26 PM - edited 08-14-2008 12:27 PM
Hello,
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 Jenkinson
08-14-2008 12:44 PM
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.
Info
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.
Possible Solutions
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.
08-14-2008 01:03 PM
Josh,
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.
David Jenkinson
08-14-2008 06:14 PM
Hello David,
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.
08-14-2008 06:15 PM
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.
08-14-2008 06:49 PM
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).