|
Hi Using SQL Anywhere 12, we have a remote server defined which is in productive use for quite a while. Having installed SQL Anywhere 16, everything runs fine except the remote server is not working any more. With Sybase Central version 12, when creating a new remote server, the Wizard asks for: Provide Connection Details and I can choose JDBC. In Sybase Central version 16, there is no possibility to specify the Connection Details. The Wizard sets ODBC. What does invalid server class mean and what can I do to get the correct server class? Why can't I specify Connection Details any more? What about the JDBC connection of the previously set remote server and how to get it to work again? Thanks a lot for any help. Robert
|
|
AFAIK, with 12.0.1, all JDBC-based server classes (primarly SAJDBC and ASEJDBC) were deprecated, and with v16, they were discontinued. Here's what 12.0.1 tells for class SAJDBC:
Given that, I guess you will have to use ALTER SERVER to modify the class to use the according ODBC-based class, possibly using a DSN-less connection. Hi Volker Thanks for your hint. I understand Sybase stopped supporting JDBC for Remote Servers with Version 16. Now I am trying to get a clearer picture what to do to get it running on OS X. On OS X (Unix), the data source is the .odbc.ini file, as far as I understand. Contrary to the Sybase documentation (http://dcx.sybase.com/index.html#sa160/en/dbadmin/connect-s-3731160.html), there is no Apple delivered ODBC Administrator tool any more - since Mountain Lion. So I tried the dbdsn tool to create the .odbc.ini file, which works. Interestingly, only with the one in .../bin64s. I can't remember why there is always a bin64 and bin64s folder? The content of my .odbc.ini file does not seem to be correct, as I still always get an error (with various trials). The .odbc.ini is also placed by default in the root of the user account. I am not sure if this is the right place. Have you got the minimum data to make the ODBC connection work. And what do you mean by: DSN-less connection? Thanks in advance Robert
(26 Nov '15, 06:10)
robert
Replies hidden
Robert, a DSN-less connection is based on a connection string that does not refer to a DSN entry (which requires a registry entry under Windows for normal user or system DSNs or requires a FileDSN) but instead names the required driver explicitly by using the DRIVER= connection parameter. Note, this goes for Windows, I'm not using Unix nor OS X, so I hope others can give further hints. Just one wild guess: That FAQ deals with a feature which has been introduced with 12.0.1 and might be of help here (if working on OS X...):
Given that, I guess your connection string could be quite similar to that of your former JDBC-based remote server.
(26 Nov '15, 06:21)
Volker Barth
Volker, great idea! It works :-) By "Remote data access can load the SQL Anywhere ODBC driver directly" you mean, executing a CREATE SERVER <server_name> CLASS 'SAODBC' USING 'DRIVER=SQL Anywhere Native;...' statement is sufficient to create a working Remote Server, do you? I have successfully tried the following CREATE SERVER statement: CREATE SERVER hades_remote CLASS 'SAODBC' USING 'DRIVER=SQL Anywhere Native; UID=<uid>; PWD=<pwd>; HOST=localhost:2638; DBN=Hades'; Thanks for the tip. So easy, and I tried so long :-o
(26 Nov '15, 13:34)
robert
Replies hidden
By the way, have you an idea why SAP removed the JDBC connection and requires the ODBC connection on SQL Anywhere 17 (and 16, for that matter)
(26 Nov '15, 13:35)
robert
Replies hidden
Note, those have not been my words, I was just citing the docs... But the meaning is different: A CREATE SERVER statement does usually work (unless there are syntax errors), even when refering to a non-existing DSN. AFAIK, SQL Anywhere does simply create the according definition in the system table (SYSSERVER) then, it does not try to connect to the remote server, so it will not check whether this will succeed or not... - The physical access usually only happens when one tries to create proxy tables, and then suddenly notices that the remote server is not available/misconfigured... So, the "can load directly..." is not related to the CREATE SERVER statement execution but to the later accesses to the remote server (i.e. when accessing proxy tables or using FORWARD TO statements and the like). In my understanding, the particular "native driver" specification omits the ODBC driver manager then and therefore is "more direct" (and may therefore succeed in your case when the ODBC driver manager seems to be missing or not working - as stated, I can't comment on the OS X needs...).
(26 Nov '15, 14:32)
Volker Barth
AFAIK, it has been partly made for performance reasons (ODBC is usally faster than JDBC via jConnect) and probably also because the JDBC-based server classes seem to have used an internal Java VM which has been eliminated - but see, I'm just another customer, so that's just guessing... The docs do tell that for the deprecated JDBC-based classes (yep, I'm quoting again...):
(26 Nov '15, 14:56)
Volker Barth
|
