LabVIEW
How to use database connectivity toolkit with cRIO to log data into database
- last edited on by
Content Cleaner
@Ben wrote:
My faulty memory suggest that Rolf may have written something.
It is faulty indeed, as that is not from me! Although I have done some database stuff myself like some maintenance work on a Database Toolkit developed at our former company Test & Measurement Solutions, but we are not marketing that anymore. It was also based on an ActiveX interface and had the same trouble than the NI Toolkit in terms of running on other platforms than Windows. I have done some work on an ODBC based interface too, that was meant to work with the Windows ODBC, unixODB and libODBC API too, with the last two being two Unix ODBC implementations but it never really got used on anything but Windows in our company either.
But what the original poster wanted can't be done at all!
The Database Connectivity Toolkit is built on ADO/DAO, which is an ActiveX technology. ActiveX is something that only works under Windows. Your cRIO however runs either Pharlap ETS, VxWorks or NI Linux RT, depending on the hardware it is built on. As such there is no possibility to run the Database Connectivity Toolkit on any cRIO or other NI Realtime target.
There are several options: Either using a local file based database like the SQLite that runs directly on the cRIO and store data there. That is a good solution if you need the data management capabilities of a database but don't need the data necessarily on a central server. You still can move the resulting file of the cRIO for archiving or historical reference on a different computer but it isn't a good solution if you need centralized data storage.
There are several SQLLite versions out there, one notable:
SQLLite Library from Dr. James Powell He is quite active on lavag.org about this: https://lavag.org/topic/15857-cr-sqlite-library
The other approach is to directly interface to a central database server through its native network interface. Unfortunately each database has its own interface and while there has been work on some MySQL libraries directly in LabVIEW that interface to a MySQL (or MariaSQL) database server over TCP, there hasn't been much progress like that on the much more demanded Microsoft SQL Server front (and none on Oracle as they are very protective of their own technology).
The protocol used by SQL Server was for a long time not officially documented by Microsoft in any way and all that existed was an old protocol description from an old Sybase implementation which Microsoft had licensed to create their own SQL Server. The only Microsoft independent interface was a C based interface library called FreeTDS that was mostly developed through reverse engineering of the network traces. In recent years Microsoft has released documents that describe the whole protocol more or less in detail. But it is not the most easy documentation to read and fairly extensive. So far I haven't felt like wading through it and probably never will. 😀
