named pipes?

Hello
Which is the difference between using named pipes and TCP/IP?
Is it possible to enable TCP/IP and disable named pipes at the same time for
the server communication?
What happens if I disable named pipes?
Tanx
Alejandra Parra
Mexico
Named Pipes is MUCH slower, unless it is between servers, where it runs in
the kernal. I believe it has to do with the ability to queue requests - but
I'm not sure about that.
I usually disable named pipes on my servers. Otherwise people create DSNs
to connect and indicate Named Pipes, then wonder why the application is so
slow.
"Alejandra Parra" wrote:

> Hello
> Which is the difference between using named pipes and TCP/IP?
> Is it possible to enable TCP/IP and disable named pipes at the same time for
> the server communication?
> What happens if I disable named pipes?
> Tanx
> Alejandra Parra
> Mexico
>
>
|||"Alejandra Parra" <alparrita@.hotmail.com> wrote in message
news:OzuMkbRkEHA.2908@.tk2msftngp13.phx.gbl...

> Which is the difference between using named pipes and TCP/IP?
SQL Server BOL has a good write-up on the differences between these two
libraries see 'Named Pipes vs. TCP/IP Sockets'.

> Is it possible to enable TCP/IP and disable named pipes at the same time
for
> the server communication?
Yes, just make sure the network libraries are set up the same way on the
client side.

> What happens if I disable named pipes?
Most likely nothing... I've seen some old utilities and software dependent
on named pipes, however it's unlikely to effect you. As always, test before
deploying to production.
Steve

named pipes?

Hello
Which is the difference between using named pipes and TCP/IP?
Is it possible to enable TCP/IP and disable named pipes at the same time for
the server communication?
What happens if I disable named pipes?
Tanx
Alejandra Parra
MexicoNamed Pipes is MUCH slower, unless it is between servers, where it runs in
the kernal. I believe it has to do with the ability to queue requests - but
I'm not sure about that.
I usually disable named pipes on my servers. Otherwise people create DSNs
to connect and indicate Named Pipes, then wonder why the application is so
slow.
"Alejandra Parra" wrote:

> Hello
> Which is the difference between using named pipes and TCP/IP?
> Is it possible to enable TCP/IP and disable named pipes at the same time f
or
> the server communication?
> What happens if I disable named pipes?
> Tanx
> Alejandra Parra
> Mexico
>
>|||"Alejandra Parra" <alparrita@.hotmail.com> wrote in message
news:OzuMkbRkEHA.2908@.tk2msftngp13.phx.gbl...

> Which is the difference between using named pipes and TCP/IP?
SQL Server BOL has a good write-up on the differences between these two
libraries see 'Named Pipes vs. TCP/IP Sockets'.

> Is it possible to enable TCP/IP and disable named pipes at the same time
for
> the server communication?
Yes, just make sure the network libraries are set up the same way on the
client side.

> What happens if I disable named pipes?
Most likely nothing... I've seen some old utilities and software dependent
on named pipes, however it's unlikely to effect you. As always, test before
deploying to production.
Steve

named pipes?

Hello
Which is the difference between using named pipes and TCP/IP?
Is it possible to enable TCP/IP and disable named pipes at the same time for
the server communication?
What happens if I disable named pipes?
Tanx
Alejandra Parra
Mexico"Alejandra Parra" <alparrita@.hotmail.com> wrote in message
news:OzuMkbRkEHA.2908@.tk2msftngp13.phx.gbl...
> Which is the difference between using named pipes and TCP/IP?
SQL Server BOL has a good write-up on the differences between these two
libraries see 'Named Pipes vs. TCP/IP Sockets'.
> Is it possible to enable TCP/IP and disable named pipes at the same time
for
> the server communication?
Yes, just make sure the network libraries are set up the same way on the
client side.
> What happens if I disable named pipes?
Most likely nothing... I've seen some old utilities and software dependent
on named pipes, however it's unlikely to effect you. As always, test before
deploying to production.
Steve

Named pipes vs TCP/IP and NETWORKIO wait type

I am experiencing a problem whereby a 3rd party application is performing data transfers between tables in a database and they are taking enormous amounts of time.
I have no way of knowing what it is actually doing but when I examine the current activity, the RUNNABLE process shows NETWORKIO in the Wait Type column. What is this as I have not been able to find anything in BOL.
Related to this, what is the faster way of connection: named pipes or TCP/IP ? Both the client and the server have both enabled but the application is using TCP/IP to connect. Would named pipes be faster ?
Regards,
Peter Apostolakopoulos.
Check this out: http://sqldev.net/misc/WaitTypes.htm
Are both these tables in the same DB? What command is it using?
Andrew J. Kelly SQL MVP
"Peter Apostolakopoulos" <apostolp@.britannic.co.uk> wrote in message
news:BDFFD198-0B85-44EE-9CC3-55863CD7F980@.microsoft.com...
> I am experiencing a problem whereby a 3rd party application is performing
data transfers between tables in a database and they are taking enormous
amounts of time.
> I have no way of knowing what it is actually doing but when I examine the
current activity, the RUNNABLE process shows NETWORKIO in the Wait Type
column. What is this as I have not been able to find anything in BOL.
> Related to this, what is the faster way of connection: named pipes or
TCP/IP ? Both the client and the server have both enabled but the
application is using TCP/IP to connect. Would named pipes be faster ?
> Regards,
> Peter Apostolakopoulos.
|||Andrew,
Many thanks for the info. It is very useful. I am still having problems but I am pursuing this with the suppliers as I they have written some custom SQL to do the data migration which is "not the best" !!
Peter Apostolakopoulos
sql

Named pipes vs TCP/IP and NETWORKIO wait type

I am experiencing a problem whereby a 3rd party application is performing da
ta transfers between tables in a database and they are taking enormous amoun
ts of time.
I have no way of knowing what it is actually doing but when I examine the cu
rrent activity, the RUNNABLE process shows NETWORKIO in the Wait Type column
. What is this as I have not been able to find anything in BOL.
Related to this, what is the faster way of connection: named pipes or TCP/IP
? Both the client and the server have both enabled but the application is u
sing TCP/IP to connect. Would named pipes be faster ?
Regards,
Peter Apostolakopoulos.Check this out: http://sqldev.net/misc/WaitTypes.htm
Are both these tables in the same DB? What command is it using?
Andrew J. Kelly SQL MVP
"Peter Apostolakopoulos" <apostolp@.britannic.co.uk> wrote in message
news:BDFFD198-0B85-44EE-9CC3-55863CD7F980@.microsoft.com...
> I am experiencing a problem whereby a 3rd party application is performing
data transfers between tables in a database and they are taking enormous
amounts of time.
> I have no way of knowing what it is actually doing but when I examine the
current activity, the RUNNABLE process shows NETWORKIO in the Wait Type
column. What is this as I have not been able to find anything in BOL.
> Related to this, what is the faster way of connection: named pipes or
TCP/IP ? Both the client and the server have both enabled but the
application is using TCP/IP to connect. Would named pipes be faster ?
> Regards,
> Peter Apostolakopoulos.|||Andrew,
Many thanks for the info. It is very useful. I am still having problems but
I am pursuing this with the suppliers as I they have written some custom SQL
to do the data migration which is "not the best" !!
Peter Apostolakopoulos

Named pipes vs TCP/IP

Hi all.
We have a customer with some connection problems running Remote desctop
(Terminal server). In the startuplog of the SQL2000 server we can't find
anything else than:
2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
Pipes.
On our server we have the following started. What should we do to get the
server listening on the TCP/IP too? We think this could be the problem.
2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
Named Pipes.
Thanks all.
geir
Is the IP netlib enabled (Server Network Utility)?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Geir Holme" <geir@.multicase.no> wrote in message news:u1OjFIJ5FHA.1032@.TK2MSFTNGP11.phx.gbl...
> Hi all.
> We have a customer with some connection problems running Remote desctop
> (Terminal server). In the startuplog of the SQL2000 server we can't find
> anything else than:
> 2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
> Pipes.
> On our server we have the following started. What should we do to get the
> server listening on the TCP/IP too? We think this could be the problem.
>
> 2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
> 2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
> 2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
> Named Pipes.
>
>
> Thanks all.
> geir
>

Named Pipes vs TCP/IP

Why would one choose Named Pipes over TCP/IP for the client net lib? We have
noticed for some of our customers that changing to named pipes speeds up the
response times of our application. But it is my understanding that a
properly configured LAN should work fine with TCP/IP.
Thanks,
Bob Castleman
SuccessWare Software
It is my understanding that named pipes have slightly less overhead than
TCP/IP but there it is usually not enough to warrant using named pipes. TCP
is much more versatile and should be encouraged in general over named pipes.
One thing to note is that WIN2003 has a 25% higher throuput in TCP over
Win2000 and DNS lookups are up to 120% faster as well. If your clients are
looking for speed improvements and are not on Win2003 they should try it
out. Another thing to note is that usually when clients tell me one
protocol is faster than another I tend to find there is too much chatter
from the client to the server in the first place. The more packets sent
back and forth the more likely you will have performance issues under heavy
load.
Andrew J. Kelly SQL MVP
"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
> Thanks,
> Bob Castleman
> SuccessWare Software
>
|||A specific example of what we are running into happened this morning. A
customer called complaining of speed problems. Everything was "fine" on
Friday and today it was slow. CPU load on the database server was around 2%.
Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
Named Pipes and the time it took to load our application went from 20
seconds to 2 seconds. He reported a similar effect on the other
workstations. Nothing I have been able to find about TCP/IP and Named Pipes
would explain this behavior. This seems like some problem in network
communication, especially since the server was basically sitting idle.
I personally don't like "quick fixes". We run into this with just enough
regularity that it would be good to know what's really happening so we can
address the underlying problem.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> have
> the
>
|||Simply some facts top start with: Named Pipes is a OSI level 7 (Application)
protocol, WinSock is OSI level 5 (Session), therefore in a TCP only based
network, Named Pipes actually goes over WinSock, so it does not make any
sense that TCP Winsock is slower in that case, which is also not the
experience, and this is why we use TCP to perform client server benchmarks
for SQL Server. When running on the same machine, Named Pipes is faster then
TCP, because it becomes a Local Pipe call (this is where the magic . (dot)
notation is coming from).
Also since Named Pipes are file system objects at kernel level the
scalability compared to WinSock is much less, which is why if you need to
handle large number of connections you always have to use TCP sockets
instead of named pipes. Which each OS release thresholds move, like Andrew
said in Windows Server 2003, TCP sockets and DNS performance increase
dramatically. For example in NT 4.0 you would run out of file handles when
you would have more then 100-150 named pipes connections, this is not longer
a problem with Windows 2000 and Windows Server 2004, but this is to indicate
that each protocol have there own characteristics and scalability
thresholds.
In general the default choice is and should be TCP sockets for all remote
connections, if you are running on the same server like batch process you
might consider named pipes using a local pipe (using the . (dot) notation).
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> have
> the
>
|||Anti.virus program trying to AV check the named pipes stuff?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bob Castleman" <nomail@.here> wrote in message news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>A specific example of what we are running into happened this morning. A customer called complaining
>of speed problems. Everything was "fine" on Friday and today it was slow. CPU load on the database
>server was around 2%. Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
>Named Pipes and the time it took to load our application went from 20 seconds to 2 seconds. He
>reported a similar effect on the other workstations. Nothing I have been able to find about TCP/IP
>and Named Pipes would explain this behavior. This seems like some problem in network communication,
>especially since the server was basically sitting idle.
> I personally don't like "quick fixes". We run into this with just enough regularity that it would
> be good to know what's really happening so we can address the underlying problem.
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>
|||An other option we see often are a DNS name resolution problems, use tracert
to determine the route taken.
An other thought are these notebooks, that connect wireless as well, or at
home? In which case it most of the times helps to dump the DNS resolver
cache of the workstation. See IPCONFIG /flushdns
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2004 All rights reserved.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
> Anti.virus program trying to AV check the named pipes stuff?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>
|||"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
Don't know if this is your problem, but there was a bug a while ago in SQL
Server 2000 to do with the introduction of Kerberos aware authentication
using DBLibrary connections over TCP/IP.
IIRC, the SQL Client and SQL Server would not correctly negotiate packet
sizes. This could be circumvented by explicitly overriding the default
packet size in the client app. This was resolved in SQL Server SP2.
Kind Regards, Howard
|||Yes I have seen where issues with DNS have caused situations such as this as
well.
Andrew J. Kelly SQL MVP
"Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
> An other option we see often are a DNS name resolution problems, use
tracert
> to determine the route taken.
> An other thought are these notebooks, that connect wireless as well, or at
> home? In which case it most of the times helps to dump the DNS resolver
> cache of the workstation. See IPCONFIG /flushdns
> GertD@.SQLDev.Net
> Please reply only to the newsgroups.
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> You assume all risk for your use.
> Copyright SQLDev.Net 1991-2004 All rights reserved.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in[vbcol=seagreen]
> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
network[vbcol=seagreen]
enough[vbcol=seagreen]
than[vbcol=seagreen]
pipes.[vbcol=seagreen]
over[vbcol=seagreen]
clients[vbcol=seagreen]
it[vbcol=seagreen]
chatter[vbcol=seagreen]
sent[vbcol=seagreen]
We
>
|||Same here.
Basically if the DNS server is unavailable the client will wait for 20-30
seconds, and then resolve the servername in a different way.
You can do a quick check if this is the issue by connecting to the server
via both the IP-address and the servername. IP-address should behave
normally and the servername will have the 30 second delay.
Jacco Schalkwijk
SQL Server MVP
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
> Yes I have seen where issues with DNS have caused situations such as this
> as
> well.
> --
> Andrew J. Kelly SQL MVP
>
> "Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
> news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
> tracert
> rights.
> in
> network
> enough
> than
> pipes.
> over
> clients
> it
> chatter
> sent
> We
>
|||Thanks,
I'll try that.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid > wrote
in message news:uXQM9FQlEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Same here.
> Basically if the DNS server is unavailable the client will wait for 20-30
> seconds, and then resolve the servername in a different way.
> You can do a quick check if this is the issue by connecting to the server
> via both the IP-address and the servername. IP-address should behave
> normally and the servername will have the 30 second delay.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
>

Named pipes vs TCP/IP

Hi all.
We have a customer with some connection problems running Remote desctop
(Terminal server). In the startuplog of the SQL2000 server we can't find
anything else than:
2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
Pipes.
On our server we have the following started. What should we do to get the
server listening on the TCP/IP too? We think this could be the problem.
2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
Named Pipes.
Thanks all.
geirIs the IP netlib enabled (Server Network Utility)?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Geir Holme" <geir@.multicase.no> wrote in message news:u1OjFIJ5FHA.1032@.TK2MSFTNGP11.phx.gbl...
> Hi all.
> We have a customer with some connection problems running Remote desctop
> (Terminal server). In the startuplog of the SQL2000 server we can't find
> anything else than:
> 2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
> Pipes.
> On our server we have the following started. What should we do to get the
> server listening on the TCP/IP too? We think this could be the problem.
>
> 2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
> 2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
> 2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
> Named Pipes.
>
>
> Thanks all.
> geir
>

Named Pipes vs TCP/IP

Why would one choose Named Pipes over TCP/IP for the client net lib? We have
noticed for some of our customers that changing to named pipes speeds up the
response times of our application. But it is my understanding that a
properly configured LAN should work fine with TCP/IP.
Thanks,
Bob Castleman
SuccessWare SoftwareIt is my understanding that named pipes have slightly less overhead than
TCP/IP but there it is usually not enough to warrant using named pipes. TCP
is much more versatile and should be encouraged in general over named pipes.
One thing to note is that WIN2003 has a 25% higher throuput in TCP over
Win2000 and DNS lookups are up to 120% faster as well. If your clients are
looking for speed improvements and are not on Win2003 they should try it
out. Another thing to note is that usually when clients tell me one
protocol is faster than another I tend to find there is too much chatter
from the client to the server in the first place. The more packets sent
back and forth the more likely you will have performance issues under heavy
load.
--
Andrew J. Kelly SQL MVP
"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
> Thanks,
> Bob Castleman
> SuccessWare Software
>|||http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/optimsql/odp_tun_1a_7fcj.asp
Peter
"Status quo, you know, that is Latin for "the mess we're
in."
Ronald Reagan
>--Original Message--
>Why would one choose Named Pipes over TCP/IP for the
client net lib? We have
>noticed for some of our customers that changing to named
pipes speeds up the
>response times of our application. But it is my
understanding that a
>properly configured LAN should work fine with TCP/IP.
>Thanks,
>Bob Castleman
>SuccessWare Software
>
>.
>|||A specific example of what we are running into happened this morning. A
customer called complaining of speed problems. Everything was "fine" on
Friday and today it was slow. CPU load on the database server was around 2%.
Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
Named Pipes and the time it took to load our application went from 20
seconds to 2 seconds. He reported a similar effect on the other
workstations. Nothing I have been able to find about TCP/IP and Named Pipes
would explain this behavior. This seems like some problem in network
communication, especially since the server was basically sitting idle.
I personally don't like "quick fixes". We run into this with just enough
regularity that it would be good to know what's really happening so we can
address the underlying problem.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
> have
>> noticed for some of our customers that changing to named pipes speeds up
> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>|||Simply some facts top start with: Named Pipes is a OSI level 7 (Application)
protocol, WinSock is OSI level 5 (Session), therefore in a TCP only based
network, Named Pipes actually goes over WinSock, so it does not make any
sense that TCP Winsock is slower in that case, which is also not the
experience, and this is why we use TCP to perform client server benchmarks
for SQL Server. When running on the same machine, Named Pipes is faster then
TCP, because it becomes a Local Pipe call (this is where the magic . (dot)
notation is coming from).
Also since Named Pipes are file system objects at kernel level the
scalability compared to WinSock is much less, which is why if you need to
handle large number of connections you always have to use TCP sockets
instead of named pipes. Which each OS release thresholds move, like Andrew
said in Windows Server 2003, TCP sockets and DNS performance increase
dramatically. For example in NT 4.0 you would run out of file handles when
you would have more then 100-150 named pipes connections, this is not longer
a problem with Windows 2000 and Windows Server 2004, but this is to indicate
that each protocol have there own characteristics and scalability
thresholds.
In general the default choice is and should be TCP sockets for all remote
connections, if you are running on the same server like batch process you
might consider named pipes using a local pipe (using the . (dot) notation).
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> It is my understanding that named pipes have slightly less overhead than
> TCP/IP but there it is usually not enough to warrant using named pipes.
> TCP
> is much more versatile and should be encouraged in general over named
> pipes.
> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
> Win2000 and DNS lookups are up to 120% faster as well. If your clients
> are
> looking for speed improvements and are not on Win2003 they should try it
> out. Another thing to note is that usually when clients tell me one
> protocol is faster than another I tend to find there is too much chatter
> from the client to the server in the first place. The more packets sent
> back and forth the more likely you will have performance issues under
> heavy
> load.
> --
> Andrew J. Kelly SQL MVP
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
> have
>> noticed for some of our customers that changing to named pipes speeds up
> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>|||Anti.virus program trying to AV check the named pipes stuff?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bob Castleman" <nomail@.here> wrote in message news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>A specific example of what we are running into happened this morning. A customer called complaining
>of speed problems. Everything was "fine" on Friday and today it was slow. CPU load on the database
>server was around 2%. Disks weren't thrasing, etc. I had him change a workstation from TCP/IP to
>Named Pipes and the time it took to load our application went from 20 seconds to 2 seconds. He
>reported a similar effect on the other workstations. Nothing I have been able to find about TCP/IP
>and Named Pipes would explain this behavior. This seems like some problem in network communication,
>especially since the server was basically sitting idle.
> I personally don't like "quick fixes". We run into this with just enough regularity that it would
> be good to know what's really happening so we can address the underlying problem.
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> It is my understanding that named pipes have slightly less overhead than
>> TCP/IP but there it is usually not enough to warrant using named pipes. TCP
>> is much more versatile and should be encouraged in general over named pipes.
>> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
>> Win2000 and DNS lookups are up to 120% faster as well. If your clients are
>> looking for speed improvements and are not on Win2003 they should try it
>> out. Another thing to note is that usually when clients tell me one
>> protocol is faster than another I tend to find there is too much chatter
>> from the client to the server in the first place. The more packets sent
>> back and forth the more likely you will have performance issues under heavy
>> load.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Bob Castleman" <nomail@.here> wrote in message
>> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
>> have
>> noticed for some of our customers that changing to named pipes speeds up
>> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>>
>|||An other option we see often are a DNS name resolution problems, use tracert
to determine the route taken.
An other thought are these notebooks, that connect wireless as well, or at
home? In which case it most of the times helps to dump the DNS resolver
cache of the workstation. See IPCONFIG /flushdns
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2004 All rights reserved.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
> Anti.virus program trying to AV check the named pipes stuff?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>>A specific example of what we are running into happened this morning. A
>>customer called complaining of speed problems. Everything was "fine" on
>>Friday and today it was slow. CPU load on the database server was around
>>2%. Disks weren't thrasing, etc. I had him change a workstation from
>>TCP/IP to Named Pipes and the time it took to load our application went
>>from 20 seconds to 2 seconds. He reported a similar effect on the other
>>workstations. Nothing I have been able to find about TCP/IP and Named
>>Pipes would explain this behavior. This seems like some problem in network
>>communication, especially since the server was basically sitting idle.
>> I personally don't like "quick fixes". We run into this with just enough
>> regularity that it would be good to know what's really happening so we
>> can address the underlying problem.
>> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> It is my understanding that named pipes have slightly less overhead than
>> TCP/IP but there it is usually not enough to warrant using named pipes.
>> TCP
>> is much more versatile and should be encouraged in general over named
>> pipes.
>> One thing to note is that WIN2003 has a 25% higher throuput in TCP over
>> Win2000 and DNS lookups are up to 120% faster as well. If your clients
>> are
>> looking for speed improvements and are not on Win2003 they should try it
>> out. Another thing to note is that usually when clients tell me one
>> protocol is faster than another I tend to find there is too much chatter
>> from the client to the server in the first place. The more packets sent
>> back and forth the more likely you will have performance issues under
>> heavy
>> load.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Bob Castleman" <nomail@.here> wrote in message
>> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> Why would one choose Named Pipes over TCP/IP for the client net lib? We
>> have
>> noticed for some of our customers that changing to named pipes speeds
>> up
>> the
>> response times of our application. But it is my understanding that a
>> properly configured LAN should work fine with TCP/IP.
>> Thanks,
>> Bob Castleman
>> SuccessWare Software
>>
>>
>>
>|||"Bob Castleman" <nomail@.here> wrote in message
news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> Why would one choose Named Pipes over TCP/IP for the client net lib? We
have
> noticed for some of our customers that changing to named pipes speeds up
the
> response times of our application. But it is my understanding that a
> properly configured LAN should work fine with TCP/IP.
Don't know if this is your problem, but there was a bug a while ago in SQL
Server 2000 to do with the introduction of Kerberos aware authentication
using DBLibrary connections over TCP/IP.
IIRC, the SQL Client and SQL Server would not correctly negotiate packet
sizes. This could be circumvented by explicitly overriding the default
packet size in the client app. This was resolved in SQL Server SP2.
Kind Regards, Howard|||Yes I have seen where issues with DNS have caused situations such as this as
well.
--
Andrew J. Kelly SQL MVP
"Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
> An other option we see often are a DNS name resolution problems, use
tracert
> to determine the route taken.
> An other thought are these notebooks, that connect wireless as well, or at
> home? In which case it most of the times helps to dump the DNS resolver
> cache of the workstation. See IPCONFIG /flushdns
> GertD@.SQLDev.Net
> Please reply only to the newsgroups.
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> You assume all risk for your use.
> Copyright © SQLDev.Net 1991-2004 All rights reserved.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in
> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
> > Anti.virus program trying to AV check the named pipes stuff?
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > http://www.karaszi.com/sqlserver/default.asp
> > http://www.solidqualitylearning.com/
> >
> >
> > "Bob Castleman" <nomail@.here> wrote in message
> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
> >>A specific example of what we are running into happened this morning. A
> >>customer called complaining of speed problems. Everything was "fine" on
> >>Friday and today it was slow. CPU load on the database server was around
> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
> >>TCP/IP to Named Pipes and the time it took to load our application went
> >>from 20 seconds to 2 seconds. He reported a similar effect on the other
> >>workstations. Nothing I have been able to find about TCP/IP and Named
> >>Pipes would explain this behavior. This seems like some problem in
network
> >>communication, especially since the server was basically sitting idle.
> >>
> >> I personally don't like "quick fixes". We run into this with just
enough
> >> regularity that it would be good to know what's really happening so we
> >> can address the underlying problem.
> >>
> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
> >> It is my understanding that named pipes have slightly less overhead
than
> >> TCP/IP but there it is usually not enough to warrant using named
pipes.
> >> TCP
> >> is much more versatile and should be encouraged in general over named
> >> pipes.
> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
over
> >> Win2000 and DNS lookups are up to 120% faster as well. If your
clients
> >> are
> >> looking for speed improvements and are not on Win2003 they should try
it
> >> out. Another thing to note is that usually when clients tell me one
> >> protocol is faster than another I tend to find there is too much
chatter
> >> from the client to the server in the first place. The more packets
sent
> >> back and forth the more likely you will have performance issues under
> >> heavy
> >> load.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >>
> >> "Bob Castleman" <nomail@.here> wrote in message
> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
> >> Why would one choose Named Pipes over TCP/IP for the client net lib?
We
> >> have
> >> noticed for some of our customers that changing to named pipes speeds
> >> up
> >> the
> >> response times of our application. But it is my understanding that a
> >> properly configured LAN should work fine with TCP/IP.
> >>
> >> Thanks,
> >>
> >> Bob Castleman
> >> SuccessWare Software
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>|||Same here.
Basically if the DNS server is unavailable the client will wait for 20-30
seconds, and then resolve the servername in a different way.
You can do a quick check if this is the issue by connecting to the server
via both the IP-address and the servername. IP-address should behave
normally and the servername will have the 30 second delay.
--
Jacco Schalkwijk
SQL Server MVP
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
> Yes I have seen where issues with DNS have caused situations such as this
> as
> well.
> --
> Andrew J. Kelly SQL MVP
>
> "Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
> news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
>> An other option we see often are a DNS name resolution problems, use
> tracert
>> to determine the route taken.
>> An other thought are these notebooks, that connect wireless as well, or
>> at
>> home? In which case it most of the times helps to dump the DNS resolver
>> cache of the workstation. See IPCONFIG /flushdns
>> GertD@.SQLDev.Net
>> Please reply only to the newsgroups.
>> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>> You assume all risk for your use.
>> Copyright © SQLDev.Net 1991-2004 All rights reserved.
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in
>> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
>> > Anti.virus program trying to AV check the named pipes stuff?
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bob Castleman" <nomail@.here> wrote in message
>> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>> >>A specific example of what we are running into happened this morning. A
>> >>customer called complaining of speed problems. Everything was "fine" on
>> >>Friday and today it was slow. CPU load on the database server was
>> >>around
>> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
>> >>TCP/IP to Named Pipes and the time it took to load our application went
>> >>from 20 seconds to 2 seconds. He reported a similar effect on the other
>> >>workstations. Nothing I have been able to find about TCP/IP and Named
>> >>Pipes would explain this behavior. This seems like some problem in
> network
>> >>communication, especially since the server was basically sitting idle.
>> >>
>> >> I personally don't like "quick fixes". We run into this with just
> enough
>> >> regularity that it would be good to know what's really happening so we
>> >> can address the underlying problem.
>> >>
>> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> >> It is my understanding that named pipes have slightly less overhead
> than
>> >> TCP/IP but there it is usually not enough to warrant using named
> pipes.
>> >> TCP
>> >> is much more versatile and should be encouraged in general over named
>> >> pipes.
>> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
> over
>> >> Win2000 and DNS lookups are up to 120% faster as well. If your
> clients
>> >> are
>> >> looking for speed improvements and are not on Win2003 they should try
> it
>> >> out. Another thing to note is that usually when clients tell me one
>> >> protocol is faster than another I tend to find there is too much
> chatter
>> >> from the client to the server in the first place. The more packets
> sent
>> >> back and forth the more likely you will have performance issues under
>> >> heavy
>> >> load.
>> >>
>> >> --
>> >> Andrew J. Kelly SQL MVP
>> >>
>> >>
>> >> "Bob Castleman" <nomail@.here> wrote in message
>> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> >> Why would one choose Named Pipes over TCP/IP for the client net lib?
> We
>> >> have
>> >> noticed for some of our customers that changing to named pipes
>> >> speeds
>> >> up
>> >> the
>> >> response times of our application. But it is my understanding that a
>> >> properly configured LAN should work fine with TCP/IP.
>> >>
>> >> Thanks,
>> >>
>> >> Bob Castleman
>> >> SuccessWare Software
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>|||Thanks,
I'll try that.
"Jacco Schalkwijk" <jacco.please.reply@.to.newsgroups.mvps.org.invalid> wrote
in message news:uXQM9FQlEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Same here.
> Basically if the DNS server is unavailable the client will wait for 20-30
> seconds, and then resolve the servername in a different way.
> You can do a quick check if this is the issue by connecting to the server
> via both the IP-address and the servername. IP-address should behave
> normally and the servername will have the 30 second delay.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uD8FsIPlEHA.3356@.TK2MSFTNGP14.phx.gbl...
>> Yes I have seen where issues with DNS have caused situations such as this
>> as
>> well.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Gert E.R. Drapers" <GertD@.SQLDev.Net> wrote in message
>> news:e4O$dsOlEHA.3712@.TK2MSFTNGP15.phx.gbl...
>> An other option we see often are a DNS name resolution problems, use
>> tracert
>> to determine the route taken.
>> An other thought are these notebooks, that connect wireless as well, or
>> at
>> home? In which case it most of the times helps to dump the DNS resolver
>> cache of the workstation. See IPCONFIG /flushdns
>> GertD@.SQLDev.Net
>> Please reply only to the newsgroups.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> You assume all risk for your use.
>> Copyright © SQLDev.Net 1991-2004 All rights reserved.
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in
>> message news:e6n8opOlEHA.3372@.TK2MSFTNGP09.phx.gbl...
>> > Anti.virus program trying to AV check the named pipes stuff?
>> >
>> > --
>> > Tibor Karaszi, SQL Server MVP
>> > http://www.karaszi.com/sqlserver/default.asp
>> > http://www.solidqualitylearning.com/
>> >
>> >
>> > "Bob Castleman" <nomail@.here> wrote in message
>> > news:uZ2a5kOlEHA.3392@.TK2MSFTNGP14.phx.gbl...
>> >>A specific example of what we are running into happened this morning.
>> >>A
>> >>customer called complaining of speed problems. Everything was "fine"
>> >>on
>> >>Friday and today it was slow. CPU load on the database server was
>> >>around
>> >>2%. Disks weren't thrasing, etc. I had him change a workstation from
>> >>TCP/IP to Named Pipes and the time it took to load our application
>> >>went
>> >>from 20 seconds to 2 seconds. He reported a similar effect on the
>> >>other
>> >>workstations. Nothing I have been able to find about TCP/IP and Named
>> >>Pipes would explain this behavior. This seems like some problem in
>> network
>> >>communication, especially since the server was basically sitting idle.
>> >>
>> >> I personally don't like "quick fixes". We run into this with just
>> enough
>> >> regularity that it would be good to know what's really happening so
>> >> we
>> >> can address the underlying problem.
>> >>
>> >> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
>> >> news:ed0R4WOlEHA.2892@.tk2msftngp13.phx.gbl...
>> >> It is my understanding that named pipes have slightly less overhead
>> than
>> >> TCP/IP but there it is usually not enough to warrant using named
>> pipes.
>> >> TCP
>> >> is much more versatile and should be encouraged in general over
>> >> named
>> >> pipes.
>> >> One thing to note is that WIN2003 has a 25% higher throuput in TCP
>> over
>> >> Win2000 and DNS lookups are up to 120% faster as well. If your
>> clients
>> >> are
>> >> looking for speed improvements and are not on Win2003 they should
>> >> try
>> it
>> >> out. Another thing to note is that usually when clients tell me one
>> >> protocol is faster than another I tend to find there is too much
>> chatter
>> >> from the client to the server in the first place. The more packets
>> sent
>> >> back and forth the more likely you will have performance issues
>> >> under
>> >> heavy
>> >> load.
>> >>
>> >> --
>> >> Andrew J. Kelly SQL MVP
>> >>
>> >>
>> >> "Bob Castleman" <nomail@.here> wrote in message
>> >> news:OAh7NLOlEHA.324@.TK2MSFTNGP11.phx.gbl...
>> >> Why would one choose Named Pipes over TCP/IP for the client net
>> >> lib?
>> We
>> >> have
>> >> noticed for some of our customers that changing to named pipes
>> >> speeds
>> >> up
>> >> the
>> >> response times of our application. But it is my understanding that
>> >> a
>> >> properly configured LAN should work fine with TCP/IP.
>> >>
>> >> Thanks,
>> >>
>> >> Bob Castleman
>> >> SuccessWare Software
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>|||Bob,
Named-pipes is a "netbios" thing so it uses WINS (and LMHOSTS) to resolve
names.
TCP/IP Sockets uses DNS (and HOSTS).
Hence the reason DNS issues affect tcp-ip net-lib and not named-pipes net-lib.
(Even though both fundamentally run over tcp-ip. You can run named-pipes over
other protocols, but that's extremely rare these days)
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvforums/UK/default.asp?SRV=MSDevApps
(faqxxx.zip in lib 7)
or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faqsql

Named pipes vs TCP/IP

Hi all.
We have a customer with some connection problems running Remote desctop
(Terminal server). In the startuplog of the SQL2000 server we can't find
anything else than:
2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
Pipes.
On our server we have the following started. What should we do to get the
server listening on the TCP/IP too? We think this could be the problem.
2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
Named Pipes.
Thanks all.
geirIs the IP netlib enabled (Server Network Utility)?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Geir Holme" <geir@.multicase.no> wrote in message news:u1OjFIJ5FHA.1032@.TK2MSFTNGP11.phx.gbl
..
> Hi all.
> We have a customer with some connection problems running Remote desctop
> (Terminal server). In the startuplog of the SQL2000 server we can't find
> anything else than:
> 2005-10-26 07:28:49.95 server SQL server listening on Shared Memory, Named
> Pipes.
> On our server we have the following started. What should we do to get the
> server listening on the TCP/IP too? We think this could be the problem.
>
> 2005-10-24 12:10:06.71 server SQL server listening on 10.120.1.26: 1433.
> 2005-10-24 12:10:06.78 server SQL server listening on 127.0.0.1: 1433.
> 2005-10-24 12:10:07.67 server SQL server listening on TCP, Shared Memory,
> Named Pipes.
>
>
> Thanks all.
> geir
>

named pipes vs tcp

Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
enable in network libraries. I noticed in EM under current activity and
process info for some processes named pipes is used and for other processes
something called LPC is used. Is LPC aka TCP/IP? It looks like when the
"host" for the process is the server, then it uses LPC but when the "host" i
s
a workstation it uses named pipes. Does it use named pipes for the
workstations because it is listed first in the network libraries? Is named
pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
second or just remove named pipes?
Thanks,
--
Dan D.Hi Dan
"Dan D." wrote:

> Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
> enable in network libraries. I noticed in EM under current activity and
> process info for some processes named pipes is used and for other processe
s
> something called LPC is used. Is LPC aka TCP/IP? It looks like when the
> "host" for the process is the server, then it uses LPC but when the "host"
is
> a workstation it uses named pipes. Does it use named pipes for the
> workstations because it is listed first in the network libraries? Is named
> pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
> second or just remove named pipes?
> Thanks,
> --
> Dan D.
LPC is a shared memory connection, that is why the host is the server
itself. The protocol used will be order by they are listed on the client, if
you client had TCP as the first protocol to use and the server has TCP/IP
enabled then that would be used. TCP/IP was made the primary protocol in SP3
a
so you may want to check what versions you are using. To see the client
protocols installed use the Client Networking Utility (on the client) there
are buttons that will let you change the order, and to check the for server
protocols use the Server Networking Utility on the server.
As far as speed, I believe they can be about the same, but with names pipes
there are potential security issues as you are connecting directly through
the filesystem of the server.
As far as removing named pipes, it is your choice.
John|||I understand. Thanks.
--
Dan D.
"John Bell" wrote:

> Hi Dan
> "Dan D." wrote:
>
> LPC is a shared memory connection, that is why the host is the server
> itself. The protocol used will be order by they are listed on the client,
if
> you client had TCP as the first protocol to use and the server has TCP/IP
> enabled then that would be used. TCP/IP was made the primary protocol in S
P3a
> so you may want to check what versions you are using. To see the client
> protocols installed use the Client Networking Utility (on the client) ther
e
> are buttons that will let you change the order, and to check the for serve
r
> protocols use the Server Networking Utility on the server.
> As far as speed, I believe they can be about the same, but with names pipe
s
> there are potential security issues as you are connecting directly through
> the filesystem of the server.
> As far as removing named pipes, it is your choice.
> John|||"Dan D." wrote:

> I understand. Thanks.
> --
> Dan D.
That is one of us then! I didn't realise it read so badly!
John

Named Pipes vs TCP

How would one go about adjusting the default connection to the SQL Server on the client side, using either Named Pipes or TCP as the default?Look for the Client Network Utility tool in the SQL Server program group. Or start->run CliConfig.exe.|||any way to pull of the defaulting programmatically??|||Yes, but the mechanics vary a lot depending on how you are programming. The easiest/surest way is to use the NETWORK parameter within DSN-Less connection strings (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnodbc/html/odbcsql.asp).

-PatP|||Looks like the ticket, thanks for your assistance...

named pipes vs tcp

Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
enable in network libraries. I noticed in EM under current activity and
process info for some processes named pipes is used and for other processes
something called LPC is used. Is LPC aka TCP/IP? It looks like when the
"host" for the process is the server, then it uses LPC but when the "host" is
a workstation it uses named pipes. Does it use named pipes for the
workstations because it is listed first in the network libraries? Is named
pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
second or just remove named pipes?
Thanks,
Dan D.
Hi Dan
"Dan D." wrote:

> Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
> enable in network libraries. I noticed in EM under current activity and
> process info for some processes named pipes is used and for other processes
> something called LPC is used. Is LPC aka TCP/IP? It looks like when the
> "host" for the process is the server, then it uses LPC but when the "host" is
> a workstation it uses named pipes. Does it use named pipes for the
> workstations because it is listed first in the network libraries? Is named
> pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
> second or just remove named pipes?
> Thanks,
> --
> Dan D.
LPC is a shared memory connection, that is why the host is the server
itself. The protocol used will be order by they are listed on the client, if
you client had TCP as the first protocol to use and the server has TCP/IP
enabled then that would be used. TCP/IP was made the primary protocol in SP3a
so you may want to check what versions you are using. To see the client
protocols installed use the Client Networking Utility (on the client) there
are buttons that will let you change the order, and to check the for server
protocols use the Server Networking Utility on the server.
As far as speed, I believe they can be about the same, but with names pipes
there are potential security issues as you are connecting directly through
the filesystem of the server.
As far as removing named pipes, it is your choice.
John
|||I understand. Thanks.
Dan D.
"John Bell" wrote:

> Hi Dan
> "Dan D." wrote:
>
> LPC is a shared memory connection, that is why the host is the server
> itself. The protocol used will be order by they are listed on the client, if
> you client had TCP as the first protocol to use and the server has TCP/IP
> enabled then that would be used. TCP/IP was made the primary protocol in SP3a
> so you may want to check what versions you are using. To see the client
> protocols installed use the Client Networking Utility (on the client) there
> are buttons that will let you change the order, and to check the for server
> protocols use the Server Networking Utility on the server.
> As far as speed, I believe they can be about the same, but with names pipes
> there are potential security issues as you are connecting directly through
> the filesystem of the server.
> As far as removing named pipes, it is your choice.
> John
|||"Dan D." wrote:

> I understand. Thanks.
> --
> Dan D.
That is one of us then! I didn't realise it read so badly!
John

named pipes vs tcp

Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
enable in network libraries. I noticed in EM under current activity and
process info for some processes named pipes is used and for other processes
something called LPC is used. Is LPC aka TCP/IP? It looks like when the
"host" for the process is the server, then it uses LPC but when the "host" is
a workstation it uses named pipes. Does it use named pipes for the
workstations because it is listed first in the network libraries? Is named
pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
second or just remove named pipes?
Thanks,
--
Dan D.Hi Dan
"Dan D." wrote:
> Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
> enable in network libraries. I noticed in EM under current activity and
> process info for some processes named pipes is used and for other processes
> something called LPC is used. Is LPC aka TCP/IP? It looks like when the
> "host" for the process is the server, then it uses LPC but when the "host" is
> a workstation it uses named pipes. Does it use named pipes for the
> workstations because it is listed first in the network libraries? Is named
> pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
> second or just remove named pipes?
> Thanks,
> --
> Dan D.
LPC is a shared memory connection, that is why the host is the server
itself. The protocol used will be order by they are listed on the client, if
you client had TCP as the first protocol to use and the server has TCP/IP
enabled then that would be used. TCP/IP was made the primary protocol in SP3a
so you may want to check what versions you are using. To see the client
protocols installed use the Client Networking Utility (on the client) there
are buttons that will let you change the order, and to check the for server
protocols use the Server Networking Utility on the server.
As far as speed, I believe they can be about the same, but with names pipes
there are potential security issues as you are connecting directly through
the filesystem of the server.
As far as removing named pipes, it is your choice.
John|||I understand. Thanks.
--
Dan D.
"John Bell" wrote:
> Hi Dan
> "Dan D." wrote:
> > Using SS2000 SP4. We have both named pipes (it's listed first) and TCP/IP
> > enable in network libraries. I noticed in EM under current activity and
> > process info for some processes named pipes is used and for other processes
> > something called LPC is used. Is LPC aka TCP/IP? It looks like when the
> > "host" for the process is the server, then it uses LPC but when the "host" is
> > a workstation it uses named pipes. Does it use named pipes for the
> > workstations because it is listed first in the network libraries? Is named
> > pipes slower than using TCP/IP. Should I list TCP/IP first and named pipes
> > second or just remove named pipes?
> >
> > Thanks,
> > --
> > Dan D.
> LPC is a shared memory connection, that is why the host is the server
> itself. The protocol used will be order by they are listed on the client, if
> you client had TCP as the first protocol to use and the server has TCP/IP
> enabled then that would be used. TCP/IP was made the primary protocol in SP3a
> so you may want to check what versions you are using. To see the client
> protocols installed use the Client Networking Utility (on the client) there
> are buttons that will let you change the order, and to check the for server
> protocols use the Server Networking Utility on the server.
> As far as speed, I believe they can be about the same, but with names pipes
> there are potential security issues as you are connecting directly through
> the filesystem of the server.
> As far as removing named pipes, it is your choice.
> John|||"Dan D." wrote:
> I understand. Thanks.
> --
> Dan D.
That is one of us then! I didn't realise it read so badly!
Johnsql

named pipes versus tcpip

Is using the named pipes protocol more/less secure and/or
slower than using tcpip to connect to SQL server?
"Colleen Rossman" <anonymous@.discussions.microsoft.com> wrote in message
news:136401c4aba9$c7ef54b0$a601280a@.phx.gbl...
> Is using the named pipes protocol more/less secure and/or
> slower than using tcpip to connect to SQL server?
Named Pipes is equally secure (ie, vulerable to ethernet sniffing).
In two special cases Named Pipes is faster: on the same machine, and over
local-area networks using the NetBUI protocol. In other cases TCP/IP is
faster, since in those cases Named Pipes would be running _over_ TCP/IP.
Remember that all the client netlibs date from before TCP/IP took over the
world. Back then you would choose the netlib which matched your LAN's
network protocol. Well today every network runs on IP, so everyone uses the
TCP/IP netlib.
David

named pipes under alias

I have a SQLSERVER INSTANCE A, to which I want to connect from a Client as TEST, using the SQL Server alias functionality under the client network utility program. The alias is working fine with the TCP\IP connection but it fails when I try to connect to the SQL Server using the named pipes. In my case I'm trying to connect to a named instance of SQL Server 2000 using the following pipe: \\servername\pipe\mssql$instancename\sql\query

Any help?I have just tried this. Pain in the neck, too. When you change the name of the alias, the client network utility is all helpful, and changes the actual path, and server name. So you have to get the right path, and save it of in notepad or something. Change the name of the alias, replace the name of the server with the name of the server you want, then recover the path from notepad. I tried it, and it did not work. Then I hit the Apply button. Now it works. Does that approximate what you went through?|||I can connect to any server using the alias name with the TCP/IP, but the same doesn't work with the Named Pipes.

Named pipes question.

Is it possible to configure named pipes only on one NIC and tcpip on the
other' (SQL 2000 sp3)
PierreNot in SQL 2000. You cannot protocol 'affinitize' NIC's
(Hopefully in the next version)
"Pierre" <Pierre.roman@.qunara.com.nospam> wrote in message
news:%23E0dhpvqDHA.2632@.TK2MSFTNGP09.phx.gbl...
> Is it possible to configure named pipes only on one NIC and tcpip on the
> other' (SQL 2000 sp3)
> Pierre
>|||Thanks
"Dieter Katzenland" <deiter@.rrtc.com> wrote in message
news:uYNs2SwqDHA.2772@.TK2MSFTNGP12.phx.gbl...
> Not in SQL 2000. You cannot protocol 'affinitize' NIC's
> (Hopefully in the next version)
> "Pierre" <Pierre.roman@.qunara.com.nospam> wrote in message
> news:%23E0dhpvqDHA.2632@.TK2MSFTNGP09.phx.gbl...
> > Is it possible to configure named pipes only on one NIC and tcpip on the
> > other' (SQL 2000 sp3)
> >
> > Pierre
> >
> >
>|||Pierre,
Yes, but only with a (software) firewall.
Named pipes use SMB, TCP/IP uses port 1433 (default).
You cannot currently separate the protocols by any binding or SQL setup that I know of.
Regards
AJ
"Pierre" <Pierre.roman@.qunara.com.nospam> wrote in message news:%23E0dhpvqDHA.2632@.TK2MSFTNGP09.phx.gbl...
> Is it possible to configure named pipes only on one NIC and tcpip on the
> other' (SQL 2000 sp3)
> Pierre
>

Named Pipes Provider, error: 40 - Could not open a connection To SQL Server

I am trying to setup a notification service sample (from Joel Webb's book) for SQL server 2000 and notification service 2.0.

When i run nscontrol create at the cmd prompt, i am getting the following error:

Notification Services failed to retrieve the SQL Server edition.

SqlServerError:
Source: .Net SqlClient Data Provider
Number: 53
State: 0
Class: 20
Server:
Message: 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)
Procedure:
Line Number: 0

Any help on how this could be resolved would be really appreciated.

Thanks,

Nirmala

Hi Nirmala -

Thanks for buying the book. I hope you find it useful!

As for your issues, you may want to double check the name of the server and SQL Server instance to make sure they are correct. You may also want to verify that the server does indeed allow remote connections and that it is using named pipes as a communication protocol.

HTH...

Joe|||

I tried all the suggested things but unfortunately still seeing the same errors. Any more thoughts?

Thanks,

Nirmala

|||In the description of the problem you mention SQL Server 2000 and SSNS v2.0. However, in the actual error message it references SSNS 2005.

SSNS v2.0 was developed using version 1.1 of the .net framework and will only work with SQL Server 2000. SSNS 2005 was developed with v2.0 of the .net framework and is only available for use with SQL Server 2005.

Could it be that you have mismatched versions? And that is what is causing the problems you are seeing?

HTH...

Joe|||

Hi

I had a similar error in analysis project.

In my case I did not use the real servername as I had put an alias name for the server in my hosts file.

When I changed the server name in my datasource to reflect the real server name in stead of the alias name, I was able to deploy the project.

Regards

Per

Named Pipes Provider, error: 40 - Could not open a connection To SQL Server

I am trying to setup a notification service sample (from Joel Webb's book) for SQL server 2000 and notification service 2.0.

When i run nscontrol create at the cmd prompt, i am getting the following error:

Notification Services failed to retrieve the SQL Server edition.

SqlServerError:
Source: .Net SqlClient Data Provider
Number: 53
State: 0
Class: 20
Server:
Message: 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)
Procedure:
Line Number: 0

Any help on how this could be resolved would be really appreciated.

Thanks,

Nirmala

Hi Nirmala -

Thanks for buying the book. I hope you find it useful!

As for your issues, you may want to double check the name of the server and SQL Server instance to make sure they are correct. You may also want to verify that the server does indeed allow remote connections and that it is using named pipes as a communication protocol.

HTH...

Joe|||

I tried all the suggested things but unfortunately still seeing the same errors. Any more thoughts?

Thanks,

Nirmala

|||In the description of the problem you mention SQL Server 2000 and SSNS v2.0. However, in the actual error message it references SSNS 2005.

SSNS v2.0 was developed using version 1.1 of the .net framework and will only work with SQL Server 2000. SSNS 2005 was developed with v2.0 of the .net framework and is only available for use with SQL Server 2005.

Could it be that you have mismatched versions? And that is what is causing the problems you are seeing?

HTH...

Joe|||

Hi

I had a similar error in analysis project.

In my case I did not use the real servername as I had put an alias name for the server in my hosts file.

When I changed the server name in my datasource to reflect the real server name in stead of the alias name, I was able to deploy the project.

Regards

Per

Named Pipes Provider, error: 40 - Could not open a connection To SQL Server

I am trying to setup a notification service sample (from Joel Webb's book) for SQL server 2000 and notification service 2.0.

When i run nscontrol create at the cmd prompt, i am getting the following error:

Notification Services failed to retrieve the SQL Server edition.

SqlServerError:
Source: .Net SqlClient Data Provider
Number: 53
State: 0
Class: 20
Server:
Message: 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)
Procedure:
Line Number: 0

Any help on how this could be resolved would be really appreciated.

Thanks,

Nirmala

Hi Nirmala -

Thanks for buying the book. I hope you find it useful!

As for your issues, you may want to double check the name of the server and SQL Server instance to make sure they are correct. You may also want to verify that the server does indeed allow remote connections and that it is using named pipes as a communication protocol.

HTH...

Joe|||

I tried all the suggested things but unfortunately still seeing the same errors. Any more thoughts?

Thanks,

Nirmala

|||In the description of the problem you mention SQL Server 2000 and SSNS v2.0. However, in the actual error message it references SSNS 2005.

SSNS v2.0 was developed using version 1.1 of the .net framework and will only work with SQL Server 2000. SSNS 2005 was developed with v2.0 of the .net framework and is only available for use with SQL Server 2005.

Could it be that you have mismatched versions? And that is what is causing the problems you are seeing?

HTH...

Joe|||

Hi

I had a similar error in analysis project.

In my case I did not use the real servername as I had put an alias name for the server in my hosts file.

When I changed the server name in my datasource to reflect the real server name in stead of the alias name, I was able to deploy the project.

Regards

Per