Can't display the report page from the Internet

Hi,

I am using SQL 2000 SP4 and Report Server SP2 on W2k3 SP1 Server.

I am having trouble displaying the report pages if I am connected from the Internet.

I have no problem if I am connected in the office (Intranet).

The frame that is not show is underneath the New Subscription bar in my report page. I can see everything above (header pages etc) and Home page etc.

I think for some reasons the request frame URL page is still https://myserver/Repor... instead https://myserver.mycompany.com/Report...

Thank's for any help

gogu

PS: Also I am able to deploy only from the Intranet with Target Server URL https://myserver/ReportServer
If I setup VS.NET deploy Target Server URL https://myserver.mycompany.com/ReportServer it comes up with "A connection could not be made ..."
If I open the Browser from the Intranet I can see the reports pages even if with https://myserver.mycompany.com/Reports...
but it ask me for Username / Password.
How can I tell VS.NET when deploy to use username/password?

I think I figure out this (PostID=499647);

I modified RSWebApplication.config see PostID=499647 above and reinstall SSL certificate with <FQDN>

What stupid think is that only the body of report page follows the key <ReportServerUrl> other frame pages are relative to browser URL?

Can't Disable, getting Server Cannot obtain LOCK

Internet merge replication. Need to detach to move to a new box. Deleted
all the publication, now when I try to disable it as the publisher. I tried
to run sp_removedbreplication 'db_name' and get the same message.
Any thoughts?
Thanks
After lots more reading and searching, I found low memory could cause this.
I added another 512 to the box, and it worked.
"SteveInBeloit" wrote:

> Internet merge replication. Need to detach to move to a new box. Deleted
> all the publication, now when I try to disable it as the publisher. I tried
> to run sp_removedbreplication 'db_name' and get the same message.
> Any thoughts?
> Thanks
|||I would have bounced the server and then tried this - this is abnormal.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"SteveInBeloit" <SteveInBeloit@.discussions.microsoft.com> wrote in message
news:17E5CBD0-5D2A-444A-97BD-4629B2AE3559@.microsoft.com...[vbcol=seagreen]
> After lots more reading and searching, I found low memory could cause
> this.
> I added another 512 to the box, and it worked.
>
> "SteveInBeloit" wrote:

Can't Connect to Multiple SQL Instances over the Internet with SQL Browser Service

I recently setup mutliple instances of SQL Server Express at my office. I have 1 default instance, and two named instances. I can connect to the named instance of the default port of 1433 with Microsoft SQL Management Studio Express, however the other instances on dynamic TCP ports can not be accessed by the instance name over the internet. I have to specify the dynamic TCP port in this form: xxx.uconn.edu/SQLTEST, Port number. My current thinking is that the SQL Browser service should tell Management Studio Express what dynamic port number each SQL instance is listening to. Any ideas?

hi,

CTJohn23 wrote:

I recently setup mutliple instances of SQL Server Express at my office. I have 1 default instance, and two named instances. I can connect to the named instance of the default port of 1433 with Microsoft SQL Management Studio Express,

TCP/IP 1433 is usually reserved for the default instance...

however the other instances on dynamic TCP ports can not be accessed by the instance name over the internet. I have to specify the dynamic TCP port in this form: xxx.uconn.edu/SQLTEST, Port number. My current thinking is that the SQL Browser service should tell Management Studio Express what dynamic port number each SQL instance is listening to. Any ideas?

the SQLBrowser can not "work" over the internet in that way... all enlistment for instance presence are available via an UDP broadcast call on the local area, when no firewall action is involved...

don't know if the "tool" still relies on SQLBrowseConnect ODBC function, like SQL Server 7.0 and 2000 ListAvailableServer used it, an ODBC function (SQLBrowseConnect()) provided by ODBC libraries installed by Mdac;
this is a mechanism working in broadcast calls, which result never are conclusive and consistent, becouse results are influenced of various servers's answer states, answer time, etc.

Until Mdac 2.5, SQLBrowseConnect function works based on a NetBIOS broadcast, on which SQL Servers respond (Default protocol for SQL Server 7.0), while in SQL Server 2000 the rules changed, because the default client protocol changed to TCP/IP and now a UDP broadcast is used, beside a NetBIOS broadcast, listening on port 1434:
which is using a UDP broadcast on port 1434, if instance do not listen or not respond on time they will not be part of the enumeration.

Some basic rules for 7.0 are:
- SQL Servers have to be running on Windows NT or Windows 2000 and have to listen on Named Pipes, that is why in 7.0 Windows 9x SQL Servers will never show up, because they do not listen on Named Pipes.
- The SQL Server has to be running in order to respond on the broadcast. There is a gray window of 15 minutes after shutdown, where a browse master in the domain may respond on the broadcast and answer.
- If you have routers in your network, that do not pass on NetBIOS broadcasts, this might limit your scope of the broadcast.
- Only servers within the same NT domain (or trust) will get enumerated.

In SQL Server 2000 using MDAC 2.6 this changes a little, because now the default protocol has been changed to be TCP/IP sockets and instead of a NetBIOS broadcast, they use a TCP UDP to detect the servers. The same logic still applies roughly.
- SQL Server that are running
- SQL Server that listening on TCP/IP
- Running on Windows NT or Windows 2000 or Windows 9x
- If you use routers and these are configured not to pass UDP broadcasts, only machines within the same subnet show up.

Upgrading to Service Pack 2 of SQL Server 2000 is required in order to have .ListAvailableServer method to work properly, becouse precding release of Sql-DMO Components of Sql Server 2000 present a bug in this area.

Courtesy of Mr. Gert E.R. Drapers
further Information at
http://sqldev.net/misc.htm

The Service Pack 3a introduced some new amenity in order to prevent MSDE 2000 to be hit by Internet worms like Slammer and Saphire virus and to increase security, so that Microsoft decided to default for disabling SuperSockets Network Protocols on new MSDE 2000 installation.
Instances of SQL Server 2000 SP3a or MSDE 2000 SP3a will stop listening on UDP port 1434 when they are configured to not listen on any network protocols. This will stop enlisting these servers.

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