I'm migrating an IIS/SQL-Server application from Windows NT4.0 and SQL-
Server 2000 to Windows 2003 Server and SQL-Server 2005.
My problem is that it is not possible to connect local (IIS and SQL-
Server 2005 are runnng on the same node) using ODBC. Running the
applikation on a remote IIS (XPPro) all works fine. I can't see any
differences in the ODBC-configuration.
Any idea?
Thanks(kk035@.hotmail.com) writes:
Quote:
Originally Posted by
I'm migrating an IIS/SQL-Server application from Windows NT4.0 and SQL-
Server 2000 to Windows 2003 Server and SQL-Server 2005.
>
My problem is that it is not possible to connect local (IIS and SQL-
Server 2005 are runnng on the same node) using ODBC. Running the
applikation on a remote IIS (XPPro) all works fine. I can't see any
differences in the ODBC-configuration.
Error messages? Connection strings?
Running IIS and SQL Server on the same machine is not a very good idea,
from the point of view of performance and security. The latter is
particularly critical, if the web application is on the internet.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||It's just an internal application without any performance problems.
strConnect="DSN=ODBC-datasourcename;UID=username;PWD=password"
code snippet:
set conDb = Server.CreateObject("adodb.connection")
conDb.Open Session("strConnect")
for each errDb in conDb.Errors
if errDb.Number <0 then
bDbError = true
Session("strErrTxt1") = errDb.Description
Session("strErrTxt2") = errDb.Source
Session("strErrTxt3") = errDb.SQLState
Session("strErrNbr1") = errDb.Number
Session("strErrNbr2") = errDb.NativeError
exit for
end if
errDb.Clear
next
-err.Db contains no information|||(kk035@.hotmail.com) writes:
Quote:
Originally Posted by
It's just an internal application without any performance problems.
>
strConnect="DSN=ODBC-datasourcename;UID=username;PWD=password"
>
code snippet:
>
set conDb = Server.CreateObject("adodb.connection")
conDb.Open Session("strConnect")
for each errDb in conDb.Errors
if errDb.Number <0 then
bDbError = true
Session("strErrTxt1") = errDb.Description
Session("strErrTxt2") = errDb.Source
Session("strErrTxt3") = errDb.SQLState
Session("strErrNbr1") = errDb.Number
Session("strErrNbr2") = errDb.NativeError
exit for
end if
errDb.Clear
next
>
-err.Db contains no information
But what happens? Does it wait for 15 seconds and give up? Or does attempts
to use the connection fail?
And why use a DSN? Personally, I've never liked DSNs, it just one more
source of error. What is in that DSN?
What happens if you change the DSN part to Provider=SQLNCLI?
Where does the password come from? Is it hard-coded into the
application, or user-entered? Keep in mind that in SQL 2005, passwords
are always case-sensitive.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||On 17 Feb., 15:55, Erland Sommarskog <esq...@.sommarskog.sewrote:
Quote:
Originally Posted by
(k...@.hotmail.com) writes:
Quote:
Originally Posted by
It's just an internal application without any performance problems.
>
Quote:
Originally Posted by
strConnect="DSN=ODBC-datasourcename;UID=username;PWD=password"
>
Quote:
Originally Posted by
code snippet:
>
Quote:
Originally Posted by
set conDb = Server.CreateObject("adodb.connection")
conDb.Open Session("strConnect")
for each errDb in conDb.Errors
if errDb.Number <0 then
bDbError = true
Session("strErrTxt1") = errDb.Description
Session("strErrTxt2") = errDb.Source
Session("strErrTxt3") = errDb.SQLState
Session("strErrNbr1") = errDb.Number
Session("strErrNbr2") = errDb.NativeError
exit for
end if
errDb.Clear
next
>
Quote:
Originally Posted by
-err.Db contains no information
>
But what happens? Does it wait for 15 seconds and give up? Or does attempts
to use the connection fail?
>
And why use a DSN? Personally, I've never liked DSNs, it just one more
source of error. What is in that DSN?
>
What happens if you change the DSN part to Provider=SQLNCLI?
>
Where does the password come from? Is it hard-coded into the
application, or user-entered? Keep in mind that in SQL 2005, passwords
are always case-sensitive.
>
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
It seems that it does not wait for 15 seconds - it returns at once.
The password is hard coded. Changing to SQLNCLI doesn't change
anything. Using the same ASP-application on a remote IIS without
changing anything works fine. Using a wrong password in the ODBC-
Configuration to get additional configuration options produces an
entry in the error log of the SQL-Server, which tells that the
password is wrong. Using a wrong password in the DSN for the ASP-
application does not result in an error log entry.|||(kk035@.hotmail.com) writes:
Quote:
Originally Posted by
It seems that it does not wait for 15 seconds - it returns at once.
The password is hard coded. Changing to SQLNCLI doesn't change
anything. Using the same ASP-application on a remote IIS without
changing anything works fine. Using a wrong password in the ODBC-
Configuration to get additional configuration options produces an
entry in the error log of the SQL-Server,
You are talking about the ODBC applet in the Control Panel?
Quote:
Originally Posted by
Using a wrong password in the DSN for the ASP-
application does not result in an error log entry.
A password in the DSN? Didn't you also have a password in the connection
string?
I still don't know why you think the connection failed.
If you leave out "if errDb.Number <0 then" do you get anything in
your Session array?
When you changed to SQLNCLI, did you remove the DSN reference?
What happens if you add "SERVER=bogus;" to the connection string?
What happens if you replace UID and PWD with "Integrated Security=SSPI;"?
Since I don't have to access to your system I have to ask questions in
the dark. Please keep this in mind when you answer the questions, and
try to be as clear and unambiguous as possible. It's enough of a guessing
game for me anyway.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx
