Connecting to Virtual Instance | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Connecting to Virtual Instance

We recently installed an Active/Active SQL cluster and have no problems connecting through Enterprise Manager or Query Analyzer to either instance. For explanation purposes lets call them DB1OLTP and DB2OLTP with DB1OLTP being the primary instance for the installations. Today when trying to install a program that will access the second instance (DB2OLTP/DB2OLTP) through ODBC, we are unable to connect. We have found that we can connect to the primary instance (DB1OLTP) with no problems. Additionally, we are able to access DB2OLTPDB2OLTP through ODBC when sitting locally on DB1OLTP, if we enter into the server name "DB2OLTP/DB2OLTP", (server name/instance name)…we cannot however connect to the instance if we enter the IP address. Sitting on DB2OLTP machine, we have the same problem. We can make an odbc connection if we use the machine/instance name, but not using the IP. Is there something that I missed on the setup or a setting that isn’t made correctly? Any help would be greatly appreciated.
Check the network for any WINS or naming resolution issue. Satya SKJ
This posting is provided “AS IS” with no rights for the sake of knowledge sharing.
Sorry I guess I was a little confusing in my post. Basically, we are only able to connect to the second instance (DB2) when sitting on one of the 2 machines in the cluster, (and then only using the server/instance name, not the IP address or fully qualified name).
From our web server, we are only able to access the first (default) virtual instance…but need to be able to access the second virtual instance as well. We have tried doing a ping from the web server and the name resolves to the correct IP (for the virtual instance) so I’m not certain WINS is an issue.
Discovered the answer….the second instance of SQL Server is listening on a different port number than the default 1433.
The reason I was able to connect to either instance while sitting on one of the db cluster servers is because the talk between them using shared memory.
To correct, when setting up the odbc, on the web server, the port had to be specified in the odbc connection.