LabVIEW
Current status of PostgreSQL for LabVIEW?
Solved!
@OneOfTheDans wrote:
Nope, I just stuck with our original database (InfluxDB, which uses a HTTP API). Writing or auditing Postgres drivers for LabVIEW would have been too much of an undertaking.
That's the main problem with most open source LabVIEW libraries. Everybody is waiting for a ready made, perfectly working, and of course free goodie! And if someone posts some library he or she mainly hears about what doesn't work and seldom how it did work.
@OneOfTheDans wrote:
Yup, no knock on the community options! But I'm disappointed NI doesn't offer some simple API for databases like they do for VISA and other protocols.
Databases is unfortunately anything but simple to support. The fairly, by far not really, simple interface is ADO/DAO and that is thanks to its use of Active X a Windows only solution. Database .Net was until a few years ago not better at all, but that change with .Net Core being not anymore Windows only happened after NI had a sudden attack of withdrawal syndrome. ODBC was in a grey past supposed to be the one to rule them all but suffered from a very complex API and the fact that each supplier was trying to create their own walled garden anyhow. Non-Windows implementations were mostly hacky at best and had little support for many database drivers beyond reverse engineered attempts.
The result was that on anything but Windows, you really had to interface to the database specific library anyhow, if it even existed, and with several dozen databases, with each having their own protocol and interface library, this results in a completely unreasonable project, especially if you count in the willingness of the community to pay even a small fee for such a solution.
This only leaves two possibilities:
- A specific driver is developed for a paying project and the client in question does not mind to have this driver published for the larger community to profit from. It does happen but not very often and the path from a driver working for a closed source project to one being an easy to use library for random community users is still a long and painful one and easily can take up the same amount or more of time than it took for development of the initial working driver. It means that most such projects are available “as is”, largely functioning but with some limitations, rough edges and limited documentation.
- A crazy developer is spending hours of his or her time for the love of the universe to develop something that they find fun and challenging. Usually the motivation is high in the beginning but can vane quickly for a number of reasons. Other life events, unexpected difficulties that exceed their expertise and seem almost impossible to overcome, or the whole thing starts to work, sort off, sometimes, if the moon phase is right and the computer was nicely patted on its keyboard.The challenge is gone, now starts the nitty gritty and unsexy work of debugging, writing test cases, crashing, debugging more and over and over again. And then ohhh lord, documentation! Let’s run as hard as possible! 😀
And yes, expecting NI to do it all is unreasonable. They are not in the business of databases and to take your PostgreSQL as example that’s one of the niche ones and would be for sure not at the top of their list to support as a product.
Dr Powell's package on VIPM is working very well I think, I use it on Linux, NI Linux RT and sometimes even on Windows when I feel adventurous.
Version in now 0.6.x
I've been using it since 0.3.x
Of course you can't simply wait for NI's priorities to align with yours is.
OpenSource has similarities... as pointed out by XKCD on dependencies
Nobody said anything of controversial. NI does support database access with their Database Toolkit. Yes it costs money and yes it uses ADO/DAO aka, ActiveX and that means it is Windows only. Considering that maybe 95% of LabVIEW users are running on Windows for at least their main development system, this is a pretty strong coverage of the potential user base.
Of course NI also sells cRIO's which run Linux and which you may feel tempted to let have access to a database server. Except that database access under Linux is even nowadays still a fragmented, colorful and rather complex theme. Not if you program in C, all database servers that want to be someone in the market have some binary library of one sort or the other to communicate with them. But each database has its own such library! unixODBC is an option but long not every database has drivers for that.
Basically NI could clobber something together of course and sell that as a Toolkit, yet whatever solution they choose, 9 out of 10 users will complain that it doesn't cover their used database server. And that for a relatively small group of potential users. Most cRIO applications do not access remote databases, simply for the reason that such a driver never would help the real-time system on them to run more reliably. It's also very often not needed. If you add that all together, you end up with a situation where NI could spend lots of effort to provide something that over 90% of the users never even want and the remaining 10% are divided up between 10 different database providers that all use different drivers so that 9 out of those 10 users still are not served by the NI solution. Sounds like a clear case of not even starting such a project. And yes, if they would decide to do something like that, PostgreSQL definitely will not be on the top of that list!
As to your counter example, DAQmx is the only way to access their hardware, which they sell for a premium and they can do that because thanks to their excellent driver support and integration with LabVIEW and other applications, it works very well. A database interface doesn't bring in any money beyond the possible Toolkit price for that library, and Toolkits in LabVIEW never really paid for themselves ever anyhow. Basically if you feel that NI should develop a driver for your preferred database, you could just as well require PostgreSQL to provide a LabVIEW driver for their database. Did you try that?
And to call PostgreSQL one of the most popular databases out there is probably a bit of a stretch. I have never seen PostgreSQL being used in any of the projects I worked in, but tons of Microsoft SQL, quite a few Oracle SQL and when it had to be low cost and/or open source, MySQL respectively MariaDB. And if it was not required to be a server based database, I have almost exclusively seen SQLite being used. Oracle efficiently eliminated DB4, when they took it over, but SQLite quickly filled that hole.
