I am having a problem connecting to a SQL Server named [non-default] instanc
e
using the Server "alias" name. Connecting, through Enterprise Manager with
the IP\instance name or server name\instance name works fine. Connecting to
the default instance using the alias also works fine.
I have confirmed that when connecting to the non-default instance, using
either the IP or server name, the connecting is made through the correct [no
t
1433] port.
We have a developer network, with some workstations being able to use the
"alias"\instance name, and other workstations not, when conencting to the
non-default instance. So, there is something particular to some workstations
that is preventing access to non-default SQL instances using the alias.
The developer workstations are all built identically, so could it be an XP
service pack that may only have been applied to some workstations, that coul
d
be causing the problem? Or is there another reason.
Thanks!
dcnDeveloper.Canada.Net wrote:
> I am having a problem connecting to a SQL Server named [non-default]
> instance using the Server "alias" name. Connecting, through
> Enterprise Manager with the IP\instance name or server name\instance
> name works fine. Connecting to the default instance using the alias
> also works fine.
> I have confirmed that when connecting to the non-default instance,
> using either the IP or server name, the connecting is made through
> the correct [not 1433] port.
> We have a developer network, with some workstations being able to use
> the "alias"\instance name, and other workstations not, when
> conencting to the non-default instance. So, there is something
> particular to some workstations that is preventing access to
> non-default SQL instances using the alias.
> The developer workstations are all built identically, so could it be
> an XP service pack that may only have been applied to some
> workstations, that could be causing the problem? Or is there another
> reason.
> Thanks!
> dcn
SP2 does have some issues connecting to MSDE. IUf you define an alias,
you use just the alias name to connect, not alias\instance.
Are you defining the alias in the SQL Server Client Network Utility?
David Gugick
Imceda Software
www.imceda.com|||I must use the instance name, as we have about 10 instances on the same
server, all using different ports.
I have not defined the alias in the client utility, although I know this
works. It is just puzzling why I cannot use the alias\instance name when
connecting to the database, whereas other computers can. There is somthing
different between half the PCs in our development group, and the
rest...although not sure what.
We will likely not spin our wheels any further on this, and just live with
an alias setting in the client utility as a workaround for the affected PCs.
Thanks!
dcn
"David Gugick" wrote:
> Developer.Canada.Net wrote:
> SP2 does have some issues connecting to MSDE. IUf you define an alias,
> you use just the alias name to connect, not alias\instance.
> Are you defining the alias in the SQL Server Client Network Utility?
> --
> David Gugick
> Imceda Software
> www.imceda.com
>|||I'm sure they were all built the same. That doesn't really mean they are
necessarily the same now if they are developer machines though (unless your
developers are MUCH different than any I ever met). Have you tried having
them upgrade the MDAC on the machines that don'e work just for kicks and
grins? You can find the latest at www.microsoft.com/data
"Developer.Canada.Net" <Developer.Canada.Net@.discussions.microsoft.com>
wrote in message news:7974ACEC-FE12-4250-B122-8865CFE44C10@.microsoft.com...
> I must use the instance name, as we have about 10 instances on the same
> server, all using different ports.
> I have not defined the alias in the client utility, although I know this
> works. It is just puzzling why I cannot use the alias\instance name when
> connecting to the database, whereas other computers can. There is somthing
> different between half the PCs in our development group, and the
> rest...although not sure what.
> We will likely not spin our wheels any further on this, and just live with
> an alias setting in the client utility as a workaround for the affected
PCs.
> Thanks!
> dcn
>
> "David Gugick" wrote:
>|||Developer.Canada.Net wrote:
> I must use the instance name, as we have about 10 instances on the
> same server, all using different ports.
> I have not defined the alias in the client utility, although I know
> this works. It is just puzzling why I cannot use the alias\instance
> name when connecting to the database, whereas other computers can.
> There is somthing different between half the PCs in our development
> group, and the rest...although not sure what.
> We will likely not spin our wheels any further on this, and just live
> with an alias setting in the client utility as a workaround for the
> affected PCs. Thanks!
> dcn
>
> "David Gugick" wrote:
>
Try turning off the Windows Firewall and see what happens.
David Gugick
Imceda Software
www.imceda.com|||On Thu, 10 Mar 2005 15:56:17 -0500, "David Gugick"
<davidg-nospam@.imceda.com> wrote:
in <#6n6bObJFHA.3428@.tk2msftngp13.phx.gbl>
>SP2 does have some issues connecting to MSDE. IUf you define an alias,
>you use just the alias name to connect, not alias\instance.
As far as I can tell the only issues have to do with implementing
the ridiculous excuse for a firewall that SP2 provides. SP2 has
no issues connecting to MSDE if a real firewall like KERIO is
used. My apologies, but this is deliberately meant to sound
inflammatory.
Stefan Berglund|||Stefan Berglund wrote:
> On Thu, 10 Mar 2005 15:56:17 -0500, "David Gugick"
> As far as I can tell the only issues have to do with implementing
> the ridiculous excuse for a firewall that SP2 provides. SP2 has
> no issues connecting to MSDE if a real firewall like KERIO is
> used. My apologies, but this is deliberately meant to sound
> inflammatory.
I assume you mean inflammatory to Microsoft, no?
David G.|||On Sat, 12 Mar 2005 12:51:21 -0500, "David Gugick"
<davidg-nospam@.imceda.com> wrote:
in <#qyVYwyJFHA.336@.TK2MSFTNGP09.phx.gbl>
>Stefan Berglund wrote:
>I assume you mean inflammatory to Microsoft, no?
Yes, of course.
Stefan Berglund|||I agree it's not a full-featured firewall, but is much improved in SP2
and as I understand it will examine incoming and outgoing packets to
some degree. For end users who until recently probably didn't keep their
virus definitions up to date, the firewall can help. Most end-users who
are on some sort of broadband have their PCs hooked directly to the
cable/DSL modem, further exposing them to attack. For businesses, this
is generally not a problem, but it does cause headaches for many
end-users, headaches aside.
David G.|||On Sun, 13 Mar 2005 21:29:57 -0500, "David Gugick"
<davidg-nospam@.imceda.com> wrote:
in <OueRz2DKFHA.732@.TK2MSFTNGP12.phx.gbl>
>I agree it's not a full-featured firewall, but is much improved in SP2
>and as I understand it will examine incoming and outgoing packets to
>some degree. For end users who until recently probably didn't keep their
>virus definitions up to date, the firewall can help. Most end-users who
>are on some sort of broadband have their PCs hooked directly to the
>cable/DSL modem, further exposing them to attack. For businesses, this
>is generally not a problem, but it does cause headaches for many
>end-users, headaches aside.
I can only suppose that by improved you mean turned on by
default. I was not aware that it did any stateful inspection of
packets or that it even looked at outgoing traffic. Obviously
the ~Windows firewall~ is better than nothing, but I prefer and
insist that all my clients operate from behind a hardware
firewall in addition to having Kerio, AVG, Ad-Aware, and Spybot
S&D on every box. I run all that even on my server which also
runs SQL and it goes without saying that they all get along
together fabulously.
Kerio can be a bit overwhelming for the novice, but once it's set
up it's a breeze. I've even used it to reclaim a client's laptop
that had been taken over by the Dark Angel trojan. This thing
was so insidious that on every reboot it took out ZoneAlarm and
Norton. Norton was able to detect its attempts at phoning home
but wasn't able to cope otherwise. It was at this point that I
removed Norton and ZoneAlarm from my boxes and went with tools
that are comparatively more lightweight and that do the job
expected of them.
Stefan Berglund
Monday, February 20, 2012
Problem Connecting to SQL Server Non-default Named Instance
Labels:
alias,
connecting,
database,
enterprise,
instance,
instanceusing,
manager,
microsoft,
mysql,
named,
non-default,
oracle,
server,
sql
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment