Showing posts with label similar. Show all posts
Showing posts with label similar. Show all posts

Friday, February 24, 2012

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.

Sunday, February 12, 2012

Can't connect to Database Engine from Management Studio

I have found several posts on the internet on similar issues, but none
with this specific problem.
I am unable to connect to a Database Engine from SQL Server 2005
Management Studio when connecting from a WAN connection, but I can
connect remotely when connected to the same LAN as the server that
hosts this SQL Server database. Also, I do not have any problems
connecting to the Analysis Services on the same database [and same
server] from the WAN connection.
On the desktop computer there is no Microsoft firewall and on the
server the Microsoft firewall is also disabled.
I have changed the options on the Surface Area Connection to only
remote with TCP/IP and remote with TCP/IP and Named Pipes - this did
not make a difference.
The SQL Server Browser is running.
Obviously remote connections work, because I can connect to the
database engine when I am remote on the same LAN. Also I can connect
to Analysis Services when I am remote on the WAN.
The specific error message is:
Cannot connect to <Server>\<Instance Name>
Additional information:
An error has occured while establishing a connection to the server.
When connecting to SQL Server 2005, this failure may be caused by the
fact that under default settings SQL Server does not allow remote
connections. (provider: SQL Network Interfaces, error: 26 - Error
Locating Server/Instance Specified) ( Microsoft SQL Server)
Blake wrote:
> I have found several posts on the internet on similar issues, but none
> with this specific problem.
> I am unable to connect to a Database Engine from SQL Server 2005
> Management Studio when connecting from a WAN connection, but I can
> connect remotely when connected to the same LAN as the server that
> hosts this SQL Server database. Also, I do not have any problems
> connecting to the Analysis Services on the same database [and same
> server] from the WAN connection.
> On the desktop computer there is no Microsoft firewall and on the
> server the Microsoft firewall is also disabled.
> I have changed the options on the Surface Area Connection to only
> remote with TCP/IP and remote with TCP/IP and Named Pipes - this did
> not make a difference.
> The SQL Server Browser is running.
> Obviously remote connections work, because I can connect to the
> database engine when I am remote on the same LAN. Also I can connect
> to Analysis Services when I am remote on the WAN.
> The specific error message is:
> Cannot connect to <Server>\<Instance Name>
> Additional information:
> An error has occured while establishing a connection to the server.
> When connecting to SQL Server 2005, this failure may be caused by the
> fact that under default settings SQL Server does not allow remote
> connections. (provider: SQL Network Interfaces, error: 26 - Error
> Locating Server/Instance Specified) ( Microsoft SQL Server)
>
When connecting over the WAN, are you able to PING the server? Have you
tried connecting by specifying the IP address instead of the hostname?
This sounds like a network issue, possible name resolution.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Tracy McKibben wrote:
> Blake wrote:
> When connecting over the WAN, are you able to PING the server? Have you
> tried connecting by specifying the IP address instead of the hostname?
> This sounds like a network issue, possible name resolution.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
Thanks for your comments. Yes I can ping the server, I can connect
with a remote control software package to the same server and can use
Management Studio to connect to SQL Server Analysis Services. I don't
think this is a network [or firewall] issue because I can connect to
the server from every other method, unless there is something specific
network method that is used for Database Engine connections that are
blocked. I have presumed that when I set the connection to be TCP/IP
only it used a TCP connection and when the connection is set to TCP/IP
and Named Pipes it used Named Pipes. I see in the Registered Server
window you can specify the type of connection. This is very
confusing...
|||MS SQL-Server talks on ports when using TCP/IP. So, you need to make sure the
port itself is open. I beleive it uses 1433/tcp for accessing the server
(might be 1434, I can't remember).
Can you telnet to that port? Does Management Studio use a different port?
"Blake" wrote:

> Tracy McKibben wrote:
> Thanks for your comments. Yes I can ping the server, I can connect
> with a remote control software package to the same server and can use
> Management Studio to connect to SQL Server Analysis Services. I don't
> think this is a network [or firewall] issue because I can connect to
> the server from every other method, unless there is something specific
> network method that is used for Database Engine connections that are
> blocked. I have presumed that when I set the connection to be TCP/IP
> only it used a TCP connection and when the connection is set to TCP/IP
> and Named Pipes it used Named Pipes. I see in the Registered Server
> window you can specify the type of connection. This is very
> confusing...
>
|||On Jan 4, 2:48 pm, JayKon <Jay...@.discussions.microsoft.com> wrote:[vbcol=seagreen]
> MS SQL-Server talks on ports when using TCP/IP. So, you need to make sure the
> port itself is open. I beleive it uses 1433/tcp for accessing the server
> (might be 1434, I can't remember).
> Can you telnet to that port? Does Management Studio use a different port?
> "Blake" wrote:
>
>
>
Based on a comment from my customer on this database, I created a SQL
Server installation without using a named instance. Using the default
instance name - I am able to connect via Management Studio from a WAN
connection. I have since deleted the original NAMED instance,
recreated on the same computer as a DEFAULT instance and connecting
with Management Studio is a breeze.
Does anyone know how to report this to Microsoft, this is a but that
should be fixed?
|||Blake wrote:
> Based on a comment from my customer on this database, I created a SQL
> Server installation without using a named instance. Using the default
> instance name - I am able to connect via Management Studio from a WAN
> connection. I have since deleted the original NAMED instance,
> recreated on the same computer as a DEFAULT instance and connecting
> with Management Studio is a breeze.
> Does anyone know how to report this to Microsoft, this is a but that
> should be fixed?
>
If I understand this correctly, you had the following:
Machine named SERVER
SQL instance named SERVER\MYINSTANCE
When you were attempting to connect, what were you specifying as a
server name? To connect to SERVER\MYINSTANCE, you wouldn't specify
SERVER\MYINSTANCE as the server name, unless you have defined that as an
alias in the client configuration tool. You would specify a server name
of "SERVER,1433", replacing 1433 with the port number that the instance
is listening on. The name "SERVER\MYINSTANCE" isn't a valid hostname,
and won't be resolvable by your client tools.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||I had same problem...at leat I think so..
Have you tryed to add server name and IP to your host file?
Because that resolved my problem.
Information about host file
http://accs-net.com/hosts/how_to_use_hosts.html
Juha Sinkkonen
Agenteq Consulting Oy
sinkkonen22(at)hotmail.com
"Blake" wrote:

>
> On Jan 4, 2:48 pm, JayKon <Jay...@.discussions.microsoft.com> wrote:
> Based on a comment from my customer on this database, I created a SQL
> Server installation without using a named instance. Using the default
> instance name - I am able to connect via Management Studio from a WAN
> connection. I have since deleted the original NAMED instance,
> recreated on the same computer as a DEFAULT instance and connecting
> with Management Studio is a breeze.
> Does anyone know how to report this to Microsoft, this is a but that
> should be fixed?
>

Can't connect to Database Engine from Management Studio

I have found several posts on the internet on similar issues, but none
with this specific problem.
I am unable to connect to a Database Engine from SQL Server 2005
Management Studio when connecting from a WAN connection, but I can
connect remotely when connected to the same LAN as the server that
hosts this SQL Server database. Also, I do not have any problems
connecting to the Analysis Services on the same database [and same
server] from the WAN connection.
On the desktop computer there is no Microsoft firewall and on the
server the Microsoft firewall is also disabled.
I have changed the options on the Surface Area Connection to only
remote with TCP/IP and remote with TCP/IP and Named Pipes - this did
not make a difference.
The SQL Server Browser is running.
Obviously remote connections work, because I can connect to the
database engine when I am remote on the same LAN. Also I can connect
to Analysis Services when I am remote on the WAN.
The specific error message is:
Cannot connect to <Server>\<Instance Name>
Additional information:
An error has occured while establishing a connection to the server.
When connecting to SQL Server 2005, this failure may be caused by the
fact that under default settings SQL Server does not allow remote
connections. (provider: SQL Network Interfaces, error: 26 - Error
Locating Server/Instance Specified) ( Microsoft SQL Server)Blake wrote:
> I have found several posts on the internet on similar issues, but none
> with this specific problem.
> I am unable to connect to a Database Engine from SQL Server 2005
> Management Studio when connecting from a WAN connection, but I can
> connect remotely when connected to the same LAN as the server that
> hosts this SQL Server database. Also, I do not have any problems
> connecting to the Analysis Services on the same database [and same
> server] from the WAN connection.
> On the desktop computer there is no Microsoft firewall and on the
> server the Microsoft firewall is also disabled.
> I have changed the options on the Surface Area Connection to only
> remote with TCP/IP and remote with TCP/IP and Named Pipes - this did
> not make a difference.
> The SQL Server Browser is running.
> Obviously remote connections work, because I can connect to the
> database engine when I am remote on the same LAN. Also I can connect
> to Analysis Services when I am remote on the WAN.
> The specific error message is:
> Cannot connect to <Server>\<Instance Name>
> Additional information:
> An error has occured while establishing a connection to the server.
> When connecting to SQL Server 2005, this failure may be caused by the
> fact that under default settings SQL Server does not allow remote
> connections. (provider: SQL Network Interfaces, error: 26 - Error
> Locating Server/Instance Specified) ( Microsoft SQL Server)
>
When connecting over the WAN, are you able to PING the server? Have you
tried connecting by specifying the IP address instead of the hostname?
This sounds like a network issue, possible name resolution.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy McKibben wrote:
> Blake wrote:
> When connecting over the WAN, are you able to PING the server? Have you
> tried connecting by specifying the IP address instead of the hostname?
> This sounds like a network issue, possible name resolution.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
Thanks for your comments. Yes I can ping the server, I can connect
with a remote control software package to the same server and can use
Management Studio to connect to SQL Server Analysis Services. I don't
think this is a network [or firewall] issue because I can connect to
the server from every other method, unless there is something specific
network method that is used for Database Engine connections that are
blocked. I have presumed that when I set the connection to be TCP/IP
only it used a TCP connection and when the connection is set to TCP/IP
and Named Pipes it used Named Pipes. I see in the Registered Server
window you can specify the type of connection. This is very
confusing...|||MS SQL-Server talks on ports when using TCP/IP. So, you need to make sure th
e
port itself is open. I beleive it uses 1433/tcp for accessing the server
(might be 1434, I can't remember).
Can you telnet to that port? Does Management Studio use a different port?
"Blake" wrote:

> Tracy McKibben wrote:
> Thanks for your comments. Yes I can ping the server, I can connect
> with a remote control software package to the same server and can use
> Management Studio to connect to SQL Server Analysis Services. I don't
> think this is a network [or firewall] issue because I can connect to
> the server from every other method, unless there is something specific
> network method that is used for Database Engine connections that are
> blocked. I have presumed that when I set the connection to be TCP/IP
> only it used a TCP connection and when the connection is set to TCP/IP
> and Named Pipes it used Named Pipes. I see in the Registered Server
> window you can specify the type of connection. This is very
> confusing...
>|||On Jan 4, 2:48 pm, JayKon <Jay...@.discussions.microsoft.com> wrote:[vbcol=seagreen]
> MS SQL-Server talks on ports when using TCP/IP. So, you need to make sure
the
> port itself is open. I beleive it uses 1433/tcp for accessing the server
> (might be 1434, I can't remember).
> Can you telnet to that port? Does Management Studio use a different port?
> "Blake" wrote:
>
>
>
>
>
>
>
Based on a comment from my customer on this database, I created a SQL
Server installation without using a named instance. Using the default
instance name - I am able to connect via Management Studio from a WAN
connection. I have since deleted the original NAMED instance,
recreated on the same computer as a DEFAULT instance and connecting
with Management Studio is a breeze.
Does anyone know how to report this to Microsoft, this is a but that
should be fixed?|||Blake wrote:
> Based on a comment from my customer on this database, I created a SQL
> Server installation without using a named instance. Using the default
> instance name - I am able to connect via Management Studio from a WAN
> connection. I have since deleted the original NAMED instance,
> recreated on the same computer as a DEFAULT instance and connecting
> with Management Studio is a breeze.
> Does anyone know how to report this to Microsoft, this is a but that
> should be fixed?
>
If I understand this correctly, you had the following:
Machine named SERVER
SQL instance named SERVER\MYINSTANCE
When you were attempting to connect, what were you specifying as a
server name? To connect to SERVER\MYINSTANCE, you wouldn't specify
SERVER\MYINSTANCE as the server name, unless you have defined that as an
alias in the client configuration tool. You would specify a server name
of "SERVER,1433", replacing 1433 with the port number that the instance
is listening on. The name "SERVER\MYINSTANCE" isn't a valid hostname,
and won't be resolvable by your client tools.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I had same problem...at leat I think so..
Have you tryed to add server name and IP to your host file?
Because that resolved my problem.
Information about host file
http://accs-net.com/hosts/how_to_use_hosts.html
Juha Sinkkonen
Agenteq Consulting Oy
sinkkonen22(at)hotmail.com
"Blake" wrote:

>
> On Jan 4, 2:48 pm, JayKon <Jay...@.discussions.microsoft.com> wrote:
> Based on a comment from my customer on this database, I created a SQL
> Server installation without using a named instance. Using the default
> instance name - I am able to connect via Management Studio from a WAN
> connection. I have since deleted the original NAMED instance,
> recreated on the same computer as a DEFAULT instance and connecting
> with Management Studio is a breeze.
> Does anyone know how to report this to Microsoft, this is a but that
> should be fixed?
>

Can't connect to Database Engine from Management Studio

I have found several posts on the internet on similar issues, but none
with this specific problem.
I am unable to connect to a Database Engine from SQL Server 2005
Management Studio when connecting from a WAN connection, but I can
connect remotely when connected to the same LAN as the server that
hosts this SQL Server database. Also, I do not have any problems
connecting to the Analysis Services on the same database [and same
server] from the WAN connection.
On the desktop computer there is no Microsoft firewall and on the
server the Microsoft firewall is also disabled.
I have changed the options on the Surface Area Connection to only
remote with TCP/IP and remote with TCP/IP and Named Pipes - this did
not make a difference.
The SQL Server Browser is running.
Obviously remote connections work, because I can connect to the
database engine when I am remote on the same LAN. Also I can connect
to Analysis Services when I am remote on the WAN.
The specific error message is:
Cannot connect to <Server>\<Instance Name>
Additional information:
An error has occured while establishing a connection to the server.
When connecting to SQL Server 2005, this failure may be caused by the
fact that under default settings SQL Server does not allow remote
connections. (provider: SQL Network Interfaces, error: 26 - Error
Locating Server/Instance Specified) ( Microsoft SQL Server)Blake wrote:
> I have found several posts on the internet on similar issues, but none
> with this specific problem.
> I am unable to connect to a Database Engine from SQL Server 2005
> Management Studio when connecting from a WAN connection, but I can
> connect remotely when connected to the same LAN as the server that
> hosts this SQL Server database. Also, I do not have any problems
> connecting to the Analysis Services on the same database [and same
> server] from the WAN connection.
> On the desktop computer there is no Microsoft firewall and on the
> server the Microsoft firewall is also disabled.
> I have changed the options on the Surface Area Connection to only
> remote with TCP/IP and remote with TCP/IP and Named Pipes - this did
> not make a difference.
> The SQL Server Browser is running.
> Obviously remote connections work, because I can connect to the
> database engine when I am remote on the same LAN. Also I can connect
> to Analysis Services when I am remote on the WAN.
> The specific error message is:
> Cannot connect to <Server>\<Instance Name>
> Additional information:
> An error has occured while establishing a connection to the server.
> When connecting to SQL Server 2005, this failure may be caused by the
> fact that under default settings SQL Server does not allow remote
> connections. (provider: SQL Network Interfaces, error: 26 - Error
> Locating Server/Instance Specified) ( Microsoft SQL Server)
>
When connecting over the WAN, are you able to PING the server? Have you
tried connecting by specifying the IP address instead of the hostname?
This sounds like a network issue, possible name resolution.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy McKibben wrote:
> Blake wrote:
> > I have found several posts on the internet on similar issues, but none
> > with this specific problem.
> >
> > I am unable to connect to a Database Engine from SQL Server 2005
> > Management Studio when connecting from a WAN connection, but I can
> > connect remotely when connected to the same LAN as the server that
> > hosts this SQL Server database. Also, I do not have any problems
> > connecting to the Analysis Services on the same database [and same
> > server] from the WAN connection.
> > On the desktop computer there is no Microsoft firewall and on the
> > server the Microsoft firewall is also disabled.
> > I have changed the options on the Surface Area Connection to only
> > remote with TCP/IP and remote with TCP/IP and Named Pipes - this did
> > not make a difference.
> > The SQL Server Browser is running.
> >
> > Obviously remote connections work, because I can connect to the
> > database engine when I am remote on the same LAN. Also I can connect
> > to Analysis Services when I am remote on the WAN.
> >
> > The specific error message is:
> > Cannot connect to <Server>\<Instance Name>
> > Additional information:
> > An error has occured while establishing a connection to the server.
> > When connecting to SQL Server 2005, this failure may be caused by the
> > fact that under default settings SQL Server does not allow remote
> > connections. (provider: SQL Network Interfaces, error: 26 - Error
> > Locating Server/Instance Specified) ( Microsoft SQL Server)
> >
> When connecting over the WAN, are you able to PING the server? Have you
> tried connecting by specifying the IP address instead of the hostname?
> This sounds like a network issue, possible name resolution.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
Thanks for your comments. Yes I can ping the server, I can connect
with a remote control software package to the same server and can use
Management Studio to connect to SQL Server Analysis Services. I don't
think this is a network [or firewall] issue because I can connect to
the server from every other method, unless there is something specific
network method that is used for Database Engine connections that are
blocked. I have presumed that when I set the connection to be TCP/IP
only it used a TCP connection and when the connection is set to TCP/IP
and Named Pipes it used Named Pipes. I see in the Registered Server
window you can specify the type of connection. This is very
confusing...|||On Jan 4, 2:48 pm, JayKon <Jay...@.discussions.microsoft.com> wrote:
> MS SQL-Server talks on ports when using TCP/IP. So, you need to make sure the
> port itself is open. I beleive it uses 1433/tcp for accessing the server
> (might be 1434, I can't remember).
> Can you telnet to that port? Does Management Studio use a different port?
> "Blake" wrote:
> > Tracy McKibben wrote:
> > > Blake wrote:
> > > > I have found several posts on the internet on similar issues, but none
> > > > with this specific problem.
> > > > I am unable to connect to a Database Engine from SQL Server 2005
> > > > Management Studio when connecting from a WAN connection, but I can
> > > > connect remotely when connected to the same LAN as the server that
> > > > hosts this SQL Server database. Also, I do not have any problems
> > > > connecting to the Analysis Services on the same database [and same
> > > > server] from the WAN connection.
> > > > On the desktop computer there is no Microsoft firewall and on the
> > > > server the Microsoft firewall is also disabled.
> > > > I have changed the options on the Surface Area Connection to only
> > > > remote with TCP/IP and remote with TCP/IP and Named Pipes - this did
> > > > not make a difference.
> > > > The SQL Server Browser is running.
> > > > Obviously remote connections work, because I can connect to the
> > > > database engine when I am remote on the same LAN. Also I can connect
> > > > to Analysis Services when I am remote on the WAN.
> > > > The specific error message is:
> > > > Cannot connect to <Server>\<Instance Name>
> > > > Additional information:
> > > > An error has occured while establishing a connection to the server.
> > > > When connecting to SQL Server 2005, this failure may be caused by the
> > > > fact that under default settings SQL Server does not allow remote
> > > > connections. (provider: SQL Network Interfaces, error: 26 - Error
> > > > Locating Server/Instance Specified) ( Microsoft SQL Server)
> > > When connecting over the WAN, are you able to PING the server? Have you
> > > tried connecting by specifying the IP address instead of the hostname?
> > > This sounds like a network issue, possible name resolution.
> > > --
> > > Tracy McKibben
> > > MCDBA
> > >http://www.realsqlguy.com
> > Thanks for your comments. Yes I can ping the server, I can connect
> > with a remote control software package to the same server and can use
> > Management Studio to connect to SQL Server Analysis Services. I don't
> > think this is a network [or firewall] issue because I can connect to
> > the server from every other method, unless there is something specific
> > network method that is used for Database Engine connections that are
> > blocked. I have presumed that when I set the connection to be TCP/IP
> > only it used a TCP connection and when the connection is set to TCP/IP
> > and Named Pipes it used Named Pipes. I see in the Registered Server
> > window you can specify the type of connection. This is very
> > confusing...
Based on a comment from my customer on this database, I created a SQL
Server installation without using a named instance. Using the default
instance name - I am able to connect via Management Studio from a WAN
connection. I have since deleted the original NAMED instance,
recreated on the same computer as a DEFAULT instance and connecting
with Management Studio is a breeze.
Does anyone know how to report this to Microsoft, this is a but that
should be fixed?|||Blake wrote:
> Based on a comment from my customer on this database, I created a SQL
> Server installation without using a named instance. Using the default
> instance name - I am able to connect via Management Studio from a WAN
> connection. I have since deleted the original NAMED instance,
> recreated on the same computer as a DEFAULT instance and connecting
> with Management Studio is a breeze.
> Does anyone know how to report this to Microsoft, this is a but that
> should be fixed?
>
If I understand this correctly, you had the following:
Machine named SERVER
SQL instance named SERVER\MYINSTANCE
When you were attempting to connect, what were you specifying as a
server name? To connect to SERVER\MYINSTANCE, you wouldn't specify
SERVER\MYINSTANCE as the server name, unless you have defined that as an
alias in the client configuration tool. You would specify a server name
of "SERVER,1433", replacing 1433 with the port number that the instance
is listening on. The name "SERVER\MYINSTANCE" isn't a valid hostname,
and won't be resolvable by your client tools.
--
Tracy McKibben
MCDBA
http://www.realsqlguy.com