|
|
You're in the
sql server connect
group:SQL Server does not exist...
sql server connect:
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
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) [quoted text, click to view] "Damien" <Damien_The_Unbeliever@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 >
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 [quoted text, click to view] "sloan" <sloan@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.
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 [quoted text, click to view] "sloan" <sloan@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" <arnie@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" <sloan@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. >> >> > >
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. [quoted text, click to view] "Damien" <Damien_The_Unbeliever@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 >
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. [quoted text, click to view] "Arnie Rowland" <arnie@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" <sloan@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. > >
[quoted text, click to view]
Arnie Rowland wrote: When I first joined my present company, the enterprise wide windows> 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 > 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
Hi Damien,
Do you get this error while trying to connect or later on, especially while running in a loop? ------- Frank
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |