Re: [sqlite] curious discovery about geopoly module
Thanks. In my case there is no installer as such. My vba code runs inside the same process as the host cad system. In this case Bricscad has already loaded their copy of dqlite3.dll and my like-named file could not demand precedence. Graham On 02-11-2018 3:16 am, Simon Slavin wrote: On 1 Nov 2018, at 10:40am, R Smith wrote: Most applications play nice and do not install their greasy little DLLs to the Widows DLL common area, but just hug them locally (in the app folder). But some, thinking probably they were doing the right thing, do install DLLs to the common area, and sometimes this includes a DLL like sqlite3.dll which starts causing problems for everyone else using it, because they don't actually distribute/install newest versions, so everything else loading the same library gets the last installed version of the last app to successfully install to the common area. That's the problem. The standard Windows installer has a way of saying "install this common-area DLL if and only if there isn't one in there, or it's a later version than the one already in there". When only professionals wrote Windows programs that needed installing, it was fine, but now days few people use it because (A) Some DLLs have bugs, the programmer figured this out and wrote around the bug, but their work-around does't involve a version-check. Updating the DLL fixes a bug their app depends on. (B) My installer installs my app which works perfectly. If you have trouble with another app, take it up with their support team, not mine. Now days most houses use Installshield which has its own problems. Simon. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Thanks for the very detailed info. I am certainly a lot wiser now! Graham On 01-11-2018 11:40 pm, R Smith wrote: On 2018/11/01 9:51 AM, Graham Hardman wrote: I am pleased about this, although still puzzled by the fact that the windows LoadLibrary call returned a non null pointer and windows help file implies that it is ok for multiple copies of same name libraries to be loaded together. This is an old Windows problem, one which I think they (M$) have self-regretted so many times. What I deduced long ago after resolving a similar problem (and I could be wrong, I don't have insider info on it) is that Windows' idea of DLLs was to have it so the DLLs live in a common area in the Windows system path (typically c:\program files\common files\system) from where it can be shared to all the lovely apps everywhere needing to use it. AND, how wonderful would it be if, when a DLL is updated, everyone benefits from the new version. Right? So what they did is the DLL loader seems to have a rule of loading the DLL FIRST from the windows common DLL area, and only if not available there (because that's where the updatedest DLL would be, right?) then see if local DLL exists next to the app and loads it. Most applications play nice and do not install their greasy little DLLs to the Widows DLL common area, but just hug them locally (in the app folder). But some, thinking probably they were doing the right thing, do install DLLs to the common area, and sometimes this includes a DLL like sqlite3.dll which starts causing problems for everyone else using it, because they don't actually distribute/install newest versions, so everything else loading the same library gets the last installed version of the last app to successfully install to the common area. Even this wouldn't be such a catastrophe if the common area DLLs weren't usually "in use" by the services it supports, so it can't be updated by anyone else, unless you KNOW which service(s) is/are using it and stop all of them. This leaves a new application install with very few options, if you can't get Windows to use your local DLL, nor can you update the "in-use" one in the common area... How then do you cause the system to use your newest DLL? There are a few hacky ways: 1 - The easiest is to just use a different name (and to do your part by not installing it for all). 2 - Use a side-by-side isolation assembly. See: https://docs.microsoft.com/en-us/windows/desktop/SbsCs/isolated-applications-and-side-by-side-assemblies-portal This option is fine if you develop new software to be isolated from any DLL conflicts from the start, but it's a LOT of effort to just fix one conflict. 3 - This is my favourite - Use DLL redirection, which involves simply adding a .local file to your app path (so myapp.exe must be accompanied by myapp.local). This does require and extra file to maintain, but it's relatively easy and means you don't need to be concerned with sorting out DLL naming or isolation. I believe the file's presence matters, but its content is irrelevant (I usually add a line like "** Force local DLLs **" as the content), which makes Widows look locally first when loading DLLs. See: https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-redirection NB! - The .local file will force local redirection for ALL DLLs you use, some of which may not be intended, like if you supply xxx.dll as a back-up, but would prefer Windows to use it's internal (and possibly newer) xxx.dll if present. NB2! - As is the standard for M$, every fix must have a fallback... so known common DLLs cannot be redirected like this (there is a list maintained in the Windows registry in HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/KnownDLLs/ of what Windows regards as "common" DLLs. Make sure your DLL is not in there, for if it is, options 1 & 2 above are your only remaining venues). HTH - Cheers! Ryan ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
On 1 Nov 2018, at 10:40am, R Smith wrote: > Most applications play nice and do not install their greasy little DLLs to > the Widows DLL common area, but just hug them locally (in the app folder). > But some, thinking probably they were doing the right thing, do install DLLs > to the common area, and sometimes this includes a DLL like sqlite3.dll which > starts causing problems for everyone else using it, because they don't > actually distribute/install newest versions, so everything else loading the > same library gets the last installed version of the last app to successfully > install to the common area. That's the problem. The standard Windows installer has a way of saying "install this common-area DLL if and only if there isn't one in there, or it's a later version than the one already in there". When only professionals wrote Windows programs that needed installing, it was fine, but now days few people use it because (A) Some DLLs have bugs, the programmer figured this out and wrote around the bug, but their work-around does't involve a version-check. Updating the DLL fixes a bug their app depends on. (B) My installer installs my app which works perfectly. If you have trouble with another app, take it up with their support team, not mine. Now days most houses use Installshield which has its own problems. Simon. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
On 2018/11/01 9:51 AM, Graham Hardman wrote: I am pleased about this, although still puzzled by the fact that the windows LoadLibrary call returned a non null pointer and windows help file implies that it is ok for multiple copies of same name libraries to be loaded together. This is an old Windows problem, one which I think they (M$) have self-regretted so many times. What I deduced long ago after resolving a similar problem (and I could be wrong, I don't have insider info on it) is that Windows' idea of DLLs was to have it so the DLLs live in a common area in the Windows system path (typically c:\program files\common files\system) from where it can be shared to all the lovely apps everywhere needing to use it. AND, how wonderful would it be if, when a DLL is updated, everyone benefits from the new version. Right? So what they did is the DLL loader seems to have a rule of loading the DLL FIRST from the windows common DLL area, and only if not available there (because that's where the updatedest DLL would be, right?) then see if local DLL exists next to the app and loads it. Most applications play nice and do not install their greasy little DLLs to the Widows DLL common area, but just hug them locally (in the app folder). But some, thinking probably they were doing the right thing, do install DLLs to the common area, and sometimes this includes a DLL like sqlite3.dll which starts causing problems for everyone else using it, because they don't actually distribute/install newest versions, so everything else loading the same library gets the last installed version of the last app to successfully install to the common area. Even this wouldn't be such a catastrophe if the common area DLLs weren't usually "in use" by the services it supports, so it can't be updated by anyone else, unless you KNOW which service(s) is/are using it and stop all of them. This leaves a new application install with very few options, if you can't get Windows to use your local DLL, nor can you update the "in-use" one in the common area... How then do you cause the system to use your newest DLL? There are a few hacky ways: 1 - The easiest is to just use a different name (and to do your part by not installing it for all). 2 - Use a side-by-side isolation assembly. See: https://docs.microsoft.com/en-us/windows/desktop/SbsCs/isolated-applications-and-side-by-side-assemblies-portal This option is fine if you develop new software to be isolated from any DLL conflicts from the start, but it's a LOT of effort to just fix one conflict. 3 - This is my favourite - Use DLL redirection, which involves simply adding a .local file to your app path (so myapp.exe must be accompanied by myapp.local). This does require and extra file to maintain, but it's relatively easy and means you don't need to be concerned with sorting out DLL naming or isolation. I believe the file's presence matters, but its content is irrelevant (I usually add a line like "** Force local DLLs **" as the content), which makes Widows look locally first when loading DLLs. See: https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-redirection NB! - The .local file will force local redirection for ALL DLLs you use, some of which may not be intended, like if you supply xxx.dll as a back-up, but would prefer Windows to use it's internal (and possibly newer) xxx.dll if present. NB2! - As is the standard for M$, every fix must have a fallback... so known common DLLs cannot be redirected like this (there is a list maintained in the Windows registry in HKLM/SYSTEM/CurrentControlSet/Control/Session Manager/KnownDLLs/ of what Windows regards as "common" DLLs. Make sure your DLL is not in there, for if it is, options 1 & 2 above are your only remaining venues). HTH - Cheers! Ryan ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
On 2018-11-01, at 02:51, Graham Hardman wrote: > I am pleased about this, although still puzzled by the fact that the windows > LoadLibrary call returned a non null pointer and windows help file implies > that it is ok for multiple copies of same name libraries to be loaded > together. This has been a problem in Windows for years. Microsoft themselves used to include version numbers in library base names (eg, MSVCRT40.DLL) and other vendors use similar tricks to keep "DLL hell" at bay. I suspect that your solution of using a different library name is actually best practice. :( ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Hi, I have managed to get passed the first hurdle by renaming my custom library and then editing all the statements declaring functions to be imported from my custom library. My code now reports correct version and source_id values, and can create the intended geopoly tables. I am pleased about this, although still puzzled by the fact that the windows LoadLibrary call returned a non null pointer and windows help file implies that it is ok for multiple copies of same name libraries to be loaded together. Also, by checking, I found that my Bricscad application (latest version) contains the exact same older version 3.8.5 that my vba code ended up hooking into. I will discuss this with them, but perhaps the problem arose because vba runs in the same 64-bit process as their application. Thanks to all who responded to my posts. regards, Graham On 01-11-2018 1:03 am, Dominique Devienne wrote: On Wed, Oct 31, 2018 at 12:51 PM Graham Holden wrote: > 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.Speculating somewhat: Have you tried updating the copy Briscad is using? If one version is already in memory, you _may_ have problems persuading Windows to load a different version, and -- even if you can -- I've a feeling that SQLite might not like that.Graham. From past discussions on this list, I remember that loading SQLite several times in the same process, even with renamed symbols, would be problematic on Posix system, because SQLite uses a "singleton" of some kind (as a workaround for broken POSIX semantic around file IO if I recall correctly). But on Windows, there was no such restriction that I can recall. Dan or Richard can probably shed more light on this. Seems like Graham already has a custom build, so renaming the symbols sounds possible at least. FWIW. --DD ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
On Wed, Oct 31, 2018 at 12:51 PM Graham Holden wrote: > > 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.Speculating > somewhat: Have you tried updating the copy Briscad is using? If one version > is already in memory, you _may_ have problems persuading Windows to load a > different version, and -- even if you can -- I've a feeling that SQLite > might not like that.Graham. > From past discussions on this list, I remember that loading SQLite several times in the same process, even with renamed symbols, would be problematic on Posix system, because SQLite uses a "singleton" of some kind (as a workaround for broken POSIX semantic around file IO if I recall correctly). But on Windows, there was no such restriction that I can recall. Dan or Richard can probably shed more light on this. Seems like Graham already has a custom build, so renaming the symbols sounds possible at least. FWIW. --DD ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
> 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.Speculating > somewhat: Have you tried updating the copy Briscad is using? If one version > is already in memory, you _may_ have problems persuading Windows to load a > different version, and -- even if you can -- I've a feeling that SQLite might > not like that.Graham. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Hi, and thanks for the suggestion. I am familiar with the vbRichClient solution. There are also odbc drivers that are free to use but in the end I am looking for system that has to work as 64 bit inside 64-bit Autocad where vba runs in-process. The system that I am using seems ideal in that I can build my custom library to include the geopoly module and that of course doesnt get enabled in the standard releases from the sqlite.org site. See my reply to Richard Hipp's message. Once I overcome the problem and get my custom library loaded I expect to make good progress. regards, Graham On 31-10-2018 12:35 am, Vladimir Vissoultchev wrote: You can try some other sqlite wrapper for VBA, for instance vbRichClient ships with 3.24 -- http://www.vbrichclient.com/#/en/Downloads.htm Unfortunately as it's primary target is VB6 the stdcall port of sqlite is compiled to x86 binary only. cheers, -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Graham Hardman Sent: Tuesday, October 30, 2018 11:49 AM To: SQLite mailing list Subject: [sqlite] curious discovery about geopoly module Hi everybody, regarding the geopoly module in version 3.25.2 a couple of weeks ago I wrote about the fact that the 'pragma compile_options' command failed to display when I was trying to check that my special build of the sqlite dll library and the command line shell was working corrrectly. Richard Hipp's reply was to announce that he had forgotten to fully broadcast the new module to the rest of the code. Fair enough i thought, since i was still able to test out my ideas using the shell interface and in my SQLiteExpert program on my windows 10 pc. Since my previous message I have been doing some tests in 64-bit vba by adapting code released on github by Govert: SQLiteForExcel [1] It has been performing well except that, to my great surprise I have been unable to get it to create a virtual table using geopoly. Tonight I have documented this in a module that runs some general tests that all succeed (creating normal tables, inserting records, and querying the results. A simple Rtree virtual table was also part of the testing). The final part of my testing was to try to create a geopoly vitual table. The prepared statement succeeded, but the step process failed - returning 1. The extended error code was also 1, and the error message was "no such module: geopoly" I guess that makes sense in one way, but it begs the question of why the shell and my version of SQLiteExpert find a way to understand what is required. In the meantime it seems I shall have to suspend my vba coding until the next release where hopefully the above issue will be fixed. I can provide my code and the library if wished. The last few lines from my debug printing to the vba intermediate window is pasted below: --begin test with a simple geopoly virtual table opening an in memory database SQLite3Open returned 0 open the rtree virtual table sqlcmd is: 'create virtual table newtab using geopoly(a,b,c)' SQLite3PrepareV2 returned 0 SQLite3Step failed returning 1 Extended error code is: 1 Extended error message is: no such module: geopoly SQLite3Finalize returned 1 forced to abandon testing since geopoly table could not be created- assertion documented Regards, Graham Hardman. Links: -- [1] https://github.com/govert/SQLiteForExcel ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
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 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
Re: [sqlite] curious discovery about geopoly module
select sqlite_source_id(); both where it works and where it doesn't. Are they the same or different? --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Graham Hardman >Sent: Tuesday, 30 October, 2018 05:25 >To: SQLite mailing list >Subject: Re: [sqlite] curious discovery about geopoly module > >To clarify: I built my own versions of the library and shell using >the >latest amalgamation (3.25.2) specifically to test the geopoly >capability. The build process completed successfully with no error >code, >and as I said allow me to create tables and use the geopoly >functionality in the command shell and sqliteexpert. > >the vba module for 64 bit windows does not need the stdcall library >offered on the github site. > >Thanks, > >Graham > >On 31-10-2018 12:13 am, Clemens Ladisch wrote: >> Graham Hardman wrote: >>> SQLiteForExcel [1] https://github.com/govert/SQLiteForExcel >> >> "sqlite3.dll is a copy of SQLite version 3.11.1" >> >>> "no such module: geopoly" >>> >>> I guess that makes sense in one way, but it begs the question of >why >>> the >>> shell and my version of SQLiteExpert find a way to understand what >is >>> required. >> >> Because they updated their copy of SQLite more recently than three >> years ago. >> >> >> Regards, >> Clemens >> ___ >> sqlite-users mailing list >> sqlite-users@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite- >users >___ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
You can try some other sqlite wrapper for VBA, for instance vbRichClient ships with 3.24 -- http://www.vbrichclient.com/#/en/Downloads.htm Unfortunately as it's primary target is VB6 the stdcall port of sqlite is compiled to x86 binary only. cheers, -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Graham Hardman Sent: Tuesday, October 30, 2018 11:49 AM To: SQLite mailing list Subject: [sqlite] curious discovery about geopoly module Hi everybody, regarding the geopoly module in version 3.25.2 a couple of weeks ago I wrote about the fact that the 'pragma compile_options' command failed to display when I was trying to check that my special build of the sqlite dll library and the command line shell was working corrrectly. Richard Hipp's reply was to announce that he had forgotten to fully broadcast the new module to the rest of the code. Fair enough i thought, since i was still able to test out my ideas using the shell interface and in my SQLiteExpert program on my windows 10 pc. Since my previous message I have been doing some tests in 64-bit vba by adapting code released on github by Govert: SQLiteForExcel [1] It has been performing well except that, to my great surprise I have been unable to get it to create a virtual table using geopoly. Tonight I have documented this in a module that runs some general tests that all succeed (creating normal tables, inserting records, and querying the results. A simple Rtree virtual table was also part of the testing). The final part of my testing was to try to create a geopoly vitual table. The prepared statement succeeded, but the step process failed - returning 1. The extended error code was also 1, and the error message was "no such module: geopoly" I guess that makes sense in one way, but it begs the question of why the shell and my version of SQLiteExpert find a way to understand what is required. In the meantime it seems I shall have to suspend my vba coding until the next release where hopefully the above issue will be fixed. I can provide my code and the library if wished. The last few lines from my debug printing to the vba intermediate window is pasted below: --begin test with a simple geopoly virtual table opening an in memory database SQLite3Open returned 0 open the rtree virtual table sqlcmd is: 'create virtual table newtab using geopoly(a,b,c)' SQLite3PrepareV2 returned 0 SQLite3Step failed returning 1 Extended error code is: 1 Extended error message is: no such module: geopoly SQLite3Finalize returned 1 forced to abandon testing since geopoly table could not be created- assertion documented Regards, Graham Hardman. Links: -- [1] https://github.com/govert/SQLiteForExcel ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
On 10/30/18, Graham Hardman 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. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
To clarify: I built my own versions of the library and shell using the latest amalgamation (3.25.2) specifically to test the geopoly capability. The build process completed successfully with no error code, and as I said allow me to create tables and use the geopoly functionality in the command shell and sqliteexpert. the vba module for 64 bit windows does not need the stdcall library offered on the github site. Thanks, Graham On 31-10-2018 12:13 am, Clemens Ladisch wrote: Graham Hardman wrote: SQLiteForExcel [1] https://github.com/govert/SQLiteForExcel "sqlite3.dll is a copy of SQLite version 3.11.1" "no such module: geopoly" I guess that makes sense in one way, but it begs the question of why the shell and my version of SQLiteExpert find a way to understand what is required. Because they updated their copy of SQLite more recently than three years ago. Regards, Clemens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] curious discovery about geopoly module
Graham Hardman wrote: > SQLiteForExcel [1] https://github.com/govert/SQLiteForExcel "sqlite3.dll is a copy of SQLite version 3.11.1" > "no such module: geopoly" > > I guess that makes sense in one way, but it begs the question of why the > shell and my version of SQLiteExpert find a way to understand what is > required. Because they updated their copy of SQLite more recently than three years ago. Regards, Clemens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] curious discovery about geopoly module
Hi everybody, regarding the geopoly module in version 3.25.2 a couple of weeks ago I wrote about the fact that the 'pragma compile_options' command failed to display when I was trying to check that my special build of the sqlite dll library and the command line shell was working corrrectly. Richard Hipp's reply was to announce that he had forgotten to fully broadcast the new module to the rest of the code. Fair enough i thought, since i was still able to test out my ideas using the shell interface and in my SQLiteExpert program on my windows 10 pc. Since my previous message I have been doing some tests in 64-bit vba by adapting code released on github by Govert: SQLiteForExcel [1] It has been performing well except that, to my great surprise I have been unable to get it to create a virtual table using geopoly. Tonight I have documented this in a module that runs some general tests that all succeed (creating normal tables, inserting records, and querying the results. A simple Rtree virtual table was also part of the testing). The final part of my testing was to try to create a geopoly vitual table. The prepared statement succeeded, but the step process failed - returning 1. The extended error code was also 1, and the error message was "no such module: geopoly" I guess that makes sense in one way, but it begs the question of why the shell and my version of SQLiteExpert find a way to understand what is required. In the meantime it seems I shall have to suspend my vba coding until the next release where hopefully the above issue will be fixed. I can provide my code and the library if wished. The last few lines from my debug printing to the vba intermediate window is pasted below: --begin test with a simple geopoly virtual table opening an in memory database SQLite3Open returned 0 open the rtree virtual table sqlcmd is: 'create virtual table newtab using geopoly(a,b,c)' SQLite3PrepareV2 returned 0 SQLite3Step failed returning 1 Extended error code is: 1 Extended error message is: no such module: geopoly SQLite3Finalize returned 1 forced to abandon testing since geopoly table could not be created- assertion documented Regards, Graham Hardman. Links: -- [1] https://github.com/govert/SQLiteForExcel ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
