SQL Server does not exist...

[Damien]

Hi Guys,

<Posted yesterday to microsoft.public.dotnet.framework.aspnet.security,
but no responses garnered. For mpsc readers, this is a fairly common
error encountered when connecting from ASP.Net 1.1, but I've followed
all the help I can find online and it hasn't fixed my problem yet. So
any ideas for troubleshooting would be welcomed>

Yet another person suffering from the infamous "SQL Server does not
exist or access is denied problem". I've looked through a fair bit of
the checklists, but none have resolved my problem as yet. Here's what
we're using:

Machine running ASP.Net is either a Window 2000 Pro or Windows XP Pro
box (tried both). The server is Windows 2003, running SQL Server 2000.

We have an ASP.Net 1.1 application that consists of a simple set of
pages/code behind and a separate DLL which performs the data
operations. The DLL knows how to find it's own connection string from
the registry (uses SQL Authentication, BTW)

If we add the data DLL to a Windows Forms application, it connects
fine, so we know that the connection string stored in the registry is
correct. We've also demonstrated that we can connect using Query
Analyzer, using the same username/password, both whilst running under a

domain users account, and whilst running under the local system
account.

This has led me to suspect it's "something" special to ASP.Net. We've
unregistered/reregistered ASP.Net using aspnet_regiis (also, bear in
mind that we get the same from both test machines). We've tried
switching ASP.Net from using the ASPNET account to using the SYSTEM
account. We've tried forcing the connection to use Named Pipes, or to
use TCP/IP (and we've verified that both protocols are enabled at both
client and server). We've tried adding an <impersonate> element into
web.config. None of these has changed the error message (other than it
taking longer to error when we forced tcp connection).

We've verified under all these circumstances that we don't even get a
login failure in profiler.

So, what I'm looking for is more ideas of where we should look?

Thanks in advance for any help,

Damien

 

[sloan]

I don't think there's anything "special" about dot net and the connection
string.

If you're using "nt authentication", then you need to be aware which account
asp_net uses.
Look under "Security / Users" in the Control Panel.

You can go here
http://www.connectionstrings.com/
and experiment with the different connection strings.

Keep in mind that ~every space and ";" is important. If you type in
"DataSource" instead of "Data Source", you'll screw yourself.
...

Also, if you aren't sure, you can research on how to use the IIdentity to
figure out who/which account you're actually using while in the dotnet
world.


I would say the most "Exact" connection string you can use is


The IP Address for the server name.
and use a sql authentication name/password pair. Use "sa" and "sapassword"
(whatever your sa password is) if you have access to it.
If not, make sure you create a new sql authentication username and try that.
CREATE A NEW ONE to make sure the "Login" (under management/security) is not
out of whack with the "(my)Database/Users".

My guess is that youre running under the asp.net account name, and you're
trying to use trusted security. And they aren't synced up.
But that's a guess.

 

[bruce barker \(sqlwork.com\)]

on the 2003 server, set the identity of the app pool to a domain account
with acces to the database. then be sure in the web config impersonate is
false.

-- bruce (sqlwork.com)

 

[Arnie Rowland]

Contrary to this advise, it is a very bad decision to use the [sa] account
for web access to a database. It should 'never' be done!

--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc

Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous

 

[sloan]

I meant try this as a test, not a permanent setting.

Naturally, after getting sa working, you want to drill down the security
model to a more specific one.

Contrary to this advise, it is a very bad decision to use the [sa] account
for web access to a database. It should 'never' be done!

--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc

Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous

...
and use a sql authentication name/password pair. Use "sa" and
"sapassword"
(whatever your sa password is) if you have access to it.

 

[Arnie Rowland]

Still bad advice, since many folks will use it, find it works, and then
never change it.

--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc

Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous

I meant try this as a test, not a permanent setting.

Naturally, after getting sa working, you want to drill down the security
model to a more specific one.

Contrary to this advise, it is a very bad decision to use the [sa]
account
for web access to a database. It should 'never' be done!

--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc

Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous

...
and use a sql authentication name/password pair. Use "sa" and
"sapassword"
(whatever your sa password is) if you have access to it.

 

[Damien]

Still bad advice, since many folks will use it, find it works, and then
never change it.

--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc

Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous

When I first joined my present company, the enterprise wide windows
application was using sa and a blank password. I still shudder to think
of it (and the day I set a password and broke several smaller apps)

Why do I always forget to include some relevant information in my posts
though? We're using sql authentication already, not intergrated
security, so I'm thinking it cannot be a user issue (since we can
connect using this user when in a windows forms app)

I have subsequently used netcap and Network Monitor, and I am seeing
what looks like traffic between the two machines, but I'm still seeing
nothing in profiler. (I'm worried we might not have shutdown everything
that might be doing SQL work between the two machines, but I'm
definitely seeing SQL Traffic (connections to port 1433))

Where do I look next?

Damien

 

[Frank Lehmann]

Hi Damien,

Do you get this error while trying to connect or later on,
especially while running in a loop?