> I have tried some days now to communicate with a mssql server
> with named pipes instead of tcp/ip.

> It was when I had disabled the tcp/ip on the sql server and only had
> named pipes enabled when I saw that my apps couldnt communicate with it
> anymore.

> I have dropped the following database components on the form:

> TDatabase
> TQuery
> TSession

> The three components are connected through the SessionName property.

> What to do? I have tried to put things in the Params property of the
> TDatabase control in a thousand of ways by now...

> Best regards
> /Anders

>> I have tried some days now to communicate with a mssql server
>> with named pipes instead of tcp/ip.

>> It was when I had disabled the tcp/ip on the sql server and only had
>> named pipes enabled when I saw that my apps couldnt communicate with
>> it anymore.

>> I have dropped the following database components on the form:

>> TDatabase
>> TQuery
>> TSession

>> The three components are connected through the SessionName property.

>> What to do? I have tried to put things in the Params property of the
>> TDatabase control in a thousand of ways by now...

>> Best regards
>> /Anders

> I have tried some days now to communicate with a mssql server
> with named pipes instead of tcp/ip.

> It was when I had disabled the tcp/ip on the sql server and only had
> named pipes enabled when I saw that my apps couldnt communicate with it
> anymore.

> I have dropped the following database components on the form:

> TDatabase
> TQuery
> TSession

> The three components are connected through the SessionName property.

> What to do? I have tried to put things in the Params property of the
> TDatabase control in a thousand of ways by now...

> Best regards
> /Anders

>   If you set Microsoft's Client Network Utility to use Named Pipes,
>   then
>that is what your using.  There is nothing to set in your code (this is
>not a Delphi/VCL issue).  Just curious, why Named Pipes?  TCP/IP is much
>faster (in our tests, but mileage may vary)

>Good luck,
>krf

>Anders Linden <no_spam_to_anders.lin...@perceptive.se> wrote in message
>news:90EF80682anderslindenpercepti@207.105.83.65...
>> tr...@kc.rr.com (Travis L. Reno) wrote in <3b6697fa_1@dnews>:

> Isnt there a setting in my application to override the settings in the
> Microsoft's Client Network Utility?

>Anders Linden <no_spam_to_anders.lin...@perceptive.se> wrote in message
>news:90F054897anderslindenpercepti@207.105.83.65...
>> The question is... shouldnt it be up to the application what transport
>> it uses? Is the settings that I set in microsoft client network
>> utitlity affecting ado too? And how can tcp/ip be faster than named
>> pipes?

>I hope not, I have enough things to worry about :).  I believe so, but
>someone who is an ADO expert might better answer that question.  Like I
>wrote, your mileage may vary, but all the docs I've read (sorry, I don't
>have any links off the top of my head), Named Pipes is a huge network
>hog and the cause for a lot of network related bottlenecks.  Ok for a
>small network, but for large, dispersed network, TCP/IP is the best
>choice.

>During our tests we had 70 plus employees doing a number of different
>tasks and performance was so bad, the apps (Delphi apps and M$'s native
>tools) were almost unusable.  Switched to TCP/IP and queries that took
>2-3 minutes now are instantaneous.

>> When I have looked at the api, it seems like a named pipe only allows
>> a client a time and queues the rest. It is a single-cpu system, so I
>> think thats the best way to use the cycles. If a processor only has
>> one thing at a time to do, it will not switch between tasks, right?

>How do you "use the cycles"?

>> And if a named pipe is on the same computer as the one you are
>> connecting from, you will not use the netbios protocol either.

>> Isnt there a setting in my application to override the settings in the
>> Microsoft's Client Network Utility?

>I'm sure all the utility is doing is setting some registry settings, so
>might do some looking around.  Just curious, why?

> I think it is the best for the cpu to not do more than one thing at the
> same time, if possible. queues just _have_ to speed up the cpu, because it
> doesnt have to switch between tasks all the time.

>krf

>Of course, this is getting way outside the bounds of any
>Borland/Delphi/VCL issue (you might get better answers on M$
>newsgroups).

>Good luck,
>krf

>Anders Linden <no_spam_to_anders.lin...@perceptive.se> wrote in message
>news:90F1AB3D1anderslindenpercepti@207.105.83.65...
>> Putting the responsibility on the application instead of the system
>whether
>> to use named pipes or tcp/ip is hardly an attempt to write a protocol
>> of any kind.

> (Regardless of the settings in the "client network utility").

> Hope I was expressing myself better this time :)

> /Anders

> kfrev...@midwayusa.com (Kevin Frevert) wrote in <3b696b47_2@dnews>:

> >Then I'm confused.  You wrote you want to manipulate the network
> >protocol, but you don't want to modify the registry.  The only other way
> >I know is to write your own protocol (I'm sure there are the C headers
> >somewhere you could use).

> >Of course, this is getting way outside the bounds of any
> >Borland/Delphi/VCL issue (you might get better answers on M$
> >newsgroups).

> >Good luck,
> >krf

> >Anders Linden <no_spam_to_anders.lin...@perceptive.se> wrote in message
> >news:90F1AB3D1anderslindenpercepti@207.105.83.65...
> >> Putting the responsibility on the application instead of the system
> >whether
> >> to use named pipes or tcp/ip is hardly an attempt to write a protocol
> >> of any kind.