Andre Tomaz

Hello Rolfk,

about the "ODBC LabVIEW library" you mentioned, do you use any ADO objects or direct access to odbc?

I am having a lot of trouble with ADO. I think there is a memory leak in the MS ADODB component... -I have tried many things, but all solutions using ADO seem to show the same problem.

Have you ever experienced anything like this? Do you plan to put your ODBC library avaliable for other users?

Thanks!

Andre

QUOTE (rolfk @ Mar 20 2008, 04:16 PM)

No I haven't done that yet. I have a fairly complete ODBC LabVIEW library here but that interfaces to the ODBC API and to my knowledge the ODBC API is not available on the RT OS. There is a little chance that you could get the Windows ODBC Manager running under the older Pharlap based RT OSes and that some ODBC drivers might work too. But it is a big if and that would definitely fail for the newer vxWorks RT Targets as that requires different object format libraries, so that there is absolutely no chance to get the Windows ODBC Manager working on them.

To get that done one would have to port unixODBC (or libiODBC) to the RT target. However that still would leave the problem of the according ODBC driver open. So in principle this approoach is a dead end.

Another approach would be to implement the actual database network protocol directly on the RT system. But that is really non trivial even when using existing open source libraries to create a shared library module for the RT OS. First porting those libraries to RT OS is tricky at least as RT OSes have simply a more limited OS API set than normal desktop systems. Second depending on the database used those libraries are fully fledged (Open Source databases like mySQL) or more or less limited or even antiquated (like for SQL Server). Reimplementing the protocol in LabVIEW while in principle possible is simply such a big project in itself that it is just not gonna happen.

What I would do is creating some LabVIEW ODBC proxy running on a generic ODBC enabled plattform (Windows, MacOS, Linux) and then using VI Server or just a simple TCP/IP protocol, call it's methods from the RT application. This also would make sure that the actual ODBC execution is entirely isolated from the RT system itself.

There are also commercial ODBC proxy applications that allow to be interfaced with more or less simple network protocols and/or easy to port API libraries.

However putting the entire DB on the RT OS is a sure way to kill its RT capabilities.

Rolf Kalbermatter