02-27-2018 11:35 AM
So we're trying to build a LabVIEW application that writes to a PostgreSQL database living on a 9039, and aren't quite sure how best to enable this. The Database Connectivity Toolkit appears confused by our cross-platform environment (as we're developing on Windows machines) and chokes when we try to move the code over to Linux RT -- probably due to DSN issues, but ones that I don't know how to fix from within LabVIEW.
What's the recommended way to connect LabVIEW to an embedded database on Linux RT while writing the code on a Windows machine?
Solved! Go to Solution.
02-28-2018 10:30 AM
The Database Connectivity Toolkit is not supported on Real-Time targets (see the Real-Time help for a list of unsupported features).
That being said, many folks have been successful building LabVIEW applications that talk to databases running on NI Linux Real-Time. Here is an example tutorial that walks you through setting up a PostgreSQL database on a Real-Time controller. This is using a different architecture, but I'd expect the steps to be generally accurate.
02-28-2018 10:56 AM
@scotia673 wrote:
The Database Connectivity Toolkit is not supported on Real-Time targets (see the Real-Time help for a list of unsupported features).
That being said, many folks have been successful building LabVIEW applications that talk to databases running on NI Linux Real-Time. Here is an example tutorial that walks you through setting up a PostgreSQL database on a Real-Time controller. This is using a different architecture, but I'd expect the steps to be generally accurate.
The software installation instructions are outdated. There's no need to enable feeds, no need to un-hold the libc6 package. The rest of the steps are likely more or less accurate
02-28-2018 01:36 PM - edited 02-28-2018 01:41 PM
Thanks, both of you! I was actually hoping to find a way to hook up some kind of API to LabVIEW for PostgreSQL on RT; I'm not a LabVIEW programmer myself, but was anticipating performance issues with the idea of sending single transactions over the CLI and was hoping that I could tell our programmers that they could use an API to open and close DB connections on either side of a large number of transactions without building a command string and passing the whole thing in a giant block. Is that the state of the art for LabVIEW interactions with PostgreSQL currently -- namely, batching statements into a single command-line and sending it through as a transaction? If so, is there any way to do parameterized queries and the like, or are we just concatenating text?
02-28-2018 03:19 PM
Since the SystemExec utility is nothing more than executing shell commands on the controller, you can certainly parameterize the queries to the full extent supported by bash shell scripting.
Of course, there's a library that exists as well for interacting with Postgres databases, libpq (installable from the feeds), the only issue there is that you would likely need to write wrapper libraries to adapt the datatypes between LabVIEW and libpq.
Making your application's requirements and use-cases known to the NI sales rep(s) and marketing folks that you work with is what helps shape future efforts and features. Hopefully the tips above will help get you the functionality and performance you need, albeit with a bit of elbow grease.
02-28-2018 03:25 PM
Thanks, Brad! I'm sorry for the newbie questions, BTW; this is almost entirely outside my wheelhouse and I'm coming into things halfway through existing development, so I was flailing a bit. 🙂 I appreciate the advice.
03-01-2018 04:04 AM - edited 03-01-2018 04:06 AM
@BradMOf course, there's a library that exists as well for interacting with Postgres databases, libpq (installable from the feeds), the only issue there is that you would likely need to write wrapper libraries to adapt the datatypes between LabVIEW and libpq.
There is a wrapper of libpq on LAVA. It's a low-level wrap of the C library. I've done work on an alternate high-level wrap, but it isn't at the point where I would make it public. Haven't tried either on an RT system, but if you can install libpq then you should be able to get it to work.