I'm storing and retrieving small images in a database using the database connectivity tool kit and parameterized stored procedures. The data type is set to 'Binary'. When I send up a jpg and look at the bytes stored, 4 bytes are prepended - A little investigation determined it was the size of the byte array. Probing the wires showed me that it WAS in fact LabVIEW adding the size, in the "Set Parameter Value" function. In the file functions, you can choose to prepend the array size or not. But this functionality seems to have not been included in the "Set Parameter Value" function of the DB toolkit. I tried [u8], binary string. I always get the array size added. So when I pull it down from the DB and attempt to open it as an img file, it will not. I have to chop off the first 4 bytes to get to the actual data. I would like to simply insert and select binary data 1:1, no modification. Can it be done?

LabVIEW

LabVIEW Database Parameterized Query prepends array sizes to binary data

@rolfk wrote:

I used to work on the ActiveX based Test & Measurement Solutions Database Toolkit back when that company was still a thing. That toolkit was even sold for some time. And I implemented a DLL to convert OLE Variants into LabVIEW native datatypes because the build in conversion in LabVIEW was not very efficient for iterating data types like arrays of anything but scalars. Not surprised that .Net is even worse.

I had talks with NI about offering native iterator and collection support. The people where enthusiastic, and then all communication stopped for reasons I can very well imagine.

@rolfk wrote:

. This is the main reason that LabVIEW fails to properly execute automation server and assembly calls for newer versions of the component if the method signature has changed (additional optional parameters) such as for the Save method for pretty much every Office version.

I never had this problem with .NET. I think maybe .NET keeps the old versions too, so they stay available. Or maybe it just updates as a framework, where the office AX components updated for every office update, and even between different languages of office.

@rolfk wrote:

With access to the LabVIEW source code and some minor changes to how the compiled data structure for ActiveX (and .Net calls is constructed) this could have been fixed already 20 years ago.

That figures...

From what I read it's no problem to change .NET version either. In almost any language a different GUID should switch the entire application, or even subsystems, to any recent .NET version.

I don't know enough about how LV handles .NET or .NET's execution system to be certain, but it seems to me support for .NET 8 (already old) shouldn't be that hard. And once it works, it shouldn't be too hard to support .NET 9, or let us choose.

Calling .NET from an application is quite a niche, and most information online seems to be 20 years old. Probably because it's no issue at all for most users.