drjdpowell

Unfortunately, the NXG Web module lacks both recursion and VIs for determining the data type inside a variant. This makes porting JSONtext to it very difficult.

Working on Idea (1) https://bitbucket.org/drjdpowell/sqlite-labview/issues/12/add-an-execute-sql-statement-multiple

That's sloppy on my part. Arrays should not be supported at all and that should throw an "Unable to Bind Arrays" error. The code for that is in the Disabled case of "Parse Parameters (Code).vi". I was experimenting with the idea of allowing U8 Arrays as binding as BLOBs, and I seem to have not undone my buggy experimental modification.

That example isn't broken for me in LabVIEW 2020. What happens if you delete the broken wire and reconnect?

Hi Guys, Support for writing multiple rows in this manner is on the Roadmap, but not yet existing, partly because I am debating multiple options: A new function, "Execute SQL Multiple Times", that takes a parameter input of arrays of clusters or a cluster of arrays and does multiple executions of one SQL statement. Integrating it into the existing "Execute SQL" node. Upping the LabVIEW version to 2017 and introducing a new VIM version of either (1) or (2). The problems with (2), which you guys are thinking should work are: "Execute SQL" is a polymorphi

I am trying to shift discussion of Messenger Library to a group at NI, as this conversation is at 12 pages and is hard to follow. New post about a beta feature for TCP that I am working on: https://forums.ni.com/t5/JDP-Science-Tools/New-Beta-feature-Reconnecting-TCP-Messenger/gpm-p/4092514#M5 Here's the image. The idea is to have a persistent TCP Client connection that will try and reestablish itself if broken.

You're right, this needs an example. How you describe it sounds correct. I've had as many as four update Booleans, I think.

It's documented in the DEV Template. I use a feedback timeout that is default 0 ms from every case but the Timeout case (which feeds back -1). This makes the Timeout case execute exactly once after the event queue is empty. Use a "Display needs update" boolean flag to record if the display needs updating in the timeout case. One can do this with Queues as well. With this one is able to look at all incoming data, but do expensive display operations only as often as possible (but as quickly as possible). So you could, for example, have information coming in a 100 a second, a

A Notifier is only usable is you only have one type of message coming in, and your display doesn't include any history, like a chart. Personally, I keep the data transfer lossless, but just make the actual front panel display update lossy.

They way you're using DVRs here, pulling the full data out of the in-place structure, forces a lot of copying. You have to do the work inside the event structure if you wish to prevent copying.

I've submitted a new version to the Tools Network.

This fix is on the Tools Network now. JDP Science Common Utilities 1.2.1.12

Have you used this? Any fixes needed?

I suffer from the handicap of being located in UTC+00:00, which makes it difficult for me to spot bugs in local to UTC conversion. I have to remember to switch my computer to the wrong timezone to test things, and I obviously didn't do that here. Thanks for spotting this. The format specifier should indeed have a ^ in it.

I believe those dlls came from a standard postgreSQL: https://www.postgresql.org/download/windows/ You could try installing postgreSQL from there and finding the latest-compiled versions of those dlls.