Proceedure to downgrade

Archived Topics
1

Due to some issues we had with the latest version 4.2.5 we choose to go back to an earlier version 4.1.5 However when we did so we had some problems. When we uninstalled the newer version then installed the older version it first off did not pickup the project then when we choose to do a restore it appeared like it restored things but then it would not connect to the service and did not show any of the configured items. I know that the backup was done under the 4.1.5 version so that should not have been it. So if you could please tell me the proceedure you recommend when going backwards in versions.

Also I still have the overlay issue with the PMI. Not sure if the two are related.

Thanks and have a great day.

PS almost forgot the only was we could get the system back up was we did a merge then went back and reconfigured all the drivers. When I left it seemed to be working but tomorrow will tell for sure.

2

Do you have a backup from your previous 4.1.5 version? That would be the thing to use. Trying to restore using a backup from a version from the future is called forwards-compatability (the opposite of backwards-compatability), and no we don’t support that. (nor does anyone else, because it would completely hamstring progress)

Like I said on the thread about the overlay issue - I think we’ll need to see it, I wasn’t getting the picture over the forum. Give us a call and we’ll take a look.

3

Since you mentioned that you’re backup was from 4.1.5, you’re right that you shouldn’t have had a problem. It’s hard to say what happened exactly, but I’ll take this opportunity to mention a few helpful points that many people might not know:

  1. Auto-backups are created during installation and each time you do a “system restore”. The are located in the FactorySQL install directory, under “auto_backups”.
  2. Any backup with a *.fdb extension is the complete system database. If it is named “system_database.fdb” and placed in the FactorySQL installation directory (usually c:\Program Files\Inductive Automation\FactorySQL), it will be the system db that FSQL uses. Therefore, all a system restore does is replace this file, and restart the service (though not literally, more of a “soft restart”). We’ve seen file locking issues occur from time to time when doing a system restore- you can actually manually restore fairly easily by stopping all FSQL applications and putting the desired “system_database.fdb” file in the main folder.
  3. When uninstalling FactorySQL: any files not created by the installer should remain after uninstall (including backups, system_database.fdb, etc). It wouldn’t hurt, however, to go in and make sure that all DLLs have been removed. If they haven’t , they’re probably locked somehow, and if that’s the case, won’t be updated properly on re-install. A Windows reboot usually takes care of file locking issues (side note: there’s not a good reason why the files should be locked, but I’ve seen it happen).
  4. The FactorySQL frontend, when in a “disconnected state”, pulls all of its settings information from the local system_database file. Therefore, if after a restore you can’t connect, but can still go to Settings and see all of the correct settings from the restore, you should go check the error log to see if you’re getting any messages concerning service start up. There are basically 2 things you can do to make sure everything is correct from the file system point of view: A) Open the frontend (disconnected), check the settings. B) Go to File->Open Project and open the system_database.fdb file directly. If both your settings and groups are correct, the file is fine, there’s just some other (probably small) problem.
    NB: After opening a project with File->Open Project, it is NOT a good idea to change the groups, start/stop them, etc. unless you’re going to restart the service. These changes, made when the frontend is “disconnected”, do not get applied until the service starts up again.

Hope these tips help everyone out a bit.

4

Hi,

Can you let me know what issues do you have with 4.2.5? I just installed and I want to check for does before I send the system to our customer.

[quote=“mrtweaver”]Due to some issues we had with the latest version 4.2.5 we choose to go back to an earlier version 4.1.5 However when we did so we had some problems. When we uninstalled the newer version then installed the older version it first off did not pickup the project then when we choose to do a restore it appeared like it restored things but then it would not connect to the service and did not show any of the configured items. I know that the backup was done under the 4.1.5 version so that should not have been it. So if you could please tell me the proceedure you recommend when going backwards in versions.

Also I still have the overlay issue with the PMI. Not sure if the two are related.

Thanks and have a great day.

PS almost forgot the only was we could get the system back up was we did a merge then went back and reconfigured all the drivers. When I left it seemed to be working but tomorrow will tell for sure.[/quote]

5

The issue he had (correct me if I’m wrong) was that he had block groups that didn’t error-out in his previous version that started to error-out in 4.2.5. The thing is, they should have errored out in the previous version to be more adherent to the OPC spec. So it might seem ‘wrong’ that something stops working in a newer version, but sometimes, it is the correct action.

6

Thanks for the info Carl

7

Yes Carl the problem was with a block group. The problem was indeed a write error but it was in three parts were I came up with the error.

  1. The one error had to do with a tag which was controlled via a script. This script monitored the SQL server time and every hour on the hour triggered the tag which was written to all the PLC units on the production floor which are currently enabled. If the unit was not enabled it would not write to the location. Under 415 this script worked but for some reason it errored out and I could not get it working properly again in 425.

  2. In the block group in question under 415 it would read/write to the SQL table a boolean tag. THe table field was set up as INT. Under 425 it did not like this cross units. If it was writing a boolean it wanted to see boolean in the table not int. Once I changed the field from int to boolean that corrected this problem. Nothing to major.

  3. In version 415 if a group was reported as E_fail it did nothing, but for some reason 425 if a group/tag is reported as E_fail it still tried to write to it then it would just error out the block group and would cause it to never report completion.

These were the three errors we had.

8

Thanks for posting these points. We’ll take a look at them and see what should be changed back or not. For example, the boolean fields types probably should work just fine with integer columns (though sometimes these types of things also depend on the specific database connector). Writing to e_fail items… I believe it tries to write now because the theory goes that they could fail out at any time and come back at any time, and the group shouldn’t just keep running happily if they’re errored. However, in your case they’re expected to be failed, and you want to just write to the good ones. Perhaps this should be some sort of an option.

Regards,