LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

aputman
0 Kudos
Message 11 of 17
(1,325 Views)

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.

0 Kudos
Message 12 of 17
(1,320 Views)

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? 

aputman
0 Kudos
Message 13 of 17
(1,307 Views)

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.

0 Kudos
Message 14 of 17
(1,302 Views)

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.   

aputman
0 Kudos
Message 15 of 17
(1,296 Views)

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.

0 Kudos
Message 16 of 17
(1,279 Views)

Thanks APutman for all the help!

0 Kudos
Message 17 of 17
(1,278 Views)