Going from LVRT to ODBC Database?

[Gerardo]

Howdy,

Has anyone here created an interface between a LVRT system directly to an ODBC database?

Thanks,

Gerardo

[LAVA 1.0 Content]

QUOTE (Gerardo @ Mar 17 2008, 12:02 PM)

Howdy,

Has anyone here created an interface between a LVRT system directly to an ODBC database?

Thanks,

Gerardo

Talk about "oil and water" !

I would be impressed if anyone has done that.

Ben

PS: If I had to guess anyone has done that, it would be Rolf.

QUOTE (neB @ Mar 17 2008, 12:34 PM)

Talk about "oil and water" !

I would be impressed if anyone has done that.

Ben

PS: If I had to guess anyone has done that, it would be Rolf.

After further thought...

You'll need a machine to serve the ODBC DB so check-out Plexxium (TM Mack Information Systems). I wrote the initial version for them and they have since then converted to SQL so that app qualifies (it is also CFR-11 compliant). If you contact them ask for "Matt" and tell them that "Ben sent you."

Ben

[Gerardo]

QUOTE (neB @ Mar 17 2008, 12:59 PM)

You'll need a machine to serve the ODBC DB so check-out http://www.mackinfo.com/plexxium.html' rel='nofollow' target="_blank">Plexxium (TM Mack Information Systems). I wrote the initial version for them and they have since then converted to SQL so that app qualifies (it is also CFR-11 compliant). If you contact them ask for "Matt" and tell them that "Ben sent you."

Hey Ben,

I'm not quite following how Plexxium fits in. I'm not well versed in database talk, so I may need a primer.

Thanks,

Gerardo

[LAVA 1.0 Content]

QUOTE (Gerardo @ Mar 17 2008, 05:23 PM)

Hey Ben,

I'm not quite following how Plexxium fits in. I'm not well versed in database talk, so I may need a primer.

Thanks,

Gerardo

WHen you have abetter idea of what you are after, post back.

Technically speaking

LV-DSC used to be sold as ODBC compliant. So depending on the req's the answer may be in your back pocket.

Re: "Oil and water"

DB's are generally implemented such that all transactions are handled no matter what and "to hell with time".

RT is implemtned such that all operations are deterministic no matter what and "to hell with logging".

Take care,

Ben

[Yair]

I have no idea whether this will help or not, but you might wish to look into this. I don't know if this can be run on a RT target and if it's ODBC compliant, but it might work.

[Rolf Kalbermatter]

QUOTE (neB @ Mar 17 2008, 01:59 PM)

Talk about "oil and water" !

I would be impressed if anyone has done that.

Ben

PS: If I had to guess anyone has done that, it would be Rolf.

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

[Gerardo]

Thanks Rolf, for such a complete answer.

The background to the question is that customers of RT platforms occasionally want to interface directly to an ODBC network. We (as in NI) have always recommended your approach, i.e. to have an app running on a GPOS to receive data from RT and pipe into the database. I was just curious to see if anyone had tried "implementing the actual database network protocol", because if they had, I'd love to refer customers to them.

Thanks again,

Gerardo

[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

[Rolf Kalbermatter]

QUOTE (Andre Tomaz @ Jun 6 2008, 11:15 AM)

Hello Rolfk,

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

It's going directly to the ODBC API. More precisely it is for the most part relying on ODBC 2.5 features only since I started that work back in 1996 and improved on it since.

QUOTE

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?

No I never really used ADO based libraries, not the NI SQL Toolkit, nor the LabSQL Toolkit, nor the IB Berger ADO Toolkit or the T&M Database Toolkit.

There seem to be some problems with ActiveX references not always being closed in some of those toolkits. But I have not really used them so I can't give more details. My driver being for a large part a DLL/shared library also has the potential of memory leaks although I believe I got it to the point where memory leaks should not happen anymore.

About putting it up for others to use, I've thought several times about it but decided for a number of reasons against it. To name a few reasons:

- It works for me but its documentation sucks and its features have by far not all been tested and also not with many ODBC drivers and it's likely to fail with some ODBC drivers since ODBC is more like a RECOMMENDED standard than a real standard.

- Documenting and maintaining it would cost a lot of time but I have not figured out a workable way to cover for the cost of that. Selling Toolkits does not work, selling support for it is also more or less unworkable.

- Its DLL/shared library is rather advanced and I do not want to open source it.

Given these reasons it simply is a lot more cost effective to not spend more time for that than is necessary for my own use. That cost can be charged to specific projects, public use as Toolkit basically not.

Rolf Kalbermatter