Hi Richard,
I have discovered that there is a problem in that the vba code (I got
from the github site) is somehow failing to load my custom library from
my specified location and in fact keeps referencing a file with version
3.8.5 from 2014. I am not sure how to overcome this right now apart from
renaming my custom library to something else apart from sqlite3.dll and
updating the references in the sqlite module.
The module uses the declare keyword to hook into externally declared
functions in another dll, and also adds references to some windows
functions - one of which is the LoadLibraryA function from kernel32 and
that is the one that is asked to load my library.
There are, of course, multiple apps on my system that use sqlite3.dll -
including the Bricscad app that I am running my vba code from.
Regarding the other questions: My custom shell and library (referenced
in sqliteexpert) return the correct string for sqlite_source_id(), and
they do know that geopoly is active because I can create the virtual
table and use all of the geopoly special functions.
I welcome any help you can provide.
Graham
On 31-10-2018 12:34 am, Richard Hipp wrote:
On 10/30/18, Graham Hardman <gra...@gh-designs.net> wrote:
To clarify: I built my own versions of the library and shell using the
latest amalgamation (3.25.2) specifically to test the geopoly
Are you certain that the third-party tool is picking up your custom
DLL? Verify by looking at the results of "SELECT sqlite_source_id();"
Are you certain that you enabled GeoPoly when you built your custom
DLL? Remember that GeoPoly is an extension that defaults off.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
