patternsqlMinor
Classic ASP Connection to SQL Server 2014 without TLS 1.0 using ADODB.Connection
Viewed 0 times
withoutsqltlsclassicusingserveradodb2014aspconnection
Problem
With TLS 1.0 being disabled in the name of PCI compliance, I'm unable to get a 32-bit Classic ASP application working.
Per MS / Stack Exchange recommendations, I've installed:
This has gotten our ASP.NET applications / SSMS running. But our Classic ASP application, which uses an
I've tried a connection string which uses
Microsoft SQL Server Native Client 11.0 error '80004005'
Shared Memory Provider: No process is on the other end of the pipe.
I also tried using Named Pipes with the connection string
Microsoft SQL Server Native Client 11.0 error '80004005'
Named Pipes Provider: No process is on the other end of the pipe.
Is there a patch for ADODB that I should be aware of?
Should I consider using Named Pipes in some other way or the like instead? (although I'm a little baffled as to why shared memory doesn't work, regardless of the TLS settings)
Updates from comments:
The web server and the SQL Server are on the same box.
It's a SQLExpress named instance. The connection string working with TLS 1.0 enabled is:
I've also tried:
Neither work once TLS 1.0 is disabled. I know Trusted_Connection / Integrated_Security is redundant, but messing around with these doesn't seem to help either.
I've toggled enabling, disabling, and order for both TCP and named pipes. The name of the pipe used in the connection string above is dire
Per MS / Stack Exchange recommendations, I've installed:
- SQL Server 2014 SP1 CU1
- .NET Framework 4.6
This has gotten our ASP.NET applications / SSMS running. But our Classic ASP application, which uses an
ADODB.Connection object is not working.I've tried a connection string which uses
Provider=SQLNCLI11;, but that doesn't seem to help either. The Shared Memory provider is still complaining about nothing being on the other end of the pipe. Error message:Microsoft SQL Server Native Client 11.0 error '80004005'
Shared Memory Provider: No process is on the other end of the pipe.
I also tried using Named Pipes with the connection string
Provider=SQLNCLI11;Server=np:\\.\pipe\MSSQL$SQLEXPRESS\sql\query;Database=northwind;Trusted_Connection=Yes; and received this error message:Microsoft SQL Server Native Client 11.0 error '80004005'
Named Pipes Provider: No process is on the other end of the pipe.
Is there a patch for ADODB that I should be aware of?
Should I consider using Named Pipes in some other way or the like instead? (although I'm a little baffled as to why shared memory doesn't work, regardless of the TLS settings)
Updates from comments:
The web server and the SQL Server are on the same box.
It's a SQLExpress named instance. The connection string working with TLS 1.0 enabled is:
"Driver={SQL Server}; Server=.\SQLExpress; Database=northwind; Trusted_Connection=Yes; Integrated_Security=True;"I've also tried:
"Provider=SQLNCLI11; Server=.\SQLExpress; Database=northwind; Trusted_Connection=Yes;"Neither work once TLS 1.0 is disabled. I know Trusted_Connection / Integrated_Security is redundant, but messing around with these doesn't seem to help either.
I've toggled enabling, disabling, and order for both TCP and named pipes. The name of the pipe used in the connection string above is dire
Solution
You might possibly be trying to use 32 bit legacy drivers.
Try running C:\Windows\SysWOW64\odbcad32.exe to create a DSN that connects to your SQL Server database using the 32 bit SQL Server driver. First test the connectivity using the GUI.
Then try specifying your DSN in your connection string like so:
The 64-bit version is located in:
C:\Windows\System32\odbcad32.exe
P.S. I've not tried this but the provider name for the 32-bit SQL Server is actually "SQL Server". It'd be nice if all you had to do was replace SQLNCLI11 with SQL Server. Here's my file DSN I created with the 32 bit version--notice the driver...
Try running C:\Windows\SysWOW64\odbcad32.exe to create a DSN that connects to your SQL Server database using the 32 bit SQL Server driver. First test the connectivity using the GUI.
Then try specifying your DSN in your connection string like so:
DSN=myDsn;Uid=myUsername;Pwd=;The 64-bit version is located in:
C:\Windows\System32\odbcad32.exe
P.S. I've not tried this but the provider name for the 32-bit SQL Server is actually "SQL Server". It'd be nice if all you had to do was replace SQLNCLI11 with SQL Server. Here's my file DSN I created with the 32 bit version--notice the driver...
[ODBC]
DRIVER=SQL Server
UID=sa
WSID=P13-0000
APP=Microsoft® Windows® Operating System
SERVER=mcdba1Code Snippets
DSN=myDsn;Uid=myUsername;Pwd=;[ODBC]
DRIVER=SQL Server
UID=sa
WSID=P13-0000
APP=Microsoft® Windows® Operating System
SERVER=mcdba1Context
StackExchange Database Administrators Q#124279, answer score: 2
Revisions (0)
No revisions yet.