DB Connectivity toolkit - DSN not found error

[Mr._Jim]

Hi all,

I wrote a VI that performs a database search and returns the results, and then I built this VI into an executable. On almost every machine in our office, it seems to work just fine as this executable. The catch is that all the systems I've tried it on are running XP and have LabVIEW 7.x installed.

The problem is that I've tried installing and running it on a Win2k server without LabVIEW (just runtime via the installer), and I get an ODBC Driver Manager error via my LabVIEW error handler. This is evidently a common message: "Data source name not found and no default driver specified." Of note, the server is up to date on the JET driver service packs, etc.

I'm using the DB Connectivity Toolkit, and I'm generating the following UDL string:

Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=;
Persist Security Info=False

Of course, the real path is very long, so I didn't type it here, and I know it's correct and can be accessed.

I'm then feeding that UDL string into "DB Tools Open Connection.vi" from the DB connectivity toolkit library. On all the machines that my build works on, I have no DSN configured under ODBC. The toolkit is somehow generating a DSN on the fly, but I have no idea how it works, or how to fix it, because the code is locked down. I'm wondering the the DB connectivity toolkit runs some sort of server? LabVIEW is my forte, not databases.

How can I resolve this error?

Thanks for your help

[TylerS]

CT_JIM,

What it sounds like is going on is a difference in database APIs between your Windows XP machines and your Windows 2000 machine. If it's telling you that a data source name is not found, it sounds like it's expecting an ODBC interface, because DSNs (data source names) are associated with ODBC, whereas UDLs are associated with OLE DB interfaces. So if you've created a UDL and it works with the XP machines, but you get an error on your 2000 machine about a missing DSN, I'm guessing you're 2000 machine is not using OLE DB like the XP machines and is instead using ODBC. So check your drivers to see which protocol you are using on the 2000 machine.

Tyler S

[Mr._Jim]

Thanks, Tyler. I'll see if I can find which driver is missing. I kind of expected that it was something along those lines.


Jim F