Very Computer

Has anyone else had this experience?  Is this a known problem?  Is
there a workaround?  Should I just modify the application to use
TCP/IP?

Any input would be appreciated.

Thanks!
Brad.

Quote:> We are experiencing a strange connection problem.  We are using VB
> with ADO to make our connections to SQL Server.  We are not specifying
> the "network library", so I assume it is defaulting to using "named
> pipes".  Occasionally after rebooting, the client cannot connect to
> the SQL Server.  What we do in such a circumstance is temporarily
> create an ODBC DSN, point it to the server in question, select
> "TCP/IP" as the network library, and hit "Test Data Source".  We don't
> keep or use the DSN, but it's as if we have to "punch through" the
> connection the first time.  This seems to resolve the problem, and
> from then on the application connects just fine using named pipes (at
> least until the next reboot).

> Has anyone else had this experience?  Is this a known problem?  Is
> there a workaround?  Should I just modify the application to use
> TCP/IP?

> Any input would be appreciated.

> Thanks!
> Brad.

In addition to Neil's post:
Named Pipes need to be authenticated through NT's IPC$ before SQL Server
even knows about the attempt. When you do TCP/IP, SQL Server will be
notified and then calls NT (for NT authentication). This might explain why
the following NP attempts are successful (the IP stuff gave the client an
IPC$ authentication.... _somehow_...).

This sometimes happens over DUN, and if you come from some other domain (as
I recall it), especially over W9x. One way to handle it is to use a mapped
drive (which then ensures you that NT has performed some kind of
authentication first).

Above doesn't really offer any solution to your problem, but it might make
it more understandable :-).
--
Tibor Karaszi
MCDBA, MCSE, MCSD, MCT, SQL Server MVP
Cornerstone Sweden AB
Please reply to the newsgroup only, not by email.

Quote:> We are experiencing a strange connection problem.  We are using VB
> with ADO to make our connections to SQL Server.  We are not specifying
> the "network library", so I assume it is defaulting to using "named
> pipes".  Occasionally after rebooting, the client cannot connect to
> the SQL Server.  What we do in such a circumstance is temporarily
> create an ODBC DSN, point it to the server in question, select
> "TCP/IP" as the network library, and hit "Test Data Source".  We don't
> keep or use the DSN, but it's as if we have to "punch through" the
> connection the first time.  This seems to resolve the problem, and
> from then on the application connects just fine using named pipes (at
> least until the next reboot).

> Has anyone else had this experience?  Is this a known problem?  Is
> there a workaround?  Should I just modify the application to use
> TCP/IP?

> Any input would be appreciated.

> Thanks!
> Brad.