LabVIEW
ODBC for CompactRIO
@Bob_Schor wrote:
It looks dubious that you could install a driver that would work with Microsoft SQL Server on a Windows 10 PC, so I'd venture that it would be even less likely that you would be able to install it on a system running LabVIEW Linux Real-Time OS (that might not be the "official" name, but it certainly isn't Windows 10).
You'd want to create a LabVIEW Real-Time Project where the Host (PC) does the data base operations requested by the CompactRIO and passes (or receives, as specified) the data to/from the RIO.
Bob Schor
Microsoft SQL support on Windows is pretty much build in as soon as I install any of the various Microsoft SQL server versions or the according client access drivers. But on Linux things get a lot more complicated.
There are two ODBC manager solutions for unix based systems. One is called unixODBC and the other is called iODBC. But for most modern systems unixODBC is the default selection. That was not always the case as unixODBC was being in a dormant state for some time after its introduction while iODBC had still some active development at that time but currently unixODBC is pretty much the standard for most modern Linux systems and either shipped as standard component with the base system or offered as default additional module.
The problem is that the ODBC manager is just the manager layer for particular ODBC drivers. Each database requires its own specific driver that knows how to talk the SQL server specific (often proprietary) protocol to communicate with the server.
There are two possible drivers to contact an MS SQL server from a Linux system.
The first is from Microsoft itself: https://learn.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-fo...
This driver is precompiled and only available in specific architectures. There is a good change that the x86_64 (amd64) version would be possible to be used on the cRIO-9040 since it is also an amd64 platform. The arm64 version will however never possibly run on the NI cRIO ARM controllers such as the myRIO-1900 or the cRIO-906x controllers. These controllers run an ARM32 Linux OS that is also specifically compiled in a binary mode for the Xilinx Zync 7000 hardware that will only be compatible to binary modules specifically compiled for this platform.
The second option is the open source ODBC FreeTDS driver from here: https://www.freetds.org/
This driver is implementing the Microsoft SQL server protocol as was documented by the original document from Sybase from which Microsoft licensed the code for the initial Microsoft SQL server version. Microsoft added various extensions to the protocol over time and the FreeTDS people tried to implement these extensions through reverse engineering of the protocol. Since several years Microsoft also provides a document that documents pretty much all new extensions used in the various SQL server versions. So FreeTDS may not support all possible features of the latest versions of Microsoft SQL Server but for simple data query and storage it is more than enough.
As it is in source code, anyone can recompile it for any platform he desires and that would also be the best solution to get running for the cRIOs. But it is an additional serious complication for anyone who hasn't recompiled source code packages on his Linux system. But it is another option to have if you absolutely want to or the Microsoft SQL Server driver for Linux doesn't work for some reason.
The third option would be to implement the TDS protocol with native LabVIEW TCP nodes. This has come up several times over the years but nobody seems to have been going beyond entertaining this idea, or if someone did go further they did not feel like sharing their result with the world.
Also note that you will have to do some serious Call Library Node work. If using ODBC, the ODBC API needs to be interfaced to and that is not exactly trivial. There are a few projects out there who try to do that with Call Library Nodes, but most are targeting mainly Windows and testing for Linux is usually a second thought if even considered at all. For the FreeTDS driver there is also an option to access its native API directly and avoid the whole unixODBC manager layer. The main reason to do that would be that the FreeTDS native API is actually a bit simpler to access than the ODBC manager API, so the Call Library Node configuration will require some less work. The drawback would be that by interfacing the FreeTDS native API you limit your library to just work with FreeTDS and can't easily target a different database if you ever should need to.
