LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Building an Application involving the Database Connectivity Toolkit

Solved!
Go to solution

Hello all,

 

I hope this is a really stupid question.  I've built an application that writes data to an access database that resides on the company network.  The .udl file sits in the same folder as the database (on the network).  The path reference for the .udl file, goes all the way back to the root server (ex. \\Servername\folder\subfolder\dbconnect.udl) so that path should work on any computer on the network (as long as the user has the proper permissions).  The .exe works on my development system, but when it has been installed on any other computer, the data is not written to the database.  Another odd behavior is that the application will not throw an error.  Any help at all would be appreciated.  I'm running windows 10 64bit, LabVIEW 2016 32bit. 

 

Regards,

Mike

0 Kudos
Message 1 of 8
(4,806 Views)

Permissions and UNC paths are a tricky beast at the best of times. Things that I would do (in order):

  1. Design the application so the UDL location can be set in a config file. This helps with future changes and debugging.
  2. To start with have the UDL and Access database file in the same folder as the built executable. See if this deploys and runs ok to runtime machines. If this doesn't work then you have another general issue unrelated to server connectivity.
  3. Post the project here as a zip so that others can try it out. Preferably with the same database but with the data purged to help satisfy any IP-related concerns.
0 Kudos
Message 2 of 8
(4,800 Views)

How are you handling errors in your program?

Message 3 of 8
(4,750 Views)

tyk007,

 

1) I have tried saving the UDL locally using a reference to the application location, without success.

2) I will try this. 

3) No can do, every thing about this has IP implications.

 

My suspicion is that I'm missing a driver on the host machines... Are there any additional installers that I should be including?

 

Thanks for your suggestions.

0 Kudos
Message 4 of 8
(4,745 Views)
Solution
Accepted by topic author MichaelSte

@MichaelSte wrote:

tyk007,

 

My suspicion is that I'm missing a driver on the host machines... Are there any additional installers that I should be including?

Perhaps you are missing an OBDC driver for Access on your other machines.

Include some reasonable error handling in your application that tells you if something is not working perhaps than you will learn what's the cause for your problems.

 

Regards, Jens

Kudos are welcome...
Message 5 of 8
(4,736 Views)

Yes, this was it.  Dkfire's comment made me realize that I was doing absolutely no error handling.  I fixed that, and found that I was throwing an error at "open connection".  After some more troubleshooting, I decided to have that VI prompt me for connection information, rather than tell it where to find the .udl.  When I did this I found that the OLE DB provider that is being used in the .udl file was not available for selection...

 

The funny thing is, I could open the .udl and the correct provider would appear, and the connection test would pass!  If I went through LabVIEW to make the connection on that computer, the Microsoft office 12.0 Access Database Engine OLE DB Provider was not available.  My colleague who is doing all the DB work, found that it isn't available in the 2010 Microsoft Database engine drivers, but that we needed to get it from the 2007 Office system driver : Data connectivity components. 

 

Once that was installed.  Everything worked fine.  In case you're wondering, the machine was running 32 bit Office 2016 on a 64-bit Windows 10 machine. 

 

Thank you for everyone's help!

0 Kudos
Message 6 of 8
(4,711 Views)

I suspect that you have the 64-bit database driver installed, and that is the one used when editing the udl file. 

Make sure that you select 32-bit drivers when you run LabVIEW 32-bit

 

0 Kudos
Message 7 of 8
(4,696 Views)

Thank you.

That is the correct answer.

0 Kudos
Message 8 of 8
(3,135 Views)