Error -2147467259 w/ DB Tools Open Connect while using .exe

[wmorris77]

I am using LabVIEW 2015 (32-bit) and I am having an issue connecting to a SQL database while running the executable. The program works fine while in the development environment but once it's built the .exe won't connect. I'm connecting through the DB Tools Open connection default vi and feeding it a connection string from a config file.

Any help would be appreciated.

[aputman]

I assume you are on Win64.

Use the ODBC tool found in c:\Windows\sysWOW64\odbcad32.exe.

[aputman]

Also what does your connection string look like?  Are you sure that you're reading the connection string properly from the config file?  Do you have the proper path to the config?  Most often, when reading from a file works in DevEnv but not in EXE, there is an issue with the path. 

[wmorris77]

To remove that possibility, I have just hardcoded the connection string in the mean time.

[wmorris77]

This is the error that keeps showing up.

[aputman]

Did you try using the ODBC tool in the sysWOW64 directory to configure the connection?  Either the connection string is wrong or you are using the wrong ODBC tool.

[wmorris77]

The connection string is correct as I can access the database in the development environment and the string does not change. I'm not quite sure how to use the ODBC tool, and IT is not quite sure how it needs to be configured. Can you clarify on that?

[aputman]

What is your connection string?

[wmorris77]

Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Test_Database;Data Source=SQLTEST

[wmorris77]

I've also tried a UDL which didn't change the outcome either.

[aputman]

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

[wmorris77]

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.

[aputman]

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? 

[wmorris77]

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.

[aputman]

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.   

[wmorris77]

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.

[wmorris77]

Thanks APutman for all the help!