SQLite library not working with LV2025 64 bit

[viSci]

I realize this SQLite LIbrary (by ShaunR) is pretty ancient so not surprised there maybe some dll updating required but I thought I would inquire.

I have used it many times in the past and have come to appreciate its performant well crafted design.

Edited Sunday at 01:29 PM by viSci

[ShaunR]

The SQLite API for LabVIEW was retired 6 years ago (at version 5.0.0).

[viSci]

That is considerably more modern then my v1.3.1, I would give it a go if you could make it available...

Edited Sunday at 05:45 PM by viSci

[ShaunR]

If you have a commercial waiver then there is limited residual support but apart from that, you should be looking to transition to an alternative product. 

[hooovahh]

There are several SQLite libraries on VIPM.io. I personally use the one by JDP Science, but a few others also look promising. Changing over will obviously take some time finding and replacing one API for another, especially if there are differences in design choices in how they each implement similar functionality. 

[viSci]

Thanks.  I have already started porting to JDP SQLite.  I should have done that a long time ago.

[ShaunR]

22 hours ago, viSci said:

Thanks.  I have already started porting to JDP SQLite.  I should have done that a long time ago.

If you didn't use the encryption then you could use the SQLite binaries from SQLite.org to keep you running while you transition. I can't remember off-hand if it was supported in 1.3.1 but adding AES=NONE to the project conditional symbols enables the use of vanilla SQLite binaries (i.e. comments out encryption function calls). That said, I expect the issue with LV2025 is probably to do with calling parameters rather than the binary itself because V5.0.0. seems to work fine with LV 2025 & 2026.

[viSci]

I did try the latest sqlite dll from SQLite.org and also adding the AES symbol to the project but still crashes.

[ShaunR]

1 hour ago, viSci said:

I did try the latest sqlite dll from SQLite.org and also adding the AES symbol to the project but still crashes.

It is probably one or more misconfigured CLFN's somewhere that was fixed in later versions. It was worth a try though.

[viSci]

It crashes running any of the included examples.  It seems to be able to open a reference to the .db but any queries crash.

[ShaunR]

34 minutes ago, viSci said:

It crashes running any of the included examples.  It seems to be able to open a reference to the .db but any queries crash.

Indeed. That is usually the result of misconfigured CLFN's.

[viSci]

Are you suggesting that the problem was non-uniform application of the pointer-sized integer CLFN parameters?

[ShaunR]

4 minutes ago, viSci said:

Are you suggesting that the problem was non-uniform application of the pointer-sized integer CLFN parameters?

Not necessarily but possibly. Pointer to data instead of value or vice versa, enum sizes, pointer de-references of strings etc. Library calls are trixy.

[Rolf Kalbermatter]

On 6/2/2026 at 7:41 PM, ShaunR said:

Not necessarily but possibly. Pointer to data instead of value or vice versa, enum sizes, pointer de-references of strings etc. Library calls are trixy.

Just one wild guess that recently bit me in another library. Does the SQLLite API in the Windows DLL use stdcall calling convention?

Until LabVIEW 2011, LabVIEW had a "helpful" feature to second guess your choice of that calling convention in the Call Library Node if the exported function had the appendix @xx with xx indicating the number of bytes passed on the stack for the parameters. The calling convention was silently "corrected" to stdcall even if you had cdecl in the configuration. Once you move to LabVIEW 2011 or later, this suddenly crashes as that silent correction was removed without any warning. The correct way when such a feature gets removed would have of course been to mutate the VI when converted from a pre 2011 version to 2011 or later. However the person removing that paternalizing feature did not think about adding an according mutation code path in the InstrumentLoad() function.

The thing bit me because I was developing code in LabVIEW 8.6 and had been also testing it in LabVIEW 2020 64-bit to be sure, wrongly assuming I had been accounting for a fairly large range of LabVIEW versions and platforms. Since LabVIEW 64-bit does not have any calling convention to choose from it did not expose that misconfiguration and someone else loading it into a newer LabVIEW 32-bit version found out the hard way that I had messed up.

Never mind, I see it is 2025 64-bit LabVIEW so there is no calling convention to get wrong.

Edited 3 hours ago by Rolf Kalbermatter

[ShaunR]

2 hours ago, Rolf Kalbermatter said:

Just one wild guess that recently bit me in another library. Does the SQLLite API in the Windows DLL use stdcall calling convention?

Until LabVIEW 2011, LabVIEW had a "helpful" feature to second guess your choice of that calling convention in the Call Library Node if the exported function had the appendix @xx with xx indicating the number of bytes passed on the stack for the parameters. The calling convention was silently "corrected" to stdcall even if you had cdecl in the configuration. Once you move to LabVIEW 2011 or later, this suddenly crashes as that silent correction was removed without any warning. The correct way when such a feature gets removed would have of course been to mutate the VI when converted from a pre 2011 version to 2011 or later. However the person removing that paternalizing feature did not think about adding an according mutation code path in the InstrumentLoad() function.

The thing bit me because I was developing code in LabVIEW 8.6 and had been also testing it in LabVIEW 2020 64-bit to be sure, wrongly assuming I had been accounting for a fairly large range of LabVIEW versions and platforms. Since LabVIEW 64-bit does not have any calling convention to choose from it did not expose that misconfiguration and someone else loading it into a newer LabVIEW 32-bit version found out the hard way that I had messed up.

Never mind, I see it is 2025 64-bit LabVIEW so there is no calling convention to get wrong.

I would probably never have been able to resolve an issue like that. What kind of monster removes anti foot-shooting boots?

It's highly likely it was just me misconfiguring some CLFN's. It's obviously been fixed in later versions. I still use the API so would have known if there was an issue with 5.0.0. I think version 1.3 was about 2010 so that version is over 16 years old - an amazing testament to LabVIEW's compatibility really.