CODEWITHSUNDEEP
vbscriptasp-classicodbciis-6iis-8.5
ccko4800
ccko4800

Reputation: 1

DB Connections in session variables fails after migrating from Win2k3 to Win2012 R2

I currently have a Classic ASP website running on IIS6, and everything works well. "Include" file is used to open a db connection. The db connection is then stored in a session variable.

Here's a snippet of our Include "dbinclude.asp" file:

<%
Set CN_sql = Server.CreateObject("ADODB.Connection")
CN_sql.ConnectionString="DSN=sqldb;UID=testuid;PWD=testpwd;Server=testdb;Database=mydatabase"
CN_sql.Open
Session("Connection_sql") = CN_sql
%>

In the classic asp pages, we use the following code to connect to the DB to pull data:

<html>
<head>
<!--#include file="./dbinclude.asp"-->
</head>
</body>
<%
    set ds = Server.CreateObject("ADODB.Recordset")
    CN_sql = Session("Connection_sql")
    ds.ActiveConnection = CN_sql
    ds.CursorType = 0

    SQL = "select * "
    SQL = SQL & " from users "

    ds.Source = SQL
    ds.Open

    IF ds.EOF then
        response.write("SQL EOF.  NO data found.<br/>")
    ELSE
        ds.MoveFirst
        while not ds.EOF
            response.write(ds.fields("user_name") & " <br/> ")
            ds.MoveNext
        wend    
    End If
%>
</body>
</html>

In IIS6, this code runs fine for all pages. However, when testing in IIS8.5 (Win2012R2, and also IIS7,Win7), I get this error message:

Microsoft OLE DB Provider for ODBC Drivers error '80004005' [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

The line number where the error points to is this line: 

 ds.ActiveConnection = CN_sql

The Application Pool in IIS 8.5 is set to .NET v2, allows 32-bit application, Classic Pipeline. I've tried various combination of the application pool (changing to different .NET version, allow/disallow 32-bit application, Classic/Integrated pipeline, changed the Identity, tried different Session States).

In IIS 8.5, if I comment out the following line in the code:
CN_sql = Session("Connection_sql")
it will resolve the issue. However, since we have a large number of pages, rewriting and testing is not feasible at the moment.

Is there something in Windows 2012 that blocks you from storing an open database connection in a session variable? I know it's not efficient, but rewriting will be a big undertaking at this time.

Upvotes: 0

Views: 469

Answers (1)

Kev
Kev

Reputation: 119806

Looks like, on the new server, you didn't re-create the DSN (Data Source Name) specified in the connection string:

DSN=sqldb

If your application is running in a 32 bit worker process/app pool on 64 bit Windows then recreate it using:

C:\Windows\SysWOW64\odbcad32.exe

Otherwise recreate using:

C:\Windows\system32\odbcad32.exe

This KB article is also quite use when working with DSN's on 64 bit systems:

https://support.microsoft.com/en-us/kb/942976

Upvotes: 3

Related Questions