views:

56

answers:

2

Hi,

First off, I can connect to both databases with SQL Server Enterprise Manager, so I know the servers are up and available. One of them is SQL1, the other is SQLTEST.

In my program when I use the following connection string, it work connects just fine:

conn = New DBConnect("Data Source=SQL1;Initial Catalog=SignInspection;Integrated Security=SSPI")

However, if I change SQL1 to SQLTEST the connection times out I don't get any errors other than the timeout error.

I can run the profiler on SQLTest and see that it is most definitely NOT even attempting to connect. Nothing happens at all, not a peep, nor hellow.

Any ideas? Thanks

EDIT:

Well, it's a moot point now because I got authentication working properly on our SQL1 server.

I'll post the configuration here so perhaps someone else can benefit.

First off, the web server is running IIS and .NET. Users are logged in to the intranet using Active Directory, and the .NET page needs to retrieve their log-in credentials (username most notably). The database is SQL Server 2005, running on a different machine. But the .NET app needs to impersonate as another user to connect to the database.

To successfully do both of these things go to Windows > Run, enter inetmgr and hit run. Navigate to the site and right click > properties, then click on the tab titled Directory Security, click Edit.., make sure only Integrated Windows Authentication and Digest authentication are enabled. Enter your proper AD realm and click OK. Apply the settings/hit OK.

In web.config you need the following lines

<authentication mode="Windows" />
<identity impersonate="true" username="myDomain\MyUserName" password="123mypasswordgoeshere">

replacing, of course, myDomain\MyUserName and 123mypasswordgoeshere with the username and password that has login rights on both your domain and your sql server. The connection string can probably be modified, but this is mine and it works:

Server=SQL1;Database=SignInspection;Trusted_connection=True;

These are the steps that worked for me and hopefully they'll be of use to someone else.

A: 

When you connected with the enterprise manager, was that from the same machine as you're running the VB.Net code on?

Otherwise, it can be quite a few things, ranging from firewall or DNS as mdma mentions to being setup with the wrong network protocol or maybe not accepting remote connections.

This article contains a list of things to look at (it's for SQL 2000 but it's something to get you started at least).

ho1
Yeah, the manager and my code are running from the same box.
Wayne Werner
I suppose technically speaking this didn't really solve my problem, but it's the most useful answer (so far), contains a helpful link, and since my problem is no longer relevant, I'll be accepting this answer.
Wayne Werner
@Wayne: Thanks, but if you solved the problem yourself you could always post an answer to your own question and mark that as the answer (I don't think you'd get any rep for it though but at least the question would be properly answered).
ho1
I thought about that, but my success has nothing to do with my original question (connecting to that particular server)... I figured that since yours actually pertains to the original question, it would be a better choice.
Wayne Werner
A: 

The obvious question - does SQLTEST have a database called "SignInspection"? Also do you log on to SQLTEST via SQL Management Studio using Windows Authentication or SQL Authentication? I would expect if either of these were the problem you would get an exception, but its worth checking.

Ben
Yes both have that database, and Windows authentication. When I connect (to either) via the manager I can run queries, etc.
Wayne Werner