Connecting to a SQL Server on a different workgroup using port 1433 4

[upsilona]

Hi,

I have 2 workgroups, on one is the client and on the other is a SQL Server installation. The server with SQL on it is locked down so that it can only be accessed through TCP port 1433. The problem is that they can't talk to each other. Do I need a trust relationship between the workgroups? Any help at all will be much appreciated, as I do not have a clue.

 

[tlbroadbent]

Which version of SQL Server are you running? If SQL 2000 then you need to open Port 1434 as well. Terry L. Broadbent
faq183-874 contains some tips and ideas for posting questions in these forums. Please review it and comment if you have time.
NOTE: Reference to the FAQ is part of my signature and is not directed at any individual.

 

[upsilona]

It is running SQL 7 with service pack 3. Netbios is disabled. They communicate with a DSN over ip

 

[tlbroadbent]

Are you connecting by name or by IP address? If not, can the client resolve the server DNS name either through a DNS server or a hosts file?

I assume that both client and server are setup to communicate using TCP/IP sockets net library. If not, they should be.

Check the following article for more information about connecting through a firewall.

http://support.microsoft.com/support/kb/articles/Q287/9/32.ASP

Terry L. Broadbent
faq183-874 contains some tips and ideas for posting questions in these forums. Please review it and comment if you have time.
NOTE: Reference to the FAQ is part of my signature and is not directed at any individual.

 

[Bernadette]

Hi There

Check what version of the SQL Server ODBC diver you are using. If you are using SQL Server Driver 2000.080.0194 which was released with SQL Server 2000 and with MDAC 2.6., there is a bug with the driver and it ignores the authentication settings and trys to log on using Integrated Security. So it will refuse to connect using TCPIP.

Check out Q279526 on MS Knowledge Base for more information.

I had a similiar problem earlier and this was the cause.

Hope this helps Bernadette

 

[tlbroadbent]

Bernadette,

The bug caused the SQL Server ODBC driver to ignore saved authentication settings. The defective driver would always attempt to login with NT authentication even if the connection was saved with SQL authentication. If the NT login was valid, a a connection would occur and that might cause problems because of permissions, incorrect databases, etc.

If the NT login was not vaid in SQL Server, the login would fail and display a login dialog. At that time, the user could change authentication method to SQL Server authentication and enter the login/password and connect. Terry L. Broadbent
Life would be easier if I had the source code. -Anonymous

 

[aalmeida]

Have you verifyed that the client is using the same TCP port 1433, note that this is not the default port, you may need to go to the "Client Network Utility" and make sure that the client is using the same port of the server. AL Almeida
NT/DB Admin
"May all those that come behind us, find us faithfull"

 

[prashantdhas]

hi everybody,
I know there might be the problem with the tcp/ip and netbui. The simple alternative is that you use the Multiprotocol with the server name and test this is odbc . U will surely get through.
let me know if it was successful!!
Thanks
Prashu

 

[upsilona]

Hi all,

Thanks for all you help, Its finally working now. The servers had 2 different version of the ODBC driver.

 

[Bernadette]

Hi Terry

Thank you for the information!! The problem that I had was that the powers that be in my company wouldnt let me connect the servers any other way only through IP on port 1433. Everything else was locked down by the NT Admin.

Do you know of any good articles about TCP/IP ?

Thanks again for all your help

Bernadette Bernadette

 

[aalmeida]

The best place to get Some TCP/IP info is at the forum 581 witch subject is TCP/IP, you'll find it very helpfull AL Almeida
NT/DB Admin
"May all those that come behind us, find us faithfull"