SQL / ODBC connection accross T1 + IP

[datadan]

This may not be the right forum, if not please redirect.

I have a SQL server (centura) on an NT server:
IP 10.10.12.13 255.255.255.0 domain ab
When establishing ODBC links I can use either Named Pipes or TCP/IP without a problem. I can then use the client component of the software to log into the application.

However when I go to a different IP across a WAN
10.11.10.x 255.255.0.0 domain ab I can establish ODBC links using TCP/IP only (Named pipes doesn't work). I can also ping and log into the domain. However I cannot log into the application. The reject error message is:
Connection Failed
SQLState: 01000
SQL Server Error: 53
[Microsoft][OBDC SQL Server Driver][DBNETLIB]Connection Open (Connect()).
Connection Failed:
SQLState: 08001
SQL Server Error 17
[Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist of access denied.


**********
I am using the same hardware (laptop). The variable is distance (Long Haul T1), and IP address changes. Why does this affect the connection. Can someone help or point me in the right direction?

Thanks,

 

[thedaver]

I can think of a few things...

1) Named Pipes is not routable across a WAN
2) Firewall blocking the Named Pipes service egress port
3) Firewall blocking the Named Pipes service ingress port
4) You may not have SQL access rights to login from that IP (not sure how MS SQL does this, my MySQL allows/denys access by IP as well as ID).



Surfinbox.com Business Internet Services - National Dialup, DSL, T-1 and more.

http://www.surfinbox.com/business/

 

[datadan]

The daver....

Good suggestions.
1) Point to Point T1.
2) No firewalls involved.
3) I am looking into the SQL access rights...
4) Could there be a timeout issue. If the handshake doesn't occur in x amount of seconds it "times outs" giving a failure to logon message?

 

[thedaver]

A proper T-1 should be more than sufficient to not have timeouts as a problem. I still say that the routers between you and the db might be WAN routing issue with whatever protocol that Named Pipes wants to use... I recall something about NetBeui not being routable, that would be a big problem. You might be able to encapsulate NetBeui in IP....

Keep in touch.

Surfinbox.com Business Internet Services - National Dialup, DSL, T-1 and more.

http://www.surfinbox.com/business/

 

[jsentelle]

Hi datadan,


I've seen this problem before. I fixed my problem by specifying the SQL server port for the DSN on the client. Either run netstat -a, or look in the SQL server registry to see what port the server listens on. I have never been able to dynamically determine the port across a wan.

Hope this helps....

 

[datadan]

Jsentelle,

How do I specify the SQL server port for the DSN on the client? (I've got w95 / w98 machines)

The server listens on:
1027
1026
1029
1030
1028
1035
1033
1034
135
137
138



However I am unable to determine which port the MSSQL connections use.

Thanks,

 

[bcastner]

Click on start-> Run -> type in Cliconfg.exe and make sure Named pipes and TCP/IP are enabled by default.

Try to make an alias using TCP or Named pipes using the SQL server name and a test connection.

If it still fails, try creating an alias with the IP address of the SQL server.

 

[jsentelle]

datadan,

You could also make a connection to the SQL server when you are on the local network, then view the results of netstat. Also, if you are comfortable with the registry ,look at HKLM\Software\Microsoft\instance\MSSQLserver\SuperSocketNetLib\TcpPort to see which port the server in question uses.

Let us know how this turns out........

 

[datadan]

Update:

I have elimiated issues of different NT domains, IP subnet, and IP subness class, but setting up multple different domains, subnets, and subnet classes within the same four walls. I can login just fine from within the 4 walls.

Over the T1 same problem.
I had someone try Cliconfg.exe no success (although I will be trying this myself next week).

Registry Entry for HKLM\Software\Microsoft\instance does not exist on NT server. (MSSQL 6.5 if that makes a diff).

I did a search while in regedit for SuperSocketNetLib but didn't find any enties.

I also tried increasing the logout time in the SQL manager, but this has no effect.

Any other thoughts on this stumper....
Thanks,

 

[jsentelle]

Did you try to make a local connection and then look for it in netstat -a? Have you looked in the client manager to see port settings? I'm about 90% sure you will need to manually set the port at the client when you cross the wan. Did you find the port seting box in the odbc manager?