Upgrading from 11-1-2472 to 12 or 16 - any advice?

[Former Member]

Hello and a good afternoon,

We are running a GUI-fat-client C-application (generated with CA GEN)on Windows 7 with SQL Anywhere 11.0.1-2472 as local DBMS (connection via ODBC).

Since this application should go "off duty" in 2014 we did not spend time on a task to upgrade SQL-Anywhere so far... (what a mistake :-))

Unfortunately some plans have changed and we have to run the application until the middle of 2016.

Since the EOL for the 11.0.1 is announced for end of May this year we have to decide whether we:

• can take the risk to stay on 11.0.1
• should upgrade
  • to Version 12 or
  • to version 16

Any advice would be appreciated!

[Former Member]

For what it's worth: we have been using SQLA since version 3 and have found the upgrades to be easy and painless. We recently upgraded one our 7GB databases from v11 to v16 in an hour. BTW: You can upgrade the database server to V16 and leave the ODBC client alone.

So yes, do read the notes as Jason suggested, and you might run into an upgrade glitch that takes a little time to sort out, but SQLA upgrades are generally painless. A version 11 to version 16 upgrade should be an easy task and not to be dreaded.

[Former Member]

We recently upgraded our solution from 11 to 16 and it was painless. The only hiccup was self-induced by introducing materialised views, which caused me a number of 'Right-Truncation' errors as a result of changing my default behaviour in the database.

The fact remains, 2016 is still some way off, and from what I've experienced during the upgrade (improved cache handling, better query optimisation, and serious bug fixes on scjview), the upgrade is well worth it.

[Breck_Carter]

My experience was similar to Liam's: upgrading from 12.0.1 to 16 was painless, for an application (Foxhound) where 99.9% of the code resides inside stored procedures. The only glitch was a minor "privilege drift" brought by the new security model, wherein BACKUP DATABASE privilege is no longer sufficient to run dbbackup -x... a truly minor quibble in a world where most everyone runs it with DBA privilege 🙂

[Former Member]

I thought of two things (there are likely more) that you should consider:

1. After the EOL date, no further bug fixes will be released for v 11. This means that if you run into a problem that is a bug in the software, you will have to work around it. However, if you have been successfully deployed with your application for a significant period of time, and are not planning any updates to it, the chances of this happening are not likely that high.
2. There will also not be any updates for new versions of OS's that are released after the EOL date. The existing software may or may not work on the new OS

If you decide to upgrade, you should read through all of the Changes and Upgrading sections of the documentation for each release - 12.0.0, 12.0.1 and 16.0

[Breck_Carter]

What exactly does this statement mean, for Windows? "There will also not be any updates for new versions of OS's that are released after the EOL date."

The SQL Anywhere 11.0.1 Components by Platform page does not list any version numbers for Windows, only "Microsoft Windows - x86, x64, Mobile".

[former_SQLA_member1694878]

This page documents the versions of Windows supported by 11.0.1. For older versions, this information can be found here.

[Former Member]

As is stated at the start of that page:
"Information about support for a specific operating system version is located at SQL Anywhere Supported Platforms and Engineering Support Status."
Following that link will redirect you here (sap.com😞
SAP Sybase SQL Anywhere Supported Platforms and Engineering Support Status
Once the EOL data is reached, the table for 11.0.1 will be marked as "Archived" and no longer updated as new versions of the various OS's come out.

[VolkerBarth]

If that is an one-site installation (i.e. you don't have to support a bunch of setups, possibly at different locations), there's also the option - in case you would face problems in the near future - to let the current v11 database run with a newer database engine (v12 or v16). So in case you would need to fix a problem, you would not necessarily have to upgrade/rebuild the database - you could just use a copy of the current database and find out whether the newer database engines solve that problem...

We had an issue with a v8 database once (that was fixed in v8 some monthes later, due to its then "limited" support) where we had noticed later that we could have solved that case immediately with just running that database once with a newer v9 engine. Not knowing that, we had to restore from a backup - that had worked, too, but the whole issue has showed me the importance of the option "in case of problems, test the current database with the newest engine available that can run that database...".

[former_SQLA_member1694880]

Given that your application's days are numbered, I see no sense in server upgrade unless you have some specific problems that upgrade is going to solve. As for the EOL... well, I don't care about it, server won't stop working at 01.06.2014 :). Anyhow, if you proceed with upgrade I strongly recommend you to move to the latest SA version (V16) and to thoroughly test your application against the new server.

[Breck_Carter]

I agree with Dmitri.

[former_SQLA_member1694870]

I also agree with Dmitri.

[Former Member]

Many thanks for all your comments, hints and tips posted so far.
The current status of our internal discussion is that we would like to start with a test of the current application-configuration on Windows 8.1 to get "gut feeling" for possible upcoming problems on a higher windows-version. Depending on the results there will be more or less pressure to follow one of the suggested upgrade pathes.

[Former Member]

Pretty easy and painless unless your upgrading HA (Mirroring) Sybase put all the config parameters in the database and the documentation doesn't convey a Mirror upgrade from 11x to 12x but from 11x or 12x to 16x. Plus, the documentation is pretty vague which seems to be SAP Sybase Modus Operendi. I can honestly say I have never encountered such vagueness to include very little if any CONCISE documentation like other Vendors such as SQL Server and Oracle have. Were using Sybase IQ and ASA and SAP Support guesses at it just like we do. I usually have it figured out before Tech Support can give me a solution.