Connection issues with ADO

Hello,

I distribute an app to various folks that allows them to connect to
various SQL Servers.  I have no control over what version of ADO they
have installed, but it's version 2.5 or higher.

With ADO 2.5 the default connection protocol was named pipes.  With ADO
2.6, they've changed the default to TCP/IP.

When users try to connect using ADO 2.5, sometimes the connection fails
for varoius reasons: the user is not on the domain and the server they
are connecting to is or they are connecting across non-trusted domains
and so forth.

So my questions are as follows:

1.  Will it have any repercussions if I force the connection to TCP/IP,
by appending "Network Library=dbmssocn" to the connection string?  Will
I still be able to connect to the local machine regardless of ADO version?

2.  Named pipes work fine as long as you are authenticated on the
domain.  Is this a correct assumption?

3.  I can always use Named Pipes to connect to my local sql server.  Is
this correct?

4.  What about if the user's PC and the SQL Server are in the same
workgroup.  Will named pipes still work?

Thanks

On Sat, 28 May 2005 10:58:40 -0700, Frank Rizzo <nospam@nospam.com>
wrote:
in <eq5kf66YFHA.3096@TK2MSFTNGP15.phx.gbl>

>Hello,
>
>I distribute an app to various folks that allows them to connect to
>various SQL Servers.  I have no control over what version of ADO they
>have installed, but it's version 2.5 or higher.
>
>With ADO 2.5 the default connection protocol was named pipes.  With ADO
>2.6, they've changed the default to TCP/IP.
>
>When users try to connect using ADO 2.5, sometimes the connection fails
>for varoius reasons: the user is not on the domain and the server they
>are connecting to is or they are connecting across non-trusted domains
>and so forth.
>
>So my questions are as follows:
>
>1.  Will it have any repercussions if I force the connection to TCP/IP,
>by appending "Network Library=dbmssocn" to the connection string?  Will
>I still be able to connect to the local machine regardless of ADO version?
>
>2.  Named pipes work fine as long as you are authenticated on the
>domain.  Is this a correct assumption?
>
>3.  I can always use Named Pipes to connect to my local sql server.  Is
>this correct?
>
>4.  What about if the user's PC and the SQL Server are in the same
>workgroup.  Will named pipes still work?
>
>Thanks

Named pipes will not work with any 9x based system, so your assertions
are correct if all clients/servers are NT based systems.  You could
always ~encourage~ your clients to upgrade to MDAC 2.8 the way MS
~encourages~ upgrades.  Use your imagination here.


---
Stefan Berglund

SQL Server has to be set up with the appropriate libraries for NamedPipes or
you will not be able to connect. For example, on several of my servers, I
use only TCP/IP.

"Frank Rizzo" <nospam@nospam.com> wrote in message
news:eq5kf66YFHA.3096@TK2MSFTNGP15.phx.gbl...
> Hello,
>
> I distribute an app to various folks that allows them to connect to
> various SQL Servers.  I have no control over what version of ADO they have
> installed, but it's version 2.5 or higher.
>
> With ADO 2.5 the default connection protocol was named pipes.  With ADO
> 2.6, they've changed the default to TCP/IP.
>
> When users try to connect using ADO 2.5, sometimes the connection fails
> for varoius reasons: the user is not on the domain and the server they are
> connecting to is or they are connecting across non-trusted domains and so
> forth.
>
> So my questions are as follows:
>
> 1.  Will it have any repercussions if I force the connection to TCP/IP, by
> appending "Network Library=dbmssocn" to the connection string?  Will I
> still be able to connect to the local machine regardless of ADO version?
>
> 2.  Named pipes work fine as long as you are authenticated on the domain.
> Is this a correct assumption?
>
> 3.  I can always use Named Pipes to connect to my local sql server.  Is
> this correct?
>
> 4.  What about if the user's PC and the SQL Server are in the same
> workgroup.  Will named pipes still work?
>
> Thanks

"Stefan Berglund" <keepit@in.thegroups> wrote in message
 news:7cfh91dus5qpan58ij9ratsthudrhn48mc@
4ax.com...

> Named pipes will not work with any 9x based system

I question that statement. Do you have something to back it up?

On Sun, 29 May 2005 22:12:43 -0400, "Jeff Johnson [MVP: VB]"
<i.get@enough.spam> wrote:
in <#09cczLZFHA.796@TK2MSFTNGP10.phx.gbl>

>
>"Stefan Berglund" <keepit@in.thegroups> wrote in message
> news:7cfh91dus5qpan58ij9ratsthudrhn48mc@
4ax.com...
> 
>
>I question that statement. Do you have something to back it up?
>
Well, I guess you're right.  Apparently I erroneously concluded that
because the CreateNamedPipe API isn't available on 9x systems but I see
that most of the other pipe APIs are:

mk:@MSITStore:G:\MSDN\ipc.chm::/hh/winbase/pipes_0tmb.htm

So I'll say that you can't create a named pipe on a 9x system but
apparently you can read/write it.

Thanks for the correction although I'm still thinking I decided against
pipes for this very reason, but I sure as hell can't find it now.  <g>


---
Stefan Berglund

"Stefan Berglund" <keepit@in.thegroups> wrote in message
 news:e7vk91ha544hairpd3hea50inqukfu4vfc@
4ax.com...
 
> Well, I guess you're right.  Apparently I erroneously concluded that
> because the CreateNamedPipe API isn't available on 9x systems but I see
> that most of the other pipe APIs are:
>
> mk:@MSITStore:G:\MSDN\ipc.chm::/hh/winbase/pipes_0tmb.htm
>
> So I'll say that you can't create a named pipe on a 9x system but
> apparently you can read/write it.
>
> Thanks for the correction although I'm still thinking I decided against
> pipes for this very reason, but I sure as hell can't find it now.  <g>

I believe the only pipe 9x systems can "create" is the "anonymous" pipe,
i.e., the named pipe with no name....