BUG? Unable to Contact non default instance of SQL server

Hi,
think i have found a resolution to a problem which has been ocurring
intermittantly on new sql server installations for some time. The symptoms
are being unable to see or connect to a named instance of sql server when
there is a default instance running also. I have spotted this behaviour in
both workstation installed versions and windows 2000 server installations.
It appears the problem is due to the named instance using tcpip with a port
of 1433 the same as the default instance. One of my machines which has a
named instance which can be connected to, has a Tcpip port of 1104. So i
guess the installation procedure is supposed to assign an unused tcpip port
when creating new instances (but this isn't occurring sometimes).
I changed the port to 1104 and was then able to connect correctly. I also
tried removing tcpip and connecting only using named pipes and this worked
also.
The latest machine build (which had this issue) was installed by installing
the default instance then the named instance and then servicepacking the
default and then the named instance with service pack3.
Thanks
TimBwhat's your connecting client's mdac-level ?
jobi
"timb" <timb@.test.com> wrote in message
news:u8fAuakjDHA.1740@.TK2MSFTNGP12.phx.gbl...
> Hi,
> think i have found a resolution to a problem which has been ocurring
> intermittantly on new sql server installations for some time. The
symptoms
> are being unable to see or connect to a named instance of sql server when
> there is a default instance running also. I have spotted this behaviour in
> both workstation installed versions and windows 2000 server installations.
> It appears the problem is due to the named instance using tcpip with a
port
> of 1433 the same as the default instance. One of my machines which has a
> named instance which can be connected to, has a Tcpip port of 1104. So i
> guess the installation procedure is supposed to assign an unused tcpip
port
> when creating new instances (but this isn't occurring sometimes).
> I changed the port to 1104 and was then able to connect correctly. I
also
> tried removing tcpip and connecting only using named pipes and this worked
> also.
> The latest machine build (which had this issue) was installed by
installing
> the default instance then the named instance and then servicepacking the
> default and then the named instance with service pack3.
>
> Thanks
> TimB
>|||What does MDAC have to do with it?
"jobi" <jobi@.reply2.group> wrote in message
news:bm3ccv$1si$1@.reader08.wxs.nl...
> what's your connecting client's mdac-level ?
> jobi
> "timb" <timb@.test.com> wrote in message
> news:u8fAuakjDHA.1740@.TK2MSFTNGP12.phx.gbl...
> > Hi,
> > think i have found a resolution to a problem which has been ocurring
> > intermittantly on new sql server installations for some time. The
> symptoms
> > are being unable to see or connect to a named instance of sql server
when
> > there is a default instance running also. I have spotted this behaviour
in
> > both workstation installed versions and windows 2000 server
installations.
> > It appears the problem is due to the named instance using tcpip with a
> port
> > of 1433 the same as the default instance. One of my machines which has
a
> > named instance which can be connected to, has a Tcpip port of 1104. So
i
> > guess the installation procedure is supposed to assign an unused tcpip
> port
> > when creating new instances (but this isn't occurring sometimes).
> >
> > I changed the port to 1104 and was then able to connect correctly. I
> also
> > tried removing tcpip and connecting only using named pipes and this
worked
> > also.
> >
> > The latest machine build (which had this issue) was installed by
> installing
> > the default instance then the named instance and then servicepacking the
> > default and then the named instance with service pack3.
> >
> >
> > Thanks
> >
> > TimB
> >
> >
>|||You have to have at least mdac 2.6 to be able to detect virtual instances by
their instancename if they don't run on port 1433.
Search KB and BOL !
jobi
"timb" <timb@.test.com> wrote in message
news:#SLUYGojDHA.2232@.TK2MSFTNGP09.phx.gbl...
> What does MDAC have to do with it?
> "jobi" <jobi@.reply2.group> wrote in message
> news:bm3ccv$1si$1@.reader08.wxs.nl...
> > what's your connecting client's mdac-level ?
> >
> > jobi
> > "timb" <timb@.test.com> wrote in message
> > news:u8fAuakjDHA.1740@.TK2MSFTNGP12.phx.gbl...
> > > Hi,
> > > think i have found a resolution to a problem which has been
ocurring
> > > intermittantly on new sql server installations for some time. The
> > symptoms
> > > are being unable to see or connect to a named instance of sql server
> when
> > > there is a default instance running also. I have spotted this
behaviour
> in
> > > both workstation installed versions and windows 2000 server
> installations.
> > > It appears the problem is due to the named instance using tcpip with a
> > port
> > > of 1433 the same as the default instance. One of my machines which
has
> a
> > > named instance which can be connected to, has a Tcpip port of 1104.
So
> i
> > > guess the installation procedure is supposed to assign an unused
tcpip
> > port
> > > when creating new instances (but this isn't occurring sometimes).
> > >
> > > I changed the port to 1104 and was then able to connect correctly.
I
> > also
> > > tried removing tcpip and connecting only using named pipes and this
> worked
> > > also.
> > >
> > > The latest machine build (which had this issue) was installed by
> > installing
> > > the default instance then the named instance and then servicepacking
the
> > > default and then the named instance with service pack3.
> > >
> > >
> > > Thanks
> > >
> > > TimB
> > >
> > >
> >
> >
>|||Hi Jobi,
no both machines are mdac 2.7. If you read my initial post you
can see that i changed the port to be different to the default port (1433)
and i could then see the instance! i.e. this is due to the sql server
installation for the named instance assigning it a port which is already in
use rather than using a new port.
Tim B
"jobi" <jobi@.reply2.group> wrote in message
news:bm5ke4$jrs$1@.reader08.wxs.nl...
> You have to have at least mdac 2.6 to be able to detect virtual instances
by
> their instancename if they don't run on port 1433.
> Search KB and BOL !
> jobi
> "timb" <timb@.test.com> wrote in message
> news:#SLUYGojDHA.2232@.TK2MSFTNGP09.phx.gbl...
> > What does MDAC have to do with it?
> >
> > "jobi" <jobi@.reply2.group> wrote in message
> > news:bm3ccv$1si$1@.reader08.wxs.nl...
> > > what's your connecting client's mdac-level ?
> > >
> > > jobi
> > > "timb" <timb@.test.com> wrote in message
> > > news:u8fAuakjDHA.1740@.TK2MSFTNGP12.phx.gbl...
> > > > Hi,
> > > > think i have found a resolution to a problem which has been
> ocurring
> > > > intermittantly on new sql server installations for some time. The
> > > symptoms
> > > > are being unable to see or connect to a named instance of sql server
> > when
> > > > there is a default instance running also. I have spotted this
> behaviour
> > in
> > > > both workstation installed versions and windows 2000 server
> > installations.
> > > > It appears the problem is due to the named instance using tcpip with
a
> > > port
> > > > of 1433 the same as the default instance. One of my machines which
> has
> > a
> > > > named instance which can be connected to, has a Tcpip port of 1104.
> So
> > i
> > > > guess the installation procedure is supposed to assign an unused
> tcpip
> > > port
> > > > when creating new instances (but this isn't occurring sometimes).
> > > >
> > > > I changed the port to 1104 and was then able to connect correctly.
> I
> > > also
> > > > tried removing tcpip and connecting only using named pipes and this
> > worked
> > > > also.
> > > >
> > > > The latest machine build (which had this issue) was installed by
> > > installing
> > > > the default instance then the named instance and then servicepacking
> the
> > > > default and then the named instance with service pack3.
> > > >
> > > >
> > > > Thanks
> > > >
> > > > TimB
> > > >
> > > >
> > >
> > >
> >
> >
>

Broken Images and Charts in Deployed Reports

Hi all,
Does anyone know why on some installations of RS, using the Reports Viewer
(http://localhost/Reports/), all images and charts appear to be broken, but
if exported, work fine. Using ReportServer works, but its not very
user-friendly for our clients.
I only read a couple of posts about this issue, but couldnt find an answer.
Some people said that if you enable Allow All Cookie's in IE, it works... but
why then is this problem only occuring on some installations of RS?
The one major differance I can point out is that it seams that broken images
only occur on Servers (Win2003) but not on development (XP) computers... Is
this as simple as an IIS issue, or security perhaps?
Please help! I'm sure there are many others with the same issue!
Thanks,
AndreAnswer is simple, and stupid...
IE does block the cookies from the RS website for some reason.
There are two fixes I know.
1) Inform anyone using RS to find the security icon at the bottom of IE and
right click it and allow Cookies from that site.
2) Inform anyone using RS to go to IE security and turn of automatic
handling of cookies and allow all cookies... I dont think this is quite hte
best idea though.
Andre
"Arkiliknam" wrote:
> Hi all,
> Does anyone know why on some installations of RS, using the Reports Viewer
> (http://localhost/Reports/), all images and charts appear to be broken, but
> if exported, work fine. Using ReportServer works, but its not very
> user-friendly for our clients.
> I only read a couple of posts about this issue, but couldnt find an answer.
> Some people said that if you enable Allow All Cookie's in IE, it works... but
> why then is this problem only occuring on some installations of RS?
> The one major differance I can point out is that it seams that broken images
> only occur on Servers (Win2003) but not on development (XP) computers... Is
> this as simple as an IIS issue, or security perhaps?
> Please help! I'm sure there are many others with the same issue!
> Thanks,
> Andre