drjdpowell

They need a killer feature, some great thing not in regular LabVIEW. So far I haven't identified such a feature.

You're a bit late for this conversation, though the topic is still very relevant today.

Tried inserting png, jpg, and bmp images (by solution 1) and they can be viewed by SQLite Expert Personal, which I use.

I think your issue is the multitudes of "image" formats. There are many formats, and many conversion functions, and it is difficult to get things to work by trial and error. The webpage for "SQLite Administrator" indicates it understands JPG format, yet your attached code is converting from JPG to a LabVIEW-only flattened image format. You need to read that JPG image into a LabVIEW string, without converting it into some other format, and insert it. Look into the "Read form binary file"... (I see smithd has beaten me to it).

"Seems not to work" is the vagueous description you could give, but I wonder why you aren't just saving your bmp image as a blob, rather than turning it into a LabVIEW image format (and then only storing part of that).

What have you tried? Have you looked at the examples?

BTW, the SQLite Statement class can be subclassed, and you could easily define your own strict-typed versions of the "Get Column" property nodes. These would just check type before calling the regular function.

SQLite differs from other databases in its dynamic type system and philosophy of "best attempt at conversion instead of error". Note though that SQLite is meant as an embedded database, sitting behind an API written in another language. Types are enforceable in that API. I don't recall ever having mixed types in a column, because a table is generally only written to by one subVI, and maybe modified by another one right next to it in the same library/class. I have one client where there are four applications that access the same db files, but they all use the same LabVIEW class for access. The API even stores data points in a scaled format to take up less space, which is transparent to the application code.

No. You haven't given any information about your "normal" text file.

Yes.

Save your image files in binary Blobs.

I made the Server a Client of itself, in order to get events when true Clients changed things. A bit weird.

Here is the function I mentioned, BTW:

Does your receiving actor know the exact reply address that the special sender will use? You can use addresses as unique identifiers with "equals". There is a vi in the palettes that searches an array of addresses for the reply address on an incoming message. Your design is different from ones I'm familiar with, so that may not be a good answer.

This is Issue 9, the trickiest problem in Messenger Library at the moment. Can you try version 1.10.6, which is in the LAVA-CR (this has been submitted to the Tools Network and is working its way through the process. There is no ideal solution but this is my best attempt. Alternately, you can try renaming your Main:ActorNR to something else (assuming you don't need to launch it but are instead running it directly).

The dll should be automatically included in any exe; does that not happen with you? I have not tried using older dlls, but I suspect the would work.

A new video resource is the gdevcon1 videos.

Yes, DQMH is Delacor's framework, and is on the Tools Network, as is Messenger Library (which I wrote).

One loop per device is very scalable, when combined with asynchronous calls to allow an arbitrary number of such loops. The details are a bit tricky, but its the most scalable way to do it, which is why multiple people have generated frameworks to do it more easily.

They have this Sqlite function https://www.sqlite.org/c3ref/memory_highwater.html. But I haven't implemented it (yet).

I suspect your problem is not using BEGIN/COMMIT or some other way of wrapping many INSERTS in one transaction. Try looking at Example1, which inserts a large number of points.

Did you wrap your INSERTs in a transaction?

There are (not free) extensions of Sqlite that add encryption, but I have not tried them:

Note: The NI Labs version is now available without password protection.

Yes, that's the basic JSONtext use case: working with JSON: Working to/from LabVIEW data types is also a use case, and there is the (more complicated) ability to intermix JSON and LabVIEW Types in clusters using the <JSON>-tag method smithd describes, but a basic motivation of JSONtext is to be able to work simply with JSON-formatted strings directly.