SQL Server does not exist...

6 Sep 2006 2:03 PM

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

6 Sep 2006 3:10 PM

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.

Show quoteHide quote

"Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message
news:1157551424.314651.280210@i3g2000cwc.googlegroups.com...
> 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
>

6 Sep 2006 3:38 PM

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

Show quoteHide quote

"sloan" <sl***@ipass.net> wrote in message
news:uh8hQbc0GHA.1300@TK2MSFTNGP05.phx.gbl...
>
....
> and use a sql authentication name/password pair. Use "sa" and
> "sapassword"
> (whatever your sa password is) if you have access to it.

6 Sep 2006 3:47 PM

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.

Show quoteHide quote

"Arnie Rowland" <ar***@1568.com> wrote in message
news:%23H$C7pc0GHA.4408@TK2MSFTNGP05.phx.gbl...
> 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" <sl***@ipass.net> wrote in message
> news:uh8hQbc0GHA.1300@TK2MSFTNGP05.phx.gbl...
> >
> ...
> > and use a sql authentication name/password pair. Use "sa" and
> > "sapassword"
> > (whatever your sa password is) if you have access to it.
>
>

6 Sep 2006 3:56 PM

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

Show quoteHide quote

"sloan" <sl***@ipass.net> wrote in message
news:%230sqKwc0GHA.4016@TK2MSFTNGP02.phx.gbl...
>
> 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.
>
>
>
>
> "Arnie Rowland" <ar***@1568.com> wrote in message
> news:%23H$C7pc0GHA.4408@TK2MSFTNGP05.phx.gbl...
>> 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" <sl***@ipass.net> wrote in message
>> news:uh8hQbc0GHA.1300@TK2MSFTNGP05.phx.gbl...
>> >
>> ...
>> > and use a sql authentication name/password pair. Use "sa" and
>> > "sapassword"
>> > (whatever your sa password is) if you have access to it.
>>
>>
>
>

7 Sep 2006 8:23 AM

Damien

Arnie Rowland wrote:

> 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

6 Sep 2006 3:16 PM

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)

Show quoteHide quote

"Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message
news:1157551424.314651.280210@i3g2000cwc.googlegroups.com...
> 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
>