Resolved SQL Server DLLs required on user's PC

tim8w

Well-known member
Joined
Sep 8, 2020
Messages
129
Programming Experience
10+
Hi,
I have deployed my program on several user's PCs and they get the following error I believe when the program tries to Open a connection: "Login filed for user". Kind of a strange error., since the credentials are in the program and I don't get the error when I run from my PC, but obviously I have all the correct DLLs installed since I have SQL Server installed on my PC. What DLLs does the user's PC need to have installed? We are using SQL Server 2014.

Thanks
 
If you are using the .NET Framework or .NET Core's SqlConnection then all that is needed to be installed on the user's machine is the .NET Framework or .NET Core. With .NET Core, you can even deploy the app as self-contained so that the user doesn't even have to install .NET Core.

I recommend digging deeper to see what is causing the login failure. If you have an exception, call ALL the exception data -- not just the top level exception. Some exceptions will have extra text following the initial description text. Also, some exceptions may have an InnerException property that is set that contains even more details.

Now tangent to your current problem. Yes, back in the 80's and 90's, it was normal for people's PCs on a LAN to connect directly to a SQL Server living on the same LAN. After Slammer and some other SQL Server issues, people will now generally keep "front office" people's PCs from directly accessing the "back office" servers. Often a web service is setup to so that the "front office" apps will hit the web service, and the web service will relay the needed requests to the "back office" servers. But if you trust your SQL server to be accessed naked on your LAN, it's your data.

Now on the other hand, if we were talking about Oracle, yes there are usually a bunch of other DLLs that you need installed on the user's machine if you are using the Oracle Native client. If you are using the Oracle Managed Client, then you can get by with just the assemblies that are packaged along with the Nuget package and put into your build output directory.

I don't know what the situation is with MySQL, or any other databases.

If you are using OleDbConnection, then, yes, you'll definitely need the appropriate OLEDB drivers/adapters for your database of choice (MSSQL, Oracle, Paradox, DB2, etc.) installed on the target machine.
 
Last edited:
If you are using the .NET Framework or .NET Core's SqlConnection then all that is needed to be installed on the user's machine is the .NET Framework or .NET Core. With .NET Core, you can even deploy the app as self-contained so that the user doesn't even have to install .NET Core.

I recommend digging deeper to see what is causing the login failure. If you have an exception, call ALL the exception data -- not just the top level exception. Some exceptions will have extra text following the initial description text. Also, some exceptions may have an InnerException property that is set that contains even more details.

Now tangent to your current problem. Yes, back in the 80's and 90's, it was normal for people's PCs on a LAN to connect directly to a SQL Server living on the same LAN. After Slammer and some other SQL Server issues, people will now generally keep "front office" people's PCs from directly accessing the "back office" servers. Often a web service is setup to so that the "front office" apps will hit the web service, and the web service will relay the needed requests to the "back office" servers. But if you trust your SQL server to be accessed naked on your LAN, it's your data.

Now on the other hand, if we were talking about Oracle, yes there are usually a bunch of other DLLs that you need installed on the user's machine if you are using the Oracle Native client. If you are using the Oracle Managed Client, then you can get by with just the assemblies that are packaged along with the Nuget package and put into your build output directory.

I don't know what the situation is with MySQL, or any other databases.

If you are using OleDbConnection, then, yes, you'll definitely need the appropriate OLEDB drivers/adapters for your database of choice (MSSQL, Oracle, Paradox, DB2, etc.) installed on the target machine.
We are building for .Net 4.5 and access SQL Server 2014 database using System.Data.SQlClient not OleDbConnection. I am interested in you comment "you can even deploy the app as self-contained so that the user doesn't even have to install .NET Core". Is that a setting somewhere in the Build or Publish? For Publish, I have "Microsoft .Net Framework 4.5" checked.

Still looking into the rest of the exception data, but like I mentioned, the credentials are compiled into the program. The user is not entering that it or the program is not getting it from the user login...
 
I am interested in you comment "you can even deploy the app as self-contained so that the user doesn't even have to install .NET Core". Is that a setting somewhere in the Build or Publish? For Publish, I have "Microsoft .Net Framework 4.5" checked.
As I said, that only applies to .NET Core. .NET Framework followed the Java philosophy that some JVM needed to be installed first. .NET Core was more flexible in either supporting the framework installed on the machine, as well as being the likes of Cygwin, MinGW, and git where everything is shipped along with the app.
 
Still looking into the rest of the exception data, but like I mentioned, the credentials are compiled into the program. The user is not entering that it or the program is not getting it from the user login...
Are you sure that connection string is using SQL Authentication instead of Windows authentication?

Is there a firewall on your SQL Server that is blocking traffic on specific port?

In my experience, the login failure message in the SQL exception is more explicit than just saying that a particular account failed to login. Usually the first sentence is login failure, but it is followed by additional text which help identify why the logon failed. I've seen messages that indicated a network time out. I've seen messages that indicated that connection pools had been exhausted. I've seen messages that indicated too many failed retries.
 
Are you sure that connection string is using SQL Authentication instead of Windows authentication?

Is there a firewall on your SQL Server that is blocking traffic on specific port?

In my experience, the login failure message in the SQL exception is more explicit than just saying that a particular account failed to login. Usually the first sentence is login failure, but it is followed by additional text which help identify why the logon failed. I've seen messages that indicated a network time out. I've seen messages that indicated that connection pools had been exhausted. I've seen messages that indicated too many failed retries.
Connection string is using SQL-authentication. As for Firewall, if it was a port or firewall issue, it wouldn't work from my PC either. I tried saving out the extended errors to a text file, but Windows wouldn't let my program create a text file on the user's system, so I'm back to showing it on the MessageBox. Need to re-complie and redeploy. I'll post anything I learn here.

So the full error message explains why it did not connect. For some reason even though in the ConnectionString I have explicitly called for the SQLServer user to be connected, it uses the current PCs login instead. Have you ever heard of such a thing before? Is there some flag I must set or something so that it will use the connectionString I specified and not override it and use the Windows Login instead?

Here is my ConnectionString:

C#:
SqlConnection myConnection = new SqlConnection("Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=FPY;Data Source=MyServer;User ID=PartsetupUser;Password=MyPassword");
 
Last edited:
Is the connection string truly hard coded, or is it in an app.config? If there is an app.config, what is the name of the connection string? Is there a connection string section in the machine.config or the application.config on the machine's .NET Framework directories? If there is such a section, is there a connection string with the same name? I believe that takes precedence.
 
Is the connection string truly hard coded, or is it in an app.config? If there is an app.config, what is the name of the connection string? Is there a connection string section in the machine.config or the application.config on the machine's .NET Framework directories? If there is such a section, is there a connection string with the same name? I believe that takes precedence.
It was the "Integrated Security=SSPI;Persist Security Info=False;" actually more precisely just the "Integrated Security=SSPI;" that was forcing the connection to the Windows logon instead of the SQL Server user logon specified in the connection. Thanks for all your insightful questions and directions.
 
Back
Top Bottom