Connecting to SQL Server 2000 on another subnet

Hi Folks,

I'm very new to SQL Server. I have a home network. My primary connection
to the internet is using "Gateway 1" a linksys router, of which, my server
is a LAN node on that router. I have another LAN node connecting to the WAN
node of the "Gateway 2" a wireless USR router to use with my laptop. Using
the wireless laptop, I am on a different subnet than the Server. I'd like
to make a connection to the server through Visual Studio.net but I can't
seem to do it. I'm using TCP/IP with a port different than the default port
(let's call it port 2110, even though it's not). I do have port forwarding
on Gateway1 and I've tried everything from just the server internal IP
address, the external IP address, IP address with port designation, URL with
port designation, nothing seems to work. Any ideas?

Thanks!
RickIt sounds more like you need to configure Gateway2 (not Gateway1)
correctly, if you want to connect to the server from your laptop? The
KB article below might help, but if not, you may get better help in a
networking group of some sort. If you haven't already, you probably
need to use ping, tracert, nslookup etc to make sure you can at least
resolve the server's name and 'see' it on the LAN.

http://support.microsoft.com/kb/287932

Simonsqlsql

Connecting to SQL Server 2000 Named Instances

We are having all kinds of issues with named instances for SQL 2000.

I am trying to connect to a SQL Server 2000 named instance on a different subnet and get an error. I cannot connect with ODBC or our web app.

I am using the port number for the alias that I created in the SQL Client Utility. We can connect to default instances without a problem, but not the named instances.

The SQL Server is 2000 build 2040 (Service pack 4 with a hot fix.) The server is listening on port 1223. In the ODBC connection I click on the Network Config and create an alias with the named instance such as SQLVSN\SQLNI and specify port 1223. I have also tried adding the port to the connection string in the ASP include file (SQLVSN\SQLNI,1223). If I do the same thing with a default instance on the network, both the app and ODBC work fine. It is only when I use a named instance.

Very frustrated. Thanks for any help you can provideIt shouldn't be much different. Here is a connection string in ASP which I use for our internal webpage.


Set objConn = Server.CreateObject("ADODB.Connection")
Set objrs = Server.CreateObject("ADODB.Recordset")

objConn.Open "Driver={SQL Server};" & _
"Server=SERVERNAME\INSTANCENAME;" & _
"Database=DATABASENAME;" & _
"Network=NETWORKNAME;" & _
"Uid=USERNAME;" & _
"Pwd=PASSWORD"

str = "SELECT bla bla FROM bla bla WHERE bla bla;"
set objrs=objConn.execute(str)

I know all about security and dynamic SQL queries; this is just a proof of concept|||That's what we have. The app works on one of the servers that are on the same subnet, but not the one on a different subnet.

The one that is on the other subnet can't connect when I try to create an ODBC connection as a test. This goes for all named instances in the company, for which we have quite a few because we have several SQL Server Cluster Groups setup. However, I can create an ODBC connection to a default instance with no problem what so ever.

I have to be overlooking something when it comes to named instances.

Connect to SQL from a different Subnet

Hi all,
I have my SQL 2000 server at 192.168.1.10. All of the
desktops with in that subnet can access the SQL server. I
just installed a new desktop with ip address: 192.168.3.2
Is there anything that i need to set up in order for this
desktop to be able to detect and connect to my SQL
Server. A ping from 192.168.3.2 to 192.168.1.10 receive
100% sucessful reply. I can even connect to the folders
on the SQL server but not to the database.
When i try to connect through a sql client it give
something like this: SQL server does not exist or access
is denied
Please help
ThanksYou need to retrieve the actual OS error to troubleshoot this problem.
Reply with the OS error returned while connecting using an ODBC test DSN.
Or test using ISQL.exe from a command prompt.
Example:
ISQL -Stcp:ServerNameHere -Usqluseridhere -Ppasswordhere -Q"select
@.@.version"
or
ISQL -Stcp:ServerNameHere -E -Q"select @.@.version"
Search the kb for the OS error returned.
Example:
10060 == Connection Timeout
10061 == Connection Refused. The server is not listening on TCP. This
could be caused if we fail to bind to the port.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.