Given a random GW backup how can you tell what version is was from?

Ignition
1

In my on going saga with looking at this client’s backup that I restored to my 8.1.3 system I was hit (but didn’t realize for a couple of hours) with java.sql.SQLException after migration 7.9 to 8.1 and with SQL Server 2005 Database Connection

I didn’t know that this was a thing as I was restoring onto a system with MS SQL 2019.

It would have saved me a large amount of frustration and stress if I knew what version of Ignition the backup was made from.

So given a random GW backup, how do I know what version of Ignition it was made from, so that I can restore it to a matching system?

2

Someone beat you to asking by 2 hours :slight_smile:

3

That’s because I spent the last 2 $&%^$^ hours trying to understand why I couldn’t get my DB connection to work :rofl:

1 Like
4

I just looked at the backup I have, and it’s 8.1.2. Now I’m confused as to how an upgrade from 8.1.2 to 8.1.3 could have triggered that issue :thinking:

5

If the source of the backup never fixed their install after upgrade…

6

But it’s a working system. :thinking:

Although their DB connector has name of the form “Host-SQL2K8”, which is kind of worrying to me if they are still using 2K8.

7

JDBC drivers aren’t part of a backup, I would guess that they have a different/older JDBC driver installed than you do.

8

That’s what puzzles me. If I have a fresh 8.1.3 install and restore a project, because the drivers aren’t included, I would have expected the restored project to use the drivers in the new system and not cause an issue.

But instead a had a crash and burn situation and only recovered by manually constructing the DB connector in the new system and then extracting the project from the backup and only importing that.

9

JDBC drivers are part of a backup, deliberately - under the assumption that it’s better to maintain old drivers forever (and only update when manually applied) than to ‘suddenly’ break on an Ignition update.

10

Whoops!

Well then maybe that’s why it exploded? Old JDBC driver + new SQL Server on the machine he restored to?

1 Like
11

So it becomes a trade off between which system you want to break. I would guess that for a typical site would change DBs less often than you change Ignition installations, so that it would make sense not to break the DB connection on an upgrade.

But from the point of view of someone who looks at a variety of systems from different clients, it makes the DB version a hidden dependency that I need to know about.

Which then raises the question - From a random GW backup, how do I identify these hidden dependencies?

12

Same way you find the version–unzip the backup and look.