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:
Any advice would be appreciated! asked 09 Jan '14, 09:54 kl_seeger Graeme Perrow |
I thought of two things (there are likely more) that you should consider:
answered 09 Jan '14, 10:18 Jason Hinspe... 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".
(09 Jan '14, 11:18)
Breck Carter
This page documents the versions of Windows supported by 11.0.1. For older versions, this information can be found here.
(09 Jan '14, 11:26)
Mikel Rychliski
1
As is stated at the start of that page:
(09 Jan '14, 11:31)
Jason Hinspe...
|
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. answered 12 Jan '14, 23:40 Liam 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 :)
(13 Jan '14, 15:13)
Breck Carter
|
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. answered 10 Jan '14, 08:19 Dmitri I agree with Dmitri.
(10 Jan '14, 08:55)
Breck Carter
I also agree with Dmitri.
(10 Jan '14, 10:46)
Derli Marcochi
|
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...". answered 11 Jan '14, 06:15 Volker Barth |
Many thanks for all your comments, hints and tips posted so far. answered 14 Jan '14, 01:30 kl_seeger |
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. answered 13 Jan '14, 14:13 sybase46 |
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.