SQL Server 连接错误 - 未找到数据源名称且未指定默认驱动程序

Question

When running a third party developed EXE located on the shared folder of Windows Server 2012 R2, which connects to SQL Server 2012 Express, the following error occurs:

[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.

When the EXE is 'Run as Administrator' it works fine. But this application interfaces with Office and other programs, so running as administrator puts it into protected memory space that conflicts with other applications. I need it to open normally, as before.

This error has only occurred since client workstations had Windows 10 1803 and higher installed. Bizarrely, workstations that updated to 1803 and higher are unaffected. Only on new installs has the problem occurred.

There was something about 1803 which changed the network stack, client side, that caused a lot of different problems for SQL connections and I have seen a hundred different solutions but none work in our case.

Client machines connect to Server 2012 using domain login accounts. Each domain user account is given local admin rights and full administrator rights. The client workstations are normal Windows 10 Pro install with ESET antivirus. When testing the ODBC connection, it is successful and works. Only when running the program does the error occur.

On the Server side I have.... Enabled Named Pipes, Disabled and Removed SMB1.0

So what is going on here? Why from 1803 on must we run as administrator to get a connection?

Answer 1

Data source name not found

I would first check if the Data Source is defined below "User" or "System" . If it is User for the Administrator there is no way to access it except if the user previously run it by using the option "Run with administrative permission"

In case it is defined as System DSN likely the user after 1803 does not have enough permission to access the registry where it is stored, so this is the most probable case scenario.

The optimal is to see if you can modify your connection using OLE or something else rather than ODBC so it can be DNSless, eventually try to define a DSN with the same name below User with the same user who is running it that should be read before the framework is going to look for the same DSN name under the system / local machine registry section.

To troubleshoot deeper registry permission issues you can use the former Sysinternals procmon downloadable from MS website, this must executed using "Run with administrative permission"