SQL Central Compatibility

[VolkerBarth]

What is the SQL Central compatibility between 17.0.4 and 17.0.10? Our current server running 17.0.4.2053 I have the 17.0.4.2053 Admin packaged by our IT department on my desktop.

Upgrading to a new server, I installed and tested against 17.0.4.2053, all was good. Upgraded the server to 17.0.10.6285 and I get this compatibility error when connecting from my desktop:

SQL central cannot connect to this database because it is running on a version 17.0.10 server. (You cannot connect to a database running on a version 17.0.10 server with version 17.0.4 SQL Anywhere plug-in.)

I thought SQL Anywhere was fairly agnostic when it comes to SQL Central.

It'll be a real pain to re-package the admin s/w. What are the compatibility rules for SQL Central?

[VolkerBarth]

According to the docs on "SAP SQL Anywhere 17.0 Components by Platforms":

Compatibility with existing SQL Central (formerly Sybase Central) software

Full support - The SQL Anywhere plug-in for SQL Central fully supports any database created by version 12 or later software running on a version 12 or later server. For example, version 12 databases running on version 12, 16 or 17 servers; version 16 databases running on version 16 or 17 database servers; and version 17 databases running on a version 17 database server.

Apparently your situation tells a different story.

[timcheshire]

Hi Volker. That's what I thought, V12-17 should be compatible. I have another server being built to replace one with 17.0.9 so will test against that one. Might take a few weeks depending on the server team. Tim

[Breck_Carter]

The "Compatibility" statement talks about backward compatibility. This situation may be more proof that 17.0.10 is really version 18.

[Breck_Carter]

> a few weeks depending on the server team

Who is Mordac? 🙂

[timcheshire]

🙂 Can't wait to ask them to re-package the 17.0.10 admin install.

[Breck_Carter]

> ask them

LOL 🙂

Seriously...

The Administration Tool Deployment on Windows describes what you have to include in your deployment of SQL Central, in the topic Step 2: Copy the Required Files:

The SQL Anywhere plug-in of SQL Central requires the personal server (dbeng17.exe and supporting files) and the following files.

In other words, if you want to deploy SQL Central to a client computer, you have to include the SQL Anywhere engine as well.

That makes SQL Central very different from any other client software... in fact, it defines SQL Central as a "server extension" rather than a client application.

[jack_schueler]

The referenced page has been updated to make it clear that within the major versions (17,16,12) there is an ordering to the major.minor.patch number such that the capabilities of version major.minor.patch are not necessarily supported in version major.minor.patch-1 or earlier.

[VolkerBarth]

Well, the Deployment Wizard can do it for you (and knows the requirements), just choose to include SQL Central within the according admin tools... - and you do not need to include the database options...

[jack_schueler]

There is no time machine built into SQL Central. Unlike some other tools, this one has very intimate knowledge of the workings of the servers that were in place at the time that version of SQL Central was published. It does not know the future. So while a 17.0.n version of SQL Central knows everything about n, n-1, etc., it has no idea what might be changed in n+1, n+2, etc. There's a reason the computer software industry uses the term "backward compatibility" and, not very often, "forward compatibility". The same thing applies to other client software. For example, the 17.0.n ODBC driver might let you use it against a 17.0.n+1 server, but there is no guarantee that you would get 100% correct behaviour (perhaps a new system table was introduced or a new data type). You should always use the latest client software.

[Breck_Carter]

> You should always use the latest client software.

If client software is not included, what is your definition of "backward compatibility"?

[Breck_Carter]

> the 17.0.n ODBC driver might let you use it against a 17.0.n+1 server, but there is no guarantee that you would get 100% correct behaviour

OMG! 🙂

I do not know of ANY installation that forces ODBC driver updates onto client computers every time they upgrade servers to a new build of dbsrv17.exe.

[VolkerBarth]

Jack, the quoted doc in my comment on the question does not mention backward compatility...

In the (probably rare) case a new server feature would require a new SQL Central plug-in, I would expect a readme entry to explain that... (based on my positive experience that SQL Anywhere generally is very well-documented).

I would agree that SQL Central is a particular client app, so there might be more need to keep up with the server version. For regular client apps, I guess it's very common to update them rarely.

[jack_schueler]

Who said "build"? I said version as in 17.0.9 and 17.0.10. Suppose that the server introduced a new datatype called "timestamp with time zone". Would you expect your old ODBC driver to report that as one of the supported data types? Would you expect the old ODBC driver to be able to handle that data type correctly? No one "forces" you to update the ODBC driver, but it would be good to do so. Each time we increment the version number (major or minor part), you could bet that there are some new features in the software.

[jack_schueler]

@Volker I do agree with you there. I think that the statement is a bit "loose" on what a version is. For example, there was a version 12.0.0 and a 12.0.1 and everyone would agree that a similar statement made about "version 12" would have been (or was) wrong. Whoever wrote the article knew about integers (17 > 16 > 12) but didn't know about our "Dewey" decimal number ordering.

Technically, the piece only refers to "databases" not server versions. We all know that a new 17.0.10 database might not run on a 17.0.4 server (have you ever seen the capability message?).

[Breck_Carter]

> Would you expect your old ODBC driver to report that as one of the supported data types? Would you expect the old ODBC driver to be able to handle that data type correctly?

Please stop raising invalid straw man arguments. Nobody would expect, or need, an existing ODBC driver to handle new features introduced inside a DBMS product, nor would they expect, or need, any data traffic using the new features. One of the reasons ODBC exists is to isolate clients from the internal workings of the DBMS.

> No one "forces" you to update the ODBC driver, but it would be good to do so.

No one "forces" me to agree with you, either 🙂

[jack_schueler]

Nobody would expect, or need, an existing SQL Central tool to handle new features introduced inside a DBMS product. SQL Central lets you know up front that it can't deal with the new features of the server.

[timcheshire]

My thoughts here are these are minor version EBFs. Not, for example 17.0 to 17.1. What is so significant that the Admin S/W isn't compatible.

All of the organisations I do work for "package" their desktop installs so to simply say we should upgrade is not a straightforward exercise.

[jack_schueler]

Our minor version EBFs are reflected in a 4-digit build number. For example, 17.0.10.1234, 17.0.10.1235. Any time you see a change in the first 3 numbers, it will mean a new version will some significant changes. In the original post, it indicates that you chose to upgrade to 17.0.10 server software but not upgrade the corresponding client tools. I think the guiding principal for SQL Central is "try to guarantee correct behavior in all situations" and that is something that cannot happen if old versions of SQL Central were allowed to inter-operate with newer versions of database servers (you could imagine all the technical support calls we would be getting from folks asking why something did not work correctly).

[VolkerBarth]

Any time you see a change in the first 3 numbers, it will mean a new version with some significant changes.

For older version (pre V16), this was easily understandable, because there always were a "What's new in ..." doc topic with those changes. However, for v17, there is much less obvious connection between the 17.0.x minor version numbers and the corresponding changes. (AFAIK, sometimes the minor version is increased just because some different SAP software which includes SQL Anywhere has a new version...)

In other words: I would not know from the docs what has been changed between 17.0.6 and 17.0.8, for example, and it would also be difficult to tell from a customer perspective what build belongs to what minor version. And was there ever a 17.0.1 - 17.0.3 or a 17.0.5?)