Can't connect via Enterprise Manager

I had a similar problem that was due to the server not
using the proper TCP/IP port. I am guessing that one of
your servers is using a different port, (or none at all),
so it can't be seen by clients looking for the default
port number 1433, at least that was the problem in my case.
Check your Windows registry settings for the following
entries, (this is the key for a default instance, but
there are similar key paths for multiple instances):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ MSSQLServ
er\SuperSocketNetLib\Tcp\TcpPort
This value is the port that SQL Server will listen on. In
some cases it does not get set up correctly on the
install. The default is a decimal value of "1433" (if it
was blank then the server was only using shared memory
protocol)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ Client\Su
perSocketNetLib\Tcp\DefaultPort
This value is the port that clients use to communicate
with the server. It normally will also be "1433" (decimal).
If you do change these values you should shut down the
server service first and check the registry again after
the server is running again... I had a heck of a time
getting my server to use port 1433, as it kept switching
to port 2433 after the server started up. (Not sure if
it's necessary, but I also put a "" in the TcpDynamicPorts
variable) to make sure dynamic port assignments is off.
Alternatively, if you do have different port settings and
need to keep them as they are, you can create alias
entries on your clients that will associate the proper
protocols and ports for each server.
HTH,
TK
>--Original Message--
>Hi All,
>We have a MSDE on a W2K server installed. It is running
fine and the
>application can access it without a problem. We have
another server on that
>same subnet that has an SQL 2000 server installed. When
trying to connect to
>the MSDE via the Enterprise Manager, only the local SQL
shows up and we
>cannot connect to the MSDE instance.
>When we go to the ODBC on the MSDE box we see both SQL -
the local and the
>remote one. On the ODBC on the other server we only see
the local one.
>Does anybody have an idea what is going on?
>Thanks,
>Claus
>
>.
>
Thanks for the reply. I finally was able to connect. I still don't have any
idea what the reason was. I rebooted both servers and it worked without
making any changes. No entries in the event logs.
MS never stops surprising me.
thanks again to all of you for your good advise,
Claus
"TK" <anonymous@.discussions.microsoft.com> wrote in message
news:3c9f01c4a58c$61560b90$a301280a@.phx.gbl...[vbcol=seagreen]
> I had a similar problem that was due to the server not
> using the proper TCP/IP port. I am guessing that one of
> your servers is using a different port, (or none at all),
> so it can't be seen by clients looking for the default
> port number 1433, at least that was the problem in my case.
> Check your Windows registry settings for the following
> entries, (this is the key for a default instance, but
> there are similar key paths for multiple instances):
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ MSSQLServ
> er\SuperSocketNetLib\Tcp\TcpPort
> This value is the port that SQL Server will listen on. In
> some cases it does not get set up correctly on the
> install. The default is a decimal value of "1433" (if it
> was blank then the server was only using shared memory
> protocol)
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ Client\Su
> perSocketNetLib\Tcp\DefaultPort
> This value is the port that clients use to communicate
> with the server. It normally will also be "1433" (decimal).
> If you do change these values you should shut down the
> server service first and check the registry again after
> the server is running again... I had a heck of a time
> getting my server to use port 1433, as it kept switching
> to port 2433 after the server started up. (Not sure if
> it's necessary, but I also put a "" in the TcpDynamicPorts
> variable) to make sure dynamic port assignments is off.
> Alternatively, if you do have different port settings and
> need to keep them as they are, you can create alias
> entries on your clients that will associate the proper
> protocols and ports for each server.
> HTH,
> TK
> fine and the
> another server on that
> trying to connect to
> shows up and we
> the local and the
> the local one.