Yeah, I already read this. What has me flustered is the fact that I suddenly have no choice in the matter. I will do some more investigating and see what I come up with.

I have had this db up and running for several years without a hicup. My problem is that it is on a production server. So I must tread softly...

Thanks


Named Pipes vs. TCP/IP Sockets

In a fast local area network (LAN) environment, Transmission Control
Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are
comparable in terms of performance. However, the performance difference
between the TCP/IP Sockets and Named Pipes clients becomes apparent with
slower networks, such as across wide area networks (WANs) or dial-up
networks. This is because of the different ways the interprocess
communication (IPC) mechanisms communicate between peers.

For named pipes, network communications are typically more interactive. A
peer does not send data until another peer asks for it using a read command.
A network read typically involves a series of peek named pipes messages
before it begins to read the data. These can be very costly in a slow
network and cause excessive network traffic, which in turn affects other
network clients.

It is also important to clarify if you are talking about local pipes or
network pipes. If the server application is running locally on the computer
running an instance of MicrosoftR SQL ServerT 2000, the local Named Pipes
protocol is an option. Local named pipes runs in kernel mode and is
extremely fast.

For TCP/IP Sockets, data transmissions are more streamlined and have less
overhead. Data transmissions can also take advantage of TCP/IP Sockets
performance enhancement mechanisms such as windowing, delayed
acknowledgements, and so on, which can be very beneficial in a slow network.
Depending on the type of applications, such performance differences can be
significant.

TCP/IP Sockets also support a backlog queue, which can provide a limited
smoothing effect compared to named pipes that may lead to pipe busy errors
when you are attempting to connect to SQL Server.

In general, sockets are preferred in a slow LAN, WAN, or dial-up network,
whereas named pipes can be a better choice when network speed is not the
issue, as it offers more functionality, ease of use, and configuration
options.
------------------------------------------------------------

No, that's not mine... but maybe it'll help.


 -----Original Message-----
 From: Web Dude [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, August 12, 2003 1:21 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Witango-Talk: MSQL Help (OT maybe)


Not sure, however, I found this in the on-line books....


 Note When connecting to a SQL Server running on Windows NT using
 Named Pipes, the user must have permission to connect to the Windows
 NT Named Pipes IPC, \\<computername>\IPC$. If the user does not have
 permission to connect, it is not possible to connect to SQL Server
 using Named Pipes unless either the Windows NT guest account on the
 computer is enabled (disabled by default), or the permission "access
 this computer from the network" is granted to everyone.

 Well I did not touch anything, however, I do not grant permission for
 everyone to access this computer from the network nor do I have any
 guest account enabled.  So how in the heck was this running on named
 pipes in the first place. According to the on-line books, it should
 not have been possible.  Wait a minute (brain fart). If I read this
 closely, it says "If the user does not have permission to connect"
 they can't "unless" there is a guest account or access this computer
 from the network yada yada.

 So how come do my users suddenly not have permission via named pipe?
 And if that is the case, how do I change the permissions back. I am
 all over SQL and can't find where named pipe permissions are changed.
 I did not even know that you can have separate permissions via TCP/IP
> or named pipes.

And which is better anyway? I ran in multi for quite a while ago and I remember changing it to named pipes, but don't remember why...

I appreciate any feedback here.

Thanks!!!!





 >did the patch close ports needed to connect to you db server on
 machine 2?
 >
 >>1st machine
 >>Windows 2000 server
 >>IIS 5
 >>Tango 2000
 >>all patches, sps and fixes
 >>
 >>2nd machine
 >>Windows 2000 server
 >>MSQL 7
 >>all patches, sps and fixes
 >>
 >>Something strange just happened to me. I applied the latest critical
 >>update to 2nd machine and rebooted. Suddenly all db queries resulted
 >>in "named pipes access denied". I changes the client configuration in
 >>MSQL to TCP/IP connections and switched client configuration in ODBC
 >>on 1st machine to the same. Now it works, but the client configuation
 >>on 2nd machine shows named pipes as the default and 1st machine shows
 >>TCP/IP for odbc.
 >>
 >>What gives? Any help appreciated as this is on a production machine.
 >>
 >>Which is the better connection anyway, I remember this discussion in
 >>the past but would like to get it right.
 >>
 >>Thanks
 >>
 >>--
 >>________________________________________________________________________
 >>TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
 >>
 >
 >
 >Bill Conlon
 >
 >To the Point
 >345 California Avenue Suite 2
 >Palo Alto, CA 94306
 >
 >office: 650.327.2175
 >fax:    650.329.8335
 >mobile: 650.906.9929
 >e-mail: mailto:[EMAIL PROTECTED]
 >web:    http://www.tothept.com
 >
 >
 >________________________________________________________________________
 >TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf


-- ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf


________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf


--
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf

Reply via email to