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.
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?
>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.
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
2. Copy the attached file into Program Files\National Instruments\TestStand
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.
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.
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.
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.
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.