Here is my situation. I have an application (Mirth Connect) running on the same server as SQL Anywhere 11. There is also another server on the same network running SQL Anywhere 11. I need to connect to both of them. They are both using the same SQL Anywhere "Server Name".
I need to use a JDBC connection to connect to either of them at any given moment. I can connect to the local instance just fine.
I tried to set up an ODBC connection to the remote server. When I test the connection it says it is all good. Then when I try to run a query I notice I am connected to the local server. It must be because both SQL Anywhere servers are using the same "Server Name".
How do I force the ODBC connection to connect to the Remote server?
Thank you!
You need to specify the IP address (and port, if not using the default) in the connection string. Your connection string must contain the LINKS parameter, with (at least) the following options:
LINKS=tcpip(HOST=<remote IP address>;PORT=<remote port>;DoBroadcast=None)
If the remote server is using the default port number, 2638, you don't need to specify the port number in the connection string. DoBroadcast=None tells the client library that it should make a direct connection to that host. The default (for version 11 and older) is to broadcast on the network looking for that server name, and whichever server responds first wins. Since there is a server on the local machine, it is very likely to respond first.
For version 12 and up, you can replace the entire LINKS parameter with the new HOST parameter:
HOST=<remote IP address>:<remote port>
which will have the same behaviour as the LINKS parameter above.
P.S. It is recommended that you give each server a unique server name, thus avoiding the need to hard-code the IP address of the host. Not to mention that you must be using some trickery to fool the second server into either (a) thinking its name is unique, or (b) not checking to see if it's unique, which it does by default. If you use unique server names, you don't need this extra stuff.
Disclaimer: I work for Sybase in SQL Anywhere engineering.