1
votes

I'm building up a new machine with Windows10 and SQL Server 2017 and am having a hard time getting my legacy ASP applications to connect properly.

The Connection string looks like this:

"driver={SQL Server};uid=USERNAME;pwd=PASSWORD;server=LocalServer;Database=LocalDB;"

I'm able to connect with a connection string like this:

"Provider=SQLNCLI11;Server=LocalServer;Database=LocalDB;Integrated Security=SSPI;DataTypeCompatibility=80;MARS Connection=True;"

... but that causes a bunch of errors with the way the existing code and how it interacts with Stored Procs so I'm trying to get the first connection string to work.

The error I get with that string is this:

Microsoft OLE DB Provider for ODBC Drivers error '80004005'

[Microsoft][ODBC SQL Server Driver][Shared Memory]SSL Security error

/Codeshare/ServerSide/conx_current.asp, line 8

That code looks like this:

dim sqlconn
set sqlconn = server.CreateObject("ADODB.CONNECTION")
dim cn : cn = getConx("current")
sqlconn.open cn

... where getConx("current") just returns the Connection String from above

If it helps, I get the same error message if I try to create an ODBC connection using the SQL Server or SQL Server Native Client 11.0 drivers.

TIA

1
For me it looks like the problem is in the database security - the new connection string means the current Windows account is used for authentication with the database and if it is not mapped for access in the database then you will get an error. support.microsoft.com/de-de/help/306586/… - user2316116
Can you connect to SQL Server over TCP/IP or is Shared Memory the only option? TCP/IP is usually disabled unless you choose to enable it - John

1 Answers

1
votes

Sounds like the SQL Sever has been hardened to only allow the more secure protocols like TLS 1.2 and associated strong ciphers. The problem is that the older providers don't support these more up to date protocols. SQLNCLI11 does but as you have discovered how ADO behaves differently which then breaks ASP sites.

For the most part I found that adding SET NOCOUNT ON to the top of SPs and SQL batches restores 90% of the functionality. Then its a case of hunting the other issues.

The alternative would be to wind back the server hardening by re-enabling older protocols like SSL3 and re-enabling the lest secure ciphers

Search "TLS 1.2 and SQLNCLI11"