Named Pipe question

Hi,
I'm wondering when do I need to use the Named Pipes connection in our SQL
Server 2000 and clients environment?
If all our LAN are running on the TCP/IP, do we need to use the Name Pipes?
Thanks for help.
JasonNamed Pipes is used only for LANs. However it does not support routing and
gateways. As it requires more interaction between your server and your
client you'll need a fast network because of the extra burden (especially
when compared to TCP\IP).
If TCP\IP works fine for you, go with it and disable NP to free some
resources and close extra ways for potention intruders.
--
Ekrem Önsoy
"Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
> Hi,
> I'm wondering when do I need to use the Named Pipes connection in our SQL
> Server 2000 and clients environment?
> If all our LAN are running on the TCP/IP, do we need to use the Name
> Pipes?
> Thanks for help.
>
> Jason
>|||> Named Pipes is used only for LANs. However it does not support
> routing and gateways.
It's true that you don't route named pipes. But it's also the case you don't
directly route any other SQL Server netlib protocols such as TCP/IP which in
this particular context is really meant to refer to sockets instead of TCP at
the transport layer or IP at the network layer. In other words, you don't
care whether you can directly route any of the session layer protocols such
as sockets, named pipes, or RPC as long as they are built on IP that is
routable.
I don't know all the ancient history of SQL Server, but since 7.0 at least
and possibly with 6.5, named pipes for all that matters are built on top of
TCP/IP and can rely on IP for routing at the network layer.
Linchi
"Ekrem Ã?nsoy" wrote:
> Named Pipes is used only for LANs. However it does not support routing and
> gateways. As it requires more interaction between your server and your
> client you'll need a fast network because of the extra burden (especially
> when compared to TCP\IP).
> If TCP\IP works fine for you, go with it and disable NP to free some
> resources and close extra ways for potention intruders.
> --
> Ekrem nsoy
>
> "Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
> news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
> > Hi,
> >
> > I'm wondering when do I need to use the Named Pipes connection in our SQL
> > Server 2000 and clients environment?
> > If all our LAN are running on the TCP/IP, do we need to use the Name
> > Pipes?
> > Thanks for help.
> >
> >
> > Jason
> >
>|||> I don't know all the ancient history of SQL Server, but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
Here's how I understand it:
There are network protocols, such as:
TCP/IP (has routing functionality of course)
NetBEUI (very limited, if any, routing functionality)
IPX (original protocol in Novell)
A network protocol is of little use if we can't send data back and fort between application over
that network protocol. So, there are APIs:
NETBIOS (originally developed for NetBEUI, but is also supported over IP (requires WINS for name
resolution))
Sockets (not available for NetBEUI AFAIK, only TCP/IP)
Named Pipes (built on top of NETBIOS)
RPC (implemented and available over both NetBEUI and IP)
SPX (as I understand it, the API over IPX)
When MS released "their" SQL Server, they needed a way for the client app to communicate to the
server. They decided to go for Named Pipes and developed what we call "netlib". I.e., the MS
deveopers used the Named Pipes API (which is similar to reading and writing to a file from the
programmers perspective) when developing the Named Pipes netlib.
Over time, new netlibs were developed, where in 2000, this culminated in below list (netlibs using
the API):
Named Pipes
Sockets
RPC
VIA
SPX
There was never a netlib deveoped directly on top of NETBIOS, but indirectly through Named Pipes.
So, back to the original comment:
> but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
Named Pipes uses NETBIOS, which available over IP, and hence is routable. This isn't tied to a
specific version of SQL Server.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:0A9D3D0D-2539-477C-8885-7CF2A55696F0@.microsoft.com...
>> Named Pipes is used only for LANs. However it does not support
>> routing and gateways.
> It's true that you don't route named pipes. But it's also the case you don't
> directly route any other SQL Server netlib protocols such as TCP/IP which in
> this particular context is really meant to refer to sockets instead of TCP at
> the transport layer or IP at the network layer. In other words, you don't
> care whether you can directly route any of the session layer protocols such
> as sockets, named pipes, or RPC as long as they are built on IP that is
> routable.
> I don't know all the ancient history of SQL Server, but since 7.0 at least
> and possibly with 6.5, named pipes for all that matters are built on top of
> TCP/IP and can rely on IP for routing at the network layer.
> Linchi
> "Ekrem Önsoy" wrote:
>> Named Pipes is used only for LANs. However it does not support routing and
>> gateways. As it requires more interaction between your server and your
>> client you'll need a fast network because of the extra burden (especially
>> when compared to TCP\IP).
>> If TCP\IP works fine for you, go with it and disable NP to free some
>> resources and close extra ways for potention intruders.
>> --
>> Ekrem nsoy
>>
>> "Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
>> news:uiQd%23KFIIHA.5400@.TK2MSFTNGP04.phx.gbl...
>> > Hi,
>> >
>> > I'm wondering when do I need to use the Named Pipes connection in our SQL
>> > Server 2000 and clients environment?
>> > If all our LAN are running on the TCP/IP, do we need to use the Name
>> > Pipes?
>> > Thanks for help.
>> >
>> >
>> > Jason
>> >

Named Pipe Provider/Linked Server Connection Error

Hello, everyone!

I'm currently having an issue with a linked server. Here's the surrounding information:

A) I have a clustered SQL Server 2005 Instance (A) and a SQL Server 2000 instance (B).

B) There is a linked server on A to B. When I set it up, I did run the fix to ensure A could talk to B (There was an issue with communication between 2005 and 2000 servers). It has been there since I installed A, and has worked fine.. Until last week.

C) This linked server uses static credentials to connect to B.

D) Named Pipes are enabled on both servers to listen to both connections on both A and B in cliconfg. So A has a named pipe listening for B, and B has a named pipe listening for A.

E) A has a view that looks at a table on B - It's a table view, very simple, just pulls in all the data from the table on B.

So, I go to do a select statement from the view, connected as a user other then 'sa'. I then get the error:

Named Pipes Provider: Could not open a connection to SQL Server Linked Server

Error Source: ncli Client (Paraphrasing, didn't copy that down, but it was the ODBC connector)

Well, that's odd. It's been working fine for months now..

I then go and connect as sa on A to query B. It works! Mind you, absolutely NO QUERY from A to B will run again until I run SOME kind of query has been run as sa on A.

Mind you, this is not a credential issue. Every user who connects to the linked server to B uses a stored credential that is DBO to the database on B. The same User Name and Password exists on both A and B.

Also of note, I check the activity monitor. There's a process that is "dormant" every time I run a query against the view. The details of this connection are:

sp_reset_connection;1

My question is, why is it resetting the connection on B when being queried from A? Why is it "all of a sudden" a problem? Are there any changes that coudl ahve been made that would cause this?

Any help with this confusing issue would be appreciated.

Thanks!

No one has any idea?

|||we found this to help us out: data source = servername,1433 (the port used), we noticed that when using an alias as the Linked Servername (not the actual servername) it failed, yet if the servername was the LS name it worked, so we added ',1433' to the data source and it cleared up our problem.

Named Pipe Provider/Linked Server Connection Error

Hello, everyone!

I'm currently having an issue with a linked server. Here's the surrounding information:

A) I have a clustered SQL Server 2005 Instance (A) and a SQL Server 2000 instance (B).

B) There is a linked server on A to B. When I set it up, I did run the fix to ensure A could talk to B (There was an issue with communication between 2005 and 2000 servers). It has been there since I installed A, and has worked fine.. Until last week.

C) This linked server uses static credentials to connect to B.

D) Named Pipes are enabled on both servers to listen to both connections on both A and B in cliconfg. So A has a named pipe listening for B, and B has a named pipe listening for A.

E) A has a view that looks at a table on B - It's a table view, very simple, just pulls in all the data from the table on B.

So, I go to do a select statement from the view, connected as a user other then 'sa'. I then get the error:

Named Pipes Provider: Could not open a connection to SQL Server Linked Server

Error Source: ncli Client (Paraphrasing, didn't copy that down, but it was the ODBC connector)

Well, that's odd. It's been working fine for months now..

I then go and connect as sa on A to query B. It works! Mind you, absolutely NO QUERY from A to B will run again until I run SOME kind of query has been run as sa on A.

Mind you, this is not a credential issue. Every user who connects to the linked server to B uses a stored credential that is DBO to the database on B. The same User Name and Password exists on both A and B.

Also of note, I check the activity monitor. There's a process that is "dormant" every time I run a query against the view. The details of this connection are:

sp_reset_connection;1

My question is, why is it resetting the connection on B when being queried from A? Why is it "all of a sudden" a problem? Are there any changes that coudl ahve been made that would cause this?

Any help with this confusing issue would be appreciated.

Thanks!

No one has any idea?

Named pipe error 53

I get the following error when I try to connect from an XP SP2 client to SQL
MSDE:
An error has occurred while establishing a connection to the server. When
connecting to SQL Server 2005, this failure may be caused by the fact that
under the default settings SQL Server does not allow remote connections.
(provider: Named Pipes Provider, error: 40 - Could not open a connection to
SQL Server) (Microsoft SQL Server, Error: 53)
Before last week, al worked fine, but suddenly I get this message.
What goes wrong?Is the service on another machine ? Can you reach the computer via ping ?
Did you try disabling the firewall on the Windows XP machine to see if it is
dedicted to the settings of the firewall ?
HTH, Jens K. Suessmeyer.
http://www.sqlserver2005.de
--
"Johan" <Johan@.discussions.microsoft.com> wrote in message
news:68D2C2C3-B0B1-4756-BBBD-B6A6D2577EDA@.microsoft.com...
>I get the following error when I try to connect from an XP SP2 client to
>SQL
> MSDE:
> An error has occurred while establishing a connection to the server. When
> connecting to SQL Server 2005, this failure may be caused by the fact that
> under the default settings SQL Server does not allow remote connections.
> (provider: Named Pipes Provider, error: 40 - Could not open a connection
> to
> SQL Server) (Microsoft SQL Server, Error: 53)
> Before last week, al worked fine, but suddenly I get this message.
> What goes wrong?sql

Named Pipe Connection through ASP - HELP!

We have a problem with interfacing a dll which is called through an Active Server Page. Our network infrastructure uses Named Pipes on Windows 2000 with SQL Server 2000 IIS version 5.0 and MDAC 2.5.

When the ASP calls the dll which (should) insert a new record into a SQL table via a stored procedure call (wrapped as a COM object), we receive the following error:

80004005 SQL Server does not exist or access denied error.

We have tried running this from the Server Admin account, but makes no difference. If we use TCP/IP the mechanism works fine, unfortunately this is not a route we can utilse without significant overall network security implications.

Any advice much appreciated!As you probably know, that's a generic error code. It could be network problems (firewall etc), file permissions or location, or any number of other things. This link shows some of the possible causes (http://support.microsoft.com/support/kb/articles/Q169/3/77.ASP?LN=EN-US&SD=gn&FR=0&qry=80004005&rnk=1&src=DHCS_MSPSS_gn_SRCH&SPR=SQL).

Named Pipe and Clustering

Hi,
I need to disable named pipes in a SQL Cluster environment (Windows 2000 and
SQL 2000 latest SP). Here is the scenario:
Our security policy requires me to secure my production SQL Server (Virtual
SQL Cluster name=SQL01) by disabling any access to SQL Server except access
from application server. I implemented this security in UAT (Non clustered )
by creating an IPSEC filter and disabling Named Pipes on SQL Server. In one
IPSEC filter, All IP Traffic to port 1433 is blocked. In another filter,
traffic from application server IP Address is permitted. This configuration
worked fine in UAT.
When I promoted the same IPSEC policy to production (both nodes
active-passive), I noticed that I can't disable Named Pipes in cluster
environment. Is there any work around this?
Can I change default pipe for Named Pipe in order to block SQL connections
coming from default pipe?
Do you have any better suggestion to secure SQL Server?
ThanksThis was an update in sp3 that was not well documented. After installing
sp3, you can't remove Named Pipes on a Cluster. If Named Pipes was
previously removed (prior to sp3) , then it will not add it back.
We experienced numerous customer problems where the server would not come
online, and it was only listening on tcp. Here's the full reference in the
kb.
831127 Named Pipes Support Cannot Be Removed on a Virtual Server That Is
http://support.microsoft.com/?id=831127
My recommendation would be to use ISA server and publish the SQL Server.
This will allow you to only publish the TCP netlib.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

name pipe VS tcpip

I found that I can only use name pipe to connect to the sql server.
When I use tcpip, it fails to connect.
I am sure I have enabled the TCP/IP protocol in SQL server
What causes it?
sql is using port no.1433 and I have try using dynamically determine port
and force it to 1433 in ODBC setting.
thank you very much
"!" <!@.!.!> wrote in message news:%236FqHb0qEHA.3416@.TK2MSFTNGP15.phx.gbl...
> I found that I can only use name pipe to connect to the sql server.
> When I use tcpip, it fails to connect.
> I am sure I have enabled the TCP/IP protocol in SQL server
> What causes it?
> sql is using port no.1433 and I have try using dynamically determine port
> and force it to 1433 in ODBC setting.
There are a lot of reasons that this can fail, application type being one of
them. Reference the following as a troubleshooting guide:
http://support.microsoft.com/default...b;en-us;827422
Steve

Name Pipe Hijacking Patch Problem

I've got a little problem. I pushed out the MS Named Pipe patch (MS03-031, q815495) to a SQL 7.0 SP4 server. We have an application that uses Named Pipes. After applying the patch the users weren't able to connect. Administrative users can connect ok.

We turned around and attempted the Patch to the Patch (Q823492) which was supposed to fix this problem. As you can tell it didn't fix the problem. We were able to move the clients over to TCP/IP and get them off of the Named Pipes but we still have processes internal to this application that aren't able to work.

We looked at backing out the patch but that is going to mean a rebuild of the database and this SQL database is almost 40 GB. I would rather find another method if at all possible to resolve this issue. Does anyone have any idea's? Any help is appreciated!

Thanks from a newbie!Hi...

i'm kind of having the same problem here. the applications that runs on SQL7.0 is not working properly now. is there a way that i can uninstall this patch?

thank you