Re: [sqlite] [EXTERNAL] Either a bug or I don't understand SQL update

You have fallen into the double quote trap. SQLite uses double quotes to denote COLUMN NAMES, and single quotes to delimit STRING CONSTANTS. When asking for "M" or "G", you get the contents of the column named m and g respectively (column names are case insensitive). When asking for "P" or

Re: [sqlite] Documentation misunderstanding or bug (FTS3 and "^" character)?

Hi, yes, but unfortunately I have still a project using FTS3 tables to which I have to add new features.. Regards, Hardy > Am 2019-08-30 um 13:00 schrieb Dan Kennedy : > > > On 30/8/62 17:39, mailing lists wrote: >> Hi, >> >> but there is no token '^beta'! Even if in FTS3 '^' is not

Re: [sqlite] Documentation misunderstanding or bug (FTS3 and "^" character)?

On 30/8/62 17:39, mailing lists wrote: Hi, but there is no token '^beta'! Even if in FTS3 '^' is not regarded as a special character. Is the '^' removed by the tokenizer? Right. It's removed by the tokenizer. FTS3/4 is focused on backwards compatibility. New work should really use FTS5 -

Re: [sqlite] Documentation misunderstanding or bug (FTS3 and "^" character)?

Hi, but there is no token '^beta'! Even if in FTS3 '^' is not regarded as a special character. Is the '^' removed by the tokenizer? Because it is regarded as a diacritical character? PS: I have to admit that I have overlooked the comment that '^' works only for FTS4 tables. Regards, Hardy >

Re: [sqlite] Documentation misunderstanding or bug (FTS3 and "^" character)?

The fts3/4 documentation says: "If the FTS table is an FTS4 table (not FTS3), a token may also be prefixed with a "^" character. In this case, in order to match the token must appear as the very first token in any column of the matching row." So change "FTS3" to "FTS4" and it will likely

Re: [sqlite] divide-by-zero bug in whereLoopAddBtreeIndex function

Hi, Richard: Sorry for that, the poc is attached here. On Thu, Aug 15, 2019 at 9:08 PM Richard Hipp wrote: > The mailing list strips attachments as an anti-spam measure. Please > send the POC directly d...@sqlite.org. > > On 8/15/19, Xingwei Lin wrote: > > Attach is the poc sql file. > > I

Re: [sqlite] divide-by-zero bug in whereLoopAddBtreeIndex function

The mailing list strips attachments as an anti-spam measure. Please send the POC directly d...@sqlite.org. On 8/15/19, Xingwei Lin wrote: > Attach is the poc sql file. > I used the following command: -- D. Richard Hipp d...@sqlite.org ___

Re: [sqlite] Is this a bug?

list Subject: Re: [sqlite] Is this a bug? Your nested select statement wants to return many rows. Technically I think this is illegal SQL (?), but it looks like SQLite is being lax about this as usual and doing what it normally does in this sort of situation: picks a row at random from the inner

Re: [sqlite] Is this a bug?

Your nested select statement wants to return many rows. Technically I think this is illegal SQL (?), but it looks like SQLite is being lax about this as usual and doing what it normally does in this sort of situation: picks a row at random from the inner select. Your statement is more or less

Re: [sqlite] [EXTERNAL] Re: sqlite3_reset() bug?

@mailinglists.sqlite.org Betreff: [EXTERNAL] Re: [sqlite] sqlite3_reset() bug? It doesn't look like my attachment worked, so here is the code: #include #include int main (void) { inti; sqlite3_stmt *stmt = NULL; sqlite3

Re: [sqlite] sqlite3Init null pointer bug

This is an issue with the CLI, not with the SQLite core. It is fixed here: https://www.sqlite.org/src/info/d7f55c62c3fa053b On 1/4/19, Xingwei Lin wrote: > Hi, > > I found a null pointer access problem in *sqlite3Init *function in version > 3.26.0. > > The poc is simple: > >> .open . > >

Re: [sqlite] Default Values Pragma bug

Hello Ryan, Your already moderate complaint needs further moderation After reading https://www.sqlite.org/lang_createtable.html#dfltval I see that the default value may be a function name (when written inside parenthesis) or a special

Re: [sqlite] [EXTERNAL] UNION ALL bug in Multi-threading

] Im Auftrag von Dominique Devienne Gesendet: Mittwoch, 01. August 2018 11:34 An: General Discussion of SQLite Database Betreff: Re: [sqlite] [EXTERNAL] UNION ALL bug in Multi-threading On Wed, Aug 1, 2018 at 10:39 AM Hick Gunter wrote: > Are you sure it is not the special case documented

Re: [sqlite] [EXTERNAL] UNION ALL bug in Multi-threading

On Wed, Aug 1, 2018 at 10:39 AM Hick Gunter wrote: > Are you sure it is not the special case documented in the ATTACH command? > (see https://sqlite.org/lang_attach.html) > Good point. OP will tell us if it applies to his/her case. > " Transactions involving multiple attached databases are

Re: [sqlite] [EXTERNAL] UNION ALL bug in Multi-threading

Are you sure it is not the special case documented in the ATTACH command? (see https://sqlite.org/lang_attach.html) " Transactions involving multiple attached databases are atomic, assuming that the main database is not ":memory:" and the journal_mode is not WAL. If the main database is

Re: [sqlite] Is it a bug or "as designed"?

On 10 Mar 2018, at 7:15am, John Found wrote: > Simon Slavin wrote: > >> On 9 Mar 2018, at 7:49pm, John Found wrote: >> >>> In the current implementation "insert or replace" behave as the foreign >>> constraint is deferred.

Re: [sqlite] Is it a bug or "as designed"?

On Sat, 10 Mar 2018 01:17:38 + Simon Slavin wrote: > On 9 Mar 2018, at 7:49pm, John Found wrote: > > > In the current implementation "insert or replace" behave as the foreign > > constraint is deferred. > > But according to documentation, all

Re: [sqlite] Is it a bug or "as designed"?

On 9 Mar 2018, at 7:49pm, John Found wrote: > In the current implementation "insert or replace" behave as the foreign > constraint is deferred. > But according to documentation, all foreign constraints in SQLite are > immediate by default. John, The documentation

Re: [sqlite] Is it a bug or "as designed"?

On 2018/03/09 9:49 PM, John Found wrote: On Fri, 9 Mar 2018 19:42:19 + Simon Slavin wrote: You are right. And Jay Kreibich in his post above. But then the second solution from my post should be the correct behavior. In the current implementation "insert or replace"

Re: [sqlite] Is it a bug or "as designed"?

> On Mar 9, 2018, at 1:42 PM, Simon Slavin wrote: > > "replace" means "delete the original row, then insert a new one”. More properly, it means “delete any and all rows that might cause any conflict with inserting the new row.” There really isn’t a concept of an

Re: [sqlite] Is it a bug or "as designed"?

On Fri, 9 Mar 2018 19:42:19 + Simon Slavin wrote: > On 9 Mar 2018, at 7:11pm, John Found wrote: > > > "insert or replace" succeed without deleting the old rows from B. > > "replace" means "delete the original row, then insert a new one". > > In

Re: [sqlite] Is it a bug or "as designed"?

On 9 Mar 2018, at 7:11pm, John Found wrote: > "insert or replace" succeed without deleting the old rows from B. "replace" means "delete the original row, then insert a new one". In your code, figure out whether you need INSERT or UPDATE, and do the appropriate one.

Re: [sqlite] Is it a bug or "as designed"?

Foreign keys enforcement can get tricky depending on the enforcement policy, transactions, and a lot of things. I don’t have enough experience to comment on that fully. I will say this, however, because it is a common mistake with a lot of different aspects of database behavior:

Re: [sqlite] Minor JSON output bug (infinity)

On Mon, Jan 22, 2018 at 6:00 PM, Alexander Beedie < alexander.m.bee...@gmail.com> wrote: > Test-case / repro: > “SELECT JSON_ARRAY(1e,-1e,NULL)” > > Actual output: > ‘[Inf,-Inf,null]’ > > Expected output: > ‘[Infinity,-Infinity,null]’ > > All JSON parsers I have tried fail on “Inf”, but

Re: [sqlite] Minor JSON output bug (infinity)

RFC 8259 states: > Numeric values that cannot be represented in the grammar below (such as > Infinity and NaN) are not permitted. This is one of the cases that expose the fallacy of the "JS" part of "JSON". While SQLite should not be producing Inf as a bare word, it should not be producing

Re: [sqlite] Minor JSON output bug (infinity)

On 1/22/18, Alexander Beedie wrote: > Test-case / repro: > “SELECT JSON_ARRAY(1e,-1e,NULL)” > > Actual output: > ‘[Inf,-Inf,null]’ > > Expected output: > ‘[Infinity,-Infinity,null]’ > > All JSON parsers I have tried fail on “Inf”, but the majority will

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

Hello, On 2018-01-03 01:44, Cezary H. Noweta wrote: MySQL has a separator specified by a distinct clause. I'm sorry -- I meant ``distinct'' == ``separate/different'' (a clause named ``SEPARATOR''). Not to be confused with ``DISTINCT'' clause in SQLite's ``group_concat(DISTINCT...)''. --

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

Scott. I almost forgot about this example. Consider group_concat's orthogonal function group_replace. I adapted this from SQLite replace and group_concat. The author disclaims all rights to the following code: --- struct StrRepl { const unsigned char* zStr; u32 nStr; u8

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

On Tue, Jan 2, 2018 at 5:46 PM, petern wrote: > Hi Scott. > >>Are there other aggregate functions that take multiple arguments? > > Absolutely. I've got a few in my code which deserialize table rows into > runtime objects. Fortunately, the DISTINCT filter makes no

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

Hi Scott. >Are there other aggregate functions that take multiple arguments? Absolutely. I've got a few in my code which deserialize table rows into runtime objects. Fortunately, the DISTINCT filter makes no sense in that use case, so I didn't bump into this issue myself. If you're looking

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

Hello, On 2018-01-03 00:02, Tony Papadimitriou wrote: MySQL does not seem to have a problem with it. MySQL has a separator specified by a distinct clause. In SQLite it is specified by a second expression, which, in a canonical and intuitive point of view, is a constant string. However it

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

On Tue, Jan 2, 2018 at 4:15 PM, petern wrote: > Hi Tony. Good. Yes, simpler test case is always better when posting > possible bugs. > > Unfortunately, as Cezary points out, this error is by design (from > select.c): > >if( pFunc->iDistinct>=0 ){ > Expr *pE

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

Hi Tony. Good. Yes, simpler test case is always better when posting possible bugs. Unfortunately, as Cezary points out, this error is by design (from select.c): if( pFunc->iDistinct>=0 ){ Expr *pE = pFunc->pExpr; assert( !ExprHasProperty(pE, EP_xIsSelect) ); if(

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

MySQL does not seem to have a problem with it. -Original Message- From: Scott Robison On Tue, Jan 2, 2018 at 1:36 PM, Tony Papadimitriou wrote: create table t(s); insert into t values ('A'),('A'),('B'); select group_concat(s,', ') from t group by null; --

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

Even simpler, then... select group_concat(distinct 1,','); -Original Message- From: petern Simpler one line test case also parses incorrectly: WITH t(c) AS (VALUES (1)) SELECT group_concat(DISTINCT c) FROM t; "group_concat(DISTINCT c)" 1 WITH t(c) AS (VALUES (1)) SELECT

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

Hello, On 2018-01-02 22:39, Scott Robison wrote: On Tue, Jan 2, 2018 at 1:36 PM, Tony Papadimitriou wrote: create table t(s); insert into t values ('A'),('A'),('B'); select group_concat(s,', ') from t group by null; -- OK select group_concat(distinct s) from t group

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

Simpler one line test case also parses incorrectly: WITH t(c) AS (VALUES (1)) SELECT group_concat(DISTINCT c) FROM t; "group_concat(DISTINCT c)" 1 WITH t(c) AS (VALUES (1)) SELECT group_concat(DISTINCT c,',') FROM t; Error: DISTINCT aggregates must have exactly one argument On Tue, Jan 2, 2018

Re: [sqlite] GROUP_CONCAT with DISTINCT bug

On Tue, Jan 2, 2018 at 1:36 PM, Tony Papadimitriou wrote: > create table t(s); > insert into t values ('A'),('A'),('B'); > > select group_concat(s,', ') from t group by null; -- OK > select group_concat(distinct s) from t group by null; -- OK > select

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Thank you Peter! I like sqlite so much and I think we all benefit if errors are fixed. I see I was not very clear with my first post. Will do better next time. Yes would be nice if people would try to understand first not just think on title text. Talking about sqlite I use it for web

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Radovan. Thank you for sticking to your guns. Your appeal to expected behavior under other DB engines was also a very good post. I see the usual suspects of the echo chamber uselessly piled on against you to clog the forum nevertheless. That happens too frequently. BTW, here is a simpler test

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Thank you Klaus! Klaus Maas je 22.12.2017 ob 20:30 napisal: Radovan is correct. Executing the same command sequence in version 3.11.0 and 3.21.0 results in different column names for table test2. (Xubuntu 16.04 with sqlite3.11.0 and sqlite3.21.0) I marked the results with '<=' Klaus

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

THANK YOU! Richard Hipp je 22.12.2017 ob 20:29 napisal: Your trouble ticket is here: https://sqlite.org/src/tktview/3b4450072511 ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Radovan is correct. Executing the same command sequence in version 3.11.0 and 3.21.0 results in different column names for table test2. (Xubuntu 16.04 with sqlite3.11.0 and sqlite3.21.0) I marked the results with '<=' Klaus SQLite version 3.11.0 2016-02-15 17:29:24 Enter ".help" for usage

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Your trouble ticket is here: https://sqlite.org/src/tktview/3b4450072511 -- 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] Changed behaviour or bug using field alias in 3.21.0

Just try this sql-s: create table test(a int, b int); insert into test values (1,1); select d from (select c as d from (select a as c from test)); will return name d. create table test2 as select d from (select c as d from (select a as c from test)); will create table test2 with column name

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

, 2017 1:45 PM To: SQLite mailing list Subject: Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0 On 12/22/17, Radovan Antloga <radovan.antl...@siol.net> wrote: In my example I have AS clause so rule 1. You did not understand my question. I think what you are asking for is t

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

On 12/22/17, Radovan Antloga wrote: > My point is you do not have to change anything regards > to how select works. SELECT statement is working just > great or OK or fine. > > CREATE TABLE AS > SELECT > > does not give same name as SELECT does. > > SELECT give name

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Correct. -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Richard Hipp Sent: Friday, December 22, 2017 1:45 PM To: SQLite mailing list Subject: Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0 On 12/22/17, Radovan

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

My point is you do not have to change anything regards to how select works. SELECT statement is working just great or OK or fine. CREATE TABLE AS SELECT does not give same name as SELECT does. SELECT give name d CREATE TABLE AS SELECT create table with name a instead of d. Richard Hipp

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

On 12/22/17, Radovan Antloga wrote: > In my example I have AS clause so rule 1. You did not understand my question. I think what you are asking for is that we should enhance rule 1 so that it applies even if the AS clause is contained within a subquery. -- D. Richard

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

In my example I have AS clause so rule 1. sqlite select statement is correct or name is correct. sqlite create table as statement create table with different name that select statement return Problem is different result or name. Richard Hipp je 22.12.2017 ob 19:27 napisal: These are the

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

These are the rules that SQLite uses to name a column in the result set: (1) If there is an AS clause, use it. (2) If the result-set value comes from a table column (even indirectly, such as through a subquery, but not if the value is altered by an expression) then use the name of the column as

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Just tried my example with PostgreSQL that have create table as statement. It work as expected. It creates table test2 with column name d. sqlite3 creates table with column name a. sqlite3 try to mimic postgresql but in this example is not. Simon Slavin je 22.12.2017 ob 17:58 napisal: On 22

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

What? I have to write select d as d. You are not serious. You dont understand what I wrote. I get select correct but create table as does not have same name as select has. Why different result? If select gives some name I don't care what I expect create table as give me same name. Is this so

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

t. I definitely don't want to have to do queries in the form of "select foo as foo, bar as bar, baz as baz..." -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin Sent: Friday, December 22, 2017 11:34 AM To: SQLite mailing

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

ite.org] On Behalf Of Simon Slavin Sent: Friday, December 22, 2017 11:34 AM To: SQLite mailing list Subject: Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0 On 22 Dec 2017, at 3:04pm, Tim Streater <t...@clothears.org.uk> wrote: > 2) I don't see this issue mentioned

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

On 22 Dec 2017, at 4:50pm, Radovan Antloga wrote: > select d from (select c AS d from (select a AS c from test)); > > I get d as column name. If I create table with > create table as I get a as column name. As I wrote, you did not specify AS for d, so you cannot

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Sorry but this is not related to my example. I have AS in inner select. My select return name as specified. Problem I have is with create table as where name is changed. I give example like this: select d from (select c AS d from (select a AS c from test)); I get d as column name. If I create

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

On 22 Dec 2017, at 3:04pm, Tim Streater wrote: > 2) I don't see this issue mentioned when I read the PHP documentation about > their SQLite interface, nor do I see it in the Xojo docs about *their* > interface either. I assume their interfaces are not rewriting SELECT

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

On 22 Dec 2017, at 09:57, Hick Gunter wrote: > The problem lies in your reliance on unspecified behaviour. Unspecified > behaviour is allowed to change. > > I am sure you have read (and ignored) the following guarantee taken from > http://sqlite.org/c3ref/column_name.html : My

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

Behaviour is not consistent when using create table as or just select statement. Try this simple test. create table test(a int, b int); insert into test values (1, 1); select d from (select c as d from (select a as c from test)); you get column name d as expected but when you have create table

Re: [sqlite] Changed behaviour or bug using field alias in 3.21.0

The behavior change is a bug fix. See http://sqlite.org/src/info/de3403bf5ae for details. On 12/21/17, Radovan Antloga wrote: > I have table (create statement): > > CREATE TABLE SOPP1 ( >STAT varchar(1) collate systemnocase, >RID varchar(2) collate

Re: [sqlite] Is this a bug with expression evaluation?

Tony Papadimitriou wrote: > I really don't know what the standard says, but here are two different > opinions in implementation. > > MySQL example: You know that the "SQL" in "MySQL" is actually the abbreviation of "something quite loose"? ;-) Anyway, it appears even MySQL conforms to SQL-92

Re: [sqlite] Is this a bug with expression evaluation?

On 12/14/17, 12:08 PM, "sqlite-users on behalf of Simon Slavin" wrote: > Just to remind you that if something is not documented it can change. The > next version of SQLite might decide that 1 / 2 is 0. So don’t

Re: [sqlite] Is this a bug with expression evaluation?

On 12/14/17, Tony Papadimitriou wrote: > > MySQL example: > mysql> select 1/2; > ++ > | 1/2| > ++ > | 0.5000 | > ++ > 1 row in set (0.13 sec) MySQL is the only database engine that behaves this way. All others do integer arithmetic on integer values.

Re: [sqlite] Is this a bug with expression evaluation?

On 14 Dec 2017, at 5:03pm, Tony Papadimitriou wrote: > SQLite3 (https://sqlite.org/datatype3.html) -- "Otherwise, an expression has > no affinity. " > It seems that 'no affinity' gets translated to integer affinity, then. Just to remind you that if something is not documented

Re: [sqlite] Is this a bug with expression evaluation?

-Original Message- From: J. King Someone please correct me if I'm wrong, but I believe it's mandated by the SQL standard that integer division is used when both operands are integers. I really don't know what the standard says, but here are two different opinions in implementation.

Re: [sqlite] Is this a bug with expression evaluation?

Someone please correct me if I'm wrong, but I believe it's mandated by the SQL standard that integer division is used when both operands are integers. Your synthetic example doesn't use a fixed table, but if it did the easiest solution for you would probably be to define any columns where you

Re: [sqlite] Is this a bug with expression evaluation?

I just multiply by 1.0 Select column1*(column2 * 1.0 / column3)... Removing the parentheses only provide the correct results in your example. It's still using integer math, it's just performing the multiply first, as per order of operations. -Original Message- From: sqlite-users

Re: [sqlite] Possible thread-safety bug in lemon parser with ParseTrace()

On 9/7/17, Fletcher T. Penney wrote: > 1) I hope I am reporting this to the right place. If not, my apologies. > > 2) I have been using lemon parsers for a year or more, but am by no > means an export on the lemon source itself. I did not see this issue >

Re: [sqlite] [EXTERNAL] Re: SQLITE bug

linglists.sqlite.org Betreff: [EXTERNAL] Re: [sqlite] SQLITE bug On 9/3/17 10:16 AM, Joseph L. Casale wrote: -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of R Smith Sent: Sunday, September 3, 2017 7:51 AM To: sqlite-users@mailinglists.sq

Re: [sqlite] [EXTERNAL] Re: SQLITE bug

:13 An: sqlite-users@mailinglists.sqlite.org Betreff: [EXTERNAL] Re: [sqlite] SQLITE bug On 9/3/17 10:16 AM, Joseph L. Casale wrote: > -Original Message- > From: sqlite-users > [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of R > Smith > Sent: Sunday, September

Re: [sqlite] 3.19.3 README.md Doc bug

I see. Replacing sqlite.tar.gz by sqlite-autoconf-3190300.tar.gz likewise produces the immediate directory 'sqlite-autoconf-3190300' rather than 'sqlite'. Taken literally, the instructions are indeed correct. I presumed, evidently incorrectly, that it would be preferrable to start in the

Re: [sqlite] 3.19.3 README.md Doc bug

On Wed, Jun 14, 2017 at 10:40 AM, petern wrote: > Was there a version in the past where the compile instructions made sense? > > tar xzf sqlite.tar.gz;# Unpack the source tree into "sqlite" > mkdir bld;# Build will occur in a

Re: [sqlite] tclsqlite 64-bit bug [Was: extension to run bash]

There are a couple more cases of Tcl_AppendResults( ..., 0) in tclsqlite.c Unfortunately, Tcl_AppendResults() is defined as having varargs and thus lacking type checking. I would prefer NULL over (char*)0 anyway, which BTW is also present at least once in tclsqlite.c -Ursprüngliche

Re: [sqlite] A possible double bug?

> On Oct 17, 2016, at 2:12 AM, Quan Yong Zhai wrote: > > Or after prepare “ INSERT INTO test VALUES(?) “ > Bind_text “62.027393” > Bind_double 62.027393 > > In all the four situation, the value insert into foo field is binary > identical, it’s a 8-bytes REAL value.

Re: [sqlite] A possible double bug?

(62.027393, 'real') or is one getting a real type and one getting a text type? -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Quan Yong Zhai Sent: Monday, October 17, 2016 5:13 AM To: Keith Medcalf; SQLite mailing list Subject: R

Re: [sqlite] A possible double bug?

On 10/17/2016 08:29 AM, Quan Yong Zhai wrote: "The database file format is cross-platform - you can freely copy a database between 32-bit and 64-bit systems or between big-endian and little-endian architectures. Quote: "In your machine, implementation, and SQLite installation the two value

Re: [sqlite] A possible double bug?

in others it may not be." Does it mean the promise about cross-platform is broken? 发件人: Bernardo Sulzbach<mailto:mafagafogiga...@gmail.com> 发送时间: ‎2016/‎10/‎17 17:19 收件人: sqlite-users@mailinglists.sqlite.org<mailto:sqlite-users@mailinglists.sql

Re: [sqlite] A possible double bug?

On 10/17/2016 07:12 AM, Quan Yong Zhai wrote: I can’t reproduce the problem, As it has already been pointed out, this is normal for floating point arithmetic. In your machine, implementation, and SQLite installation the two value representations may be identical, while in others it may not

Re: [sqlite] A possible double bug?

I can’t reproduce the problem, http://sqlite.org/datatype3.html#type_affinity “When text data is inserted into a NUMERIC column, the storage class of the text is converted to INTEGER or REAL (in order of preference) if such conversion is lossless and reversible” So after “create table test

Re: [sqlite] A possible double bug?

I’d say the mistake here is converting a double to a string before inserting it into the database. Any time you convert between floating point and decimal (or vice versa) you can lose accuracy, and are not guaranteed round-trip fidelity. (0.1, 0.01, 0.001, etc. do not have finite-length exact

Re: [sqlite] A possible double bug?

On Sunday, 16 October, 2016 12:03, Victor Evertsson wrote: > I was wondering about the different behavior of inserting a Double as a > String vs as a value with a prepare statement in C. > Consider an example when the value: 62.027393 is inserted as a String and >

Re: [sqlite] Strange problem (pehaps bug) with sqlite + json

On Fri, Sep 23, 2016 at 11:58 AM, Hick Gunter wrote: > SQLite evaluates the WHERE clause from left to right, which means it needs > to evaluate xyz and thereby call json_extract first, even before it can > determine that no rows match the second condition. > > Maybe the

Re: [sqlite] Strange problem (pehaps bug) with sqlite + json

uot; first? -Ursprüngliche Nachricht- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Dan Kennedy Gesendet: Freitag, 23. September 2016 11:28 An: sqlite-users@mailinglists.sqlite.org Betreff: Re: [sqlite] Strange problem (pehaps bug) with sqlite + json

Re: [sqlite] Strange problem (pehaps bug) with sqlite + json

On 09/23/2016 03:09 PM, Gilles Vollant wrote: With sqlite.exe from tools zipfile, I reproduce the bug with this script: If I add, just after the create table the line create index if not exists idxtype on records(activitytype); I have a correct result If I don't add the index, I've

Re: [sqlite] Strange problem (pehaps bug) with sqlite + json

With sqlite.exe from tools zipfile, I reproduce the bug with this script: If I add, just after the create table the line create index if not exists idxtype on records(activitytype); I have a correct result If I don't add the index, I've "malformed json" error. Can you try reproduce?

Re: [sqlite] Strange problem (pehaps bug) with sqlite + json

On 9/20/16, Richard Hipp wrote: > Maybe don't double the double-quotes. JSON expects just a single > double-quote a either end of a string. The tools I user (sqlite explorer) wanted it. And after I do update records set message=replace(message,'""','"'); So there is NO double quote in the

Re: [sqlite] Strange problem (pehaps bug) with sqlite + json

On 9/20/16, Gilles Vollant wrote: > > delete from records; > insert into records values (1,'2016-09-01',22,'{""Date"":""09/01/2016 > 02:00:00"",""CountAnalyzedMails"":44} '); Maybe don't double the double-quotes. JSON expects just a single double-quote a either end of a

Re: [sqlite] Report a warning bug about Lemon parser

On 1/22/15, Tang Tianyong wrote: > Hi, yy_destructor function can not suppress warning about unused > %extra_argument variable. Sure it can. Just add code to one of your destructors that references the %extra_argument variable. It doesn't have to actually do anything with the

Re: [sqlite] Sqlite problem possible bug

On 2015/01/07 12:13, The Responsa Project wrote: To Whom it amy concern I am trying to use SQLITE and the like statement with wildcards and hebrew when I put in an english string it works correctly, such as Select * from dbname where colname like '%123%' I will get all the entries from

Re: [sqlite] Sqlite problem possible bug

On 1/7/15, The Responsa Project wrote: > To Whom it amy concern > > > I am trying to use SQLITE and the like statement with wildcards and hebrew > > when I put in an english string it works correctly, such as > > Select * from dbname where colname like '%123%' > > I will

Re: [sqlite] Sqlite problem possible bug

How about to use dynamic binding? For example, is your SQL(SELECT * from dbname where colname like '%אב%'), use '?' instead of 'אב'. In my guess, 'אב' can have same ASCII code of wildcard(%). Full SQL can be as like as follows. SELECT * from dbname where colname like '%?%' To do this, you need

Re: [sqlite] Is this a bug? autoincrement in int primary key vs integer primary key

Thanks for the link Bernard Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for SQLite http://sandersonforensics.com/forum/content.php?168-Reconnoitre -

Re: [sqlite] Is this a bug? autoincrement in int primary key vs integer primary key

You are supposing that INT PRIMARY KEY == INTEGER PRIMARY KEY. Which, clearly, is not true. http://stackoverflow.com/questions/20289410/difference-between-int-primary-key-and-integer-primary-key-sqlite see this link for more on the subject. 2014-11-16 13:56 GMT-02:00 Igor Tandetnik

Re: [sqlite] Is this a bug? autoincrement in int primary key vs integer primary key

On 11/16/2014 10:51 AM, Paul Sanderson wrote: AUTOINCREMENT is only allowed on an INTEGER PRIMARY KEY No it's not a bug. AUTOINCREMENT is only allowed on INTEGER PRIMARY KEY. Which part of the error message do you find unclear? For details, see http://www.sqlite.org/autoinc.html

Re: [sqlite] Is it a bug ?

On 6 Nov 2014, at 3:13am, Andrei Yakimov wrote: > Problem is incorrect journal file, which is created on system reboot. > Reproduce this condition relativity simple: > > step 1: we open db > step 2: write/update something to db. > step 3: switch journal to memory > step 4:

Re: [sqlite] Curious datetime/strftime BUG?

On 6/10/2014 18:35, Clemens Ladisch wrote: John wrote: On 5/10/2014 19:59, Clemens Ladisch wrote: The documentation says: | These functions only work for dates between -01-01 00:00:00 and | -12-31 23:59:59. For dates outside that range, the

Re: [sqlite] Curious datetime/strftime BUG?

John wrote: > On 5/10/2014 19:59, Clemens Ladisch wrote: >> The documentation says: >> | These functions only work for dates between -01-01 00:00:00 and >> | -12-31 23:59:59. For dates outside that range, the results of >> | these functions are

Re: [sqlite] Curious datetime/strftime BUG?

Sorry Clemens, but you have missed the point, the point being that the year component of the date string returned by strftime for -ve (or BCE) years are truncated to the -ve sign + the first three digits of the year. This is not the case for the result returned by date or datetime, which

  1   2   3   >