sql server connect: I've been having trouble connecting to a 2nd instance of a SQL Server 2k
with some VB.NET code from my WinXP Prof workstation.

"System.Data.SqlClient.SqlException: Specified SQL server not found: my
server"

My application connects just fine from a Win2k machine with a like Client
Network Utility setup. I think I'm finding that my developer workstation is
having problems with SQL connectivity in general. I'm getting somewhat
random "cannot generate SSPI context" errors from my client database tools,
but they're not occurring at the same time as my failing VB.NET code. In
fact, right now, I'm only having problems with my VB.NET app.

Thoughts?

_____
DC G

To connect to a 2nd instance or Named Instance the connection string has to
include the ServerName\Instance or Servername,port in the connection string.

Example: SQL Server name is BigSQL
Instance Name is Accounting.
The connection would have to be to BigSQL\Accounting Or if you know the
port the instance is listening on, by default it is random. Say it's
listening on 2200, the connection string could be BigSQL,2200


If you're failing consistently with SSPI Errors ;

There is one easy solution...You can configure your client to connect via
Named Pipes. Named Pipes connections don't need to call the SSPI API in
order to impersonate the client. TCP sockets connections must call SSPI to
make Trusted Connections.

If you can't /don't want to do this then it will take some more digging to
find out why the connections are failing. To be clear, this problem has
nothing to do with SQL Server, but the interaction with Active Directory ,
your DC and DNS servers.

1. SPN is registered for this server in AD, but there is something wrong
with the SPN. (You'll need to have the domain admin dump all the SPN's for
the user objects and computer objects) Search for duplicate entries of
your SQL HOST name. Duplicate SPN's are also reported on the DC. The
problem is , it doesn't tell you which account is duplicated...

2. DNS name resolution problems at this client. (Use Netdiag.exe to test
both DC and DNS issues) DNS is critical to this connection succeeding.

3. DC communication problems. In order to successfully connect using
Integrated security over TCP, you need to be able to setup a session to the
DC, and get a TGS for the Server. If this communication fails, we're
unable to provide the credentials, and pass "Null".

4. Make a network trace from the client machine that fails with this error.
If you are comfortable reading network traces, you should be able to
identify where the communication is breaking down.

If none of these help, or if you feel this is over your head, open up a
case with SQL and request a Data Services engineer.


Thanks,

Kevin McDonnell
Microsoft Corporation

This posting is provided AS IS with no warranties, and confers no rights.