Re: [sqlite] forming sqlite3_statements using stored sql

2018-11-01 Thread Jens Alfke
This doesn’t seem very useful for an embedded database engine — the application code owns and creates the database, so it already has those SQL strings; in which case it just seems like extra work to first write them to the DB and then have the DB read them back out again to compile statements.

Re: [sqlite] Bug: float granularity breaking unique contraint?

2018-11-01 Thread David Empson
> On 2/11/2018, at 8:23 AM, James K. Lowden wrote: > > On Wed, 31 Oct 2018 23:05:19 -0300 > Bernardo Sulzbach wrote: > >> So if you are inserting integers >> into a real column, you are going to store integers. However, when you >> select from it they are presented as reals and mix up (looking

Re: [sqlite] Bug: float granularity breaking unique contraint?

2018-11-01 Thread Bernardo Sulzbach
> > I don't think that explanation holds water. > I don't have proof that I am correct, but you can try to test my hypothesis the following way: Let there be 4 databases: -- f1.db create table t(a real unique); insert into t values(9223372036854775807.0); -- f2.db create table t(a real unique);

Re: [sqlite] forming sqlite3_statements using stored sql

2018-11-01 Thread Thomas Kurz
> Rather than inserting the SQL into a user-visible table, it might be preferable to support CREATE PROCEDURE. +1 for that ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] forming sqlite3_statements using stored sql

2018-11-01 Thread James K. Lowden
On Thu, 1 Nov 2018 08:41:51 +0100 Clemens Ladisch wrote: > > It strikes me that this would be nicer if sqlite offered this as > > an intrinsic capability. > > How would SQLite know what the table and column names are? When the SQL is loaded, it can be parsed and analyzed. SQLite could, if

Re: [sqlite] Bug: float granularity breaking unique contraint?

2018-11-01 Thread James K. Lowden
On Thu, 1 Nov 2018 01:18:26 +0100 szmate1618 wrote: > But there seems to be an unintended > workaround > > DROP TABLE IF EXISTS TestReal;CREATE TABLE TestReal(A REAL > UNIQUE);INSERT INTO TestReal values (9223372036854775807);INSERT INTO > TestReal values (9223372036854775807 - 1);INSERT INTO

Re: [sqlite] curious discovery about geopoly module

2018-11-01 Thread Simon Slavin
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

Re: [sqlite] curious discovery about geopoly module

2018-11-01 Thread R Smith
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

Re: [sqlite] curious discovery about geopoly module

2018-11-01 Thread Peter da Silva
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

Re: [sqlite] curious discovery about geopoly module

2018-11-01 Thread Graham Hardman
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

Re: [sqlite] forming sqlite3_statements using stored sql

2018-11-01 Thread Clemens Ladisch
David Fletcher wrote: > create table if not exists StmtSQL ( > StmtNameTEXT NOT NULL UNIQUE, > SQL TEXT NOT NULL); > > The GetPreparedStmt() function retrieves the SQL from table, creates a new > sqlite3_statement object (or retrieves this from a