08-15-2017 11:37 AM
Well, UDL is just a text file that has a connection string saved in it. Open a UDL file with a text editor and you'll see the same as the connection string.
Your datasource is SQLTEST. Is that the name of your SQL instance? Is the server running on localhost or on a server? Add the server location to the data source. Data source = servername\instance
08-15-2017 12:36 PM
The database is running on a server. Again the string should be correct as I can connect to the database through the development environment with no issue. If I change the string it no longer connects in even the development environment.
08-15-2017 01:36 PM
I understand that it works in DEV but doesn't work in EXE. You have stated that multiple times but that doesn't make sense to me unless DEV and EXE are two different machines. So for now, I am ignoring that statement and trying to be as thorough as possible. And I would advise the same on your end.
Create a .txt file on your desktop and rename it with a .UDL extension. Double click the UDL file and configure the settings to connect to the server. You should be able to test the connection and confirm everything right from that dialog box. After you get a successful connection, close the dialog and open the UDL file with a text editor and use the string found there as you connection string. What happens?
Have you tried rebooting your PC?
08-15-2017 01:55 PM
I followed your steps and setup the .udl and the test connection was successful. The connection string it ended up giving me was the same as what I had. I ran the exe (hoping for a miracle) and it gave me this error.
I'm confused on how it cannot exist/denied me when I just connected to it. I rebooted yesterday but I will try again and let you know the results.
08-15-2017 02:33 PM
Since you are using Integrated Security, there may be some other detail that I am missing or not familiar with.
Here are a couple of other suggestions to try:
Use the SQL Server Native Client provider?
Make sure you have the most up to date ODBC drivers for the SQL version that you're using.
Try to setup a User DSN in the ODBC tool that I mentioned early on. After you get a successful connection there and have saved it, configure the UDL file and select Microsoft OLEDB Provider for ODBC Drivers.
08-16-2017 12:52 PM
After playing around with the location of the .exe it turned out to be a firewall issue with the network drive I was running the executable from. When I previously asked IT they had no idea there was something in place to prevent this from happening.
08-16-2017 12:53 PM
Thanks APutman for all the help!