Loadable modules in DB Browser for SQLite

[i-s-o]

I am loading the Windows binaries from SpatiaLite in DB Browser for SQLite (DB4S) after copying the contents of http://www.gaia-gis.it/gaia-sins/windows-bin-NEXTGEN-amd64/spatialite-loadable-modules-5.0.0-win-amd64.7z to the same folder as  DB4S, except libcrypto-1_1-x64.dll and libssl-1_1-x64.dll because those files are already distributed by DB4S.

I haven't run into any issues so far, however, I wasn't sure whether I should have overwritten those two files with the ones from SpatiaLite package. Could you please provide guidance?

Thanks

[a.fu...@lqt.it]

Hi,

just to recapitulate the terms of the problem:

1. a library is a more or less complex set of source code
in some symbolic human-readable language.
2. in order to effectively run this code a compiler is
required so to translate the human-readable code into
the corresponding binary machine-readable opcodes
(usually packaged as a DLL in Windows)
3. different compilers usually produce different translations
and consequently different DLLs, but they are however
supposed to be interchangeable.
at least, this one is a safe assumption until both
strictly respect the same ABI (Application Binary
Interface)

If the two DLL were compiled starting by different
versions of the source code the above assumption
could easily fail, and some spectacular crash will
then follow.

other times more subtle instabilities/incompatibilities
may be caused by different versions of the C-runtime
support and so on.

short conclusion: there is no absolute way to check
in advance if a DLL could be a reasonable replacement
for another one.

test by yourself;
it correctly works and seems to be stable enough ?
it probably means that both have the same ABI

bye Sandro

[Brendan Illis]

Hi i-s-o

I've done quite a bit of testing with spatialite & DB4S and haven't run into any issues doing it either way with the DLLs that are common between them (substituting for different versions or leaving the install as is), though as Sandro says can't rule out some unexpected issue cropping up eventually, but that's a bridge I'll cross when/if I get to it. 

One thing to note that I've run into is that the DB4S GUI doesn't like some of the spatialite functions (notably `InitSpatialMetaData()`) and exhibit some strange behavior if executed through the DB4S interface. For instance for `InitSpatialMetaData()` a successful operation will return 0 to the GUI instead of 1, and the resulting metadata will not show up in the DB Structure / Schema tabs without committing your changes, closing, and reopening the DB. I haven't found a reliable way to get the GUI to refresh without closing and reopening the DB - although querying certain parts of PRAGMA will sometimes do it, if you find anything reliable please do share. Nearest I can tell the erroneous 0 response to the GUI has something to do with the way the application batches & submits SQL statements to SQLite. I have not yet encountered any instances of a function failing entirely or malfunctioning due to this, all the issues have been contained to the GUI refresh and how the application displays responses. So if you have a script which you knows work, you should be able to comfortably execute it within DB4S without issue, but you cannot necessarily trust the response in the GUI or the GUI itself without closing & reopening.

I'd also encourage you to bring any specific issues you run into to the DB4S github - as developing a tighter more consistent integration with spatialite would be a great addition to that project

-B