Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

I just want to point something out that might help the original poster. On Saturday, March 7, 2020, 7:00:21 AM EST, sqlite-users-requ...@mailinglists.sqlite.org wrote: > > 1.  NULL is NULL = Yes, True, > 2.  NULL is FALSE = Nope, False. > 3.  NULL is TRUE  = Nope, False. > 4.  NULL is NO

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 2020/03/07 03:52, Xinyue Chen wrote: Hi, If I change IS NOT FALSE to IS TRUE, the results will be different. I assume they should perform in the same way? if you say "NULL IS NOT FALSE" is always true, then 'NULL IS TRUE' should also be always true. Then why doesn't that query also return 4 r

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 3/6/20 9:54 PM, Keith Medcalf wrote: On Friday, 6 March, 2020 19:25, Richard Damon wrote: It is sort of like NaN, where a Nan is neither less than, greater than or equal to any value, including itself. NULL (as in SQL NULL) means "missing value" or "unknown". NULL represents any value wi

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On Friday, 6 March, 2020 19:25, Richard Damon wrote: >It is sort of like NaN, where a Nan is neither less than, greater than >or equal to any value, including itself. NULL (as in SQL NULL) means "missing value" or "unknown". NULL represents any value within the domain, we simply do not know w

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 3/6/20 9:00 PM, Simon Slavin wrote: On 7 Mar 2020, at 1:52am, Xinyue Chen wrote: If I change IS NOT FALSE to IS TRUE, the results will be different. I assume they should perform in the same way? No. Because NULL is not TRUE and is not FALSE. SQLite version 3.28.0 2019-04-15 14:49:49 Ente

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 3/6/2020 8:52 PM, Xinyue Chen wrote: If I change IS NOT FALSE to IS TRUE, the results will be different. NULL IS TRUE is always false. NULL IS NOT FALSE is always true. So it's not surprising that the results are different. SQL uses trivalent logic. NULL is neither FALSE nor TRUE. I assu

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 7 Mar 2020, at 1:52am, Xinyue Chen wrote: > If I change IS NOT FALSE to IS TRUE, the results will be different. I > assume they should perform in the same way? No. Because NULL is not TRUE and is not FALSE. SQLite version 3.28.0 2019-04-15 14:49:49 Enter ".help" for usage hints. Connected t

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

> If I change IS NOT FALSE to IS TRUE, the results will be different. I > assume they should perform in the same way? > if you say "NULL IS NOT FALSE" is always true, then 'NULL IS TRUE' should > also be always true. "NULL IS NOT FALSE" is true because NULL is not a value therefor it is not FALSE

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

Hi, If I change IS NOT FALSE to IS TRUE, the results will be different. I assume they should perform in the same way? if you say "NULL IS NOT FALSE" is always true, then 'NULL IS TRUE' should also be always true. Then why doesn't that query also return 4 rows? Thanks! On Fri, Mar 6, 2020 at 5:45

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On Friday, 6 March, 2020 17:48 Xinyue Chen wrote: ... >select t1.textid a, i.intid b > from t t1, > i i > where (t1.textid = i.intid and t1.textid in (12) and t1.textid = i.intid) >or (t1.textid = null IS NOT FALSE) >group by i.intid, t1.textid; I got rid of all the extra brackets

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

Change the "(t1.textid = null)" to "(t1.textid IS NULL)". Null has no value, you have to check for it explicitly. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 3/6/20, Xinyue Chen wrote: > -- Buggy query > select t1.textid a, i.intid b > from t t1, > i i > where (((t1.textid = i.intid) and (t1.textid in (12)) and (t1.textid = > i.intid)) or ((t1.textid = null) IS NOT FALSE)) > group by i.intid, t1.textid; (1) The expression "t1.textid=null" is

Re: [sqlite] bug report (INSTR() ignores NOCASE on columns)

Stephan Senzel, on Sunday, February 2, 2020 08:12 AM, wrote... > > INSTR() ignores NOCASE on columns > > --- > > example: > > SELECT * FROM table WHERE INSTR(column, ' castle ') > 0 > > returns datasets with 'castle' only, without 'Castle', even if the > column is set to NOCASE

Re: [sqlite] Bug report: Potential thread safety issues in sqlite3_initialize

As I understand it, the barrier in that patch ensures that for whichever thread executes the if(!sqlite3GlobalConfig.mutex.xMutexAlloc codepath) {...}, the write to pTo->xMutexAlloc will be stored after the rest of the xMutex* field writes. But there's nothing preventing another thread *loading* th

Re: [sqlite] Bug report: Potential thread safety issues in sqlite3_initialize

On 1/28/20, Oystein Eftevaag wrote: > in sqlite3MutexInit() sqlite3GlobalConfig.mutex.xMutexAlloc > can be read as being set on a core, while the rest of the initialization > done in sqlite3MutexInit() still is being read as unset. Doesn't the memory barrier at https://www.sqlite.org/src/artifact

Re: [sqlite] BUG(?) in FTS5

Hi Jens, the MATCH operator is not inside an OR expression. The MATCH operator is in an AND expression, only the rowid request is in an OR expression. Regards, Hartwig PS: In FTS5 since version 3.30.1 also the MATCH operator is allowed in OR statements (try SELECT PlayersFTS.rowid FROM Players

Re: [sqlite] Bug report

On Jan 23, 2020, at 7:02 AM, Mark Benningfield wrote: > > ...whenever I do a Fossil pull of the latest > version takes a grand total of about 2 seconds, but it would be nice not to > have to remember to do it every time :) If you’re having to reapply the change on every Fossil update, you’re pro

Re: [sqlite] BUG(?) in FTS5

> On Jan 23, 2020, at 6:47 AM, mailing lists wrote: > > The following SELECT statement fails with the error "unable to use function > MATCH in the requested context": This is an annoying but documented limitation of FTS, not a bug. The MATCH operator can’t be used inside an OR expression. It

Re: [sqlite] Bug report

Well, I kinda thought that this would be fixed on the next release. The "value_frombind" typo in particular prevents FTS3/4 from being built as a loadable extension. I only have one legacy application that uses FTS3/4 that way, and fixing these typos whenever I do a Fossil pull of the latest versio

Re: [sqlite] bug on zPath length

On 1/23/20, Ondrej Dubaj wrote: > I discovered an issue found by coverity scan. Thanks for the report. This was previously fixed here: https://www.sqlite.org/src/info/465a15c5c2077011 -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list

Re: [sqlite] Bug fixes only branch.

On 1/13/20, Syed Ahmad wrote: > We are at 3.14.2 > > Current version = 3.14.2 Date : 2016-09-12 > > https://www.sqlite.org/changes.html > > how can i take latest stable branch which include only bug fixes . no new > features. > > Is there any way? We sometimes do things like that for paid support

Re: [sqlite] Bug fixes only branch.

On Monday, 13 January, 2020 15:00, Donald Griggs wrote: >On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad >wrote: >> We are at 3.14.2 Date : 2016-09-12 >> how can i take latest stable branch which include only bug fixes . no >> new features. >> Is there any way? > I may well not be understand

Re: [sqlite] Bug fixes only branch.

On Tue, 14 Jan 2020 at 7:00 am, Donald Griggs wrote: > Hi, Syed, > > === > On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad > wrote: > > > We are at 3.14.2 Date : 2016-09-12 > > > > how can i take latest stable branch which include only bug fixes . no new > > features. >

Re: [sqlite] Bug fixes only branch.

Hi, Syed, === On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad wrote: > We are at 3.14.2 Date : 2016-09-12 > > how can i take latest stable branch which include only bug fixes . no new > features. > > Is there any way? > == I may well not be

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

Hi, On Tue, Jan 7, 2020 at 2:01 AM Clemens Ladisch wrote: > > Richard Hipp wrote: > > On 1/5/20, Keith Medcalf wrote: > >> select * from a, b, c using (id); -- very strange result > > > > PostgreSQL and MySQL process the query as follows: > > > >SELECT * FROM a, (b JOIN c USING(id)); > > > >

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

Richard Hipp wrote: > On 1/5/20, Keith Medcalf wrote: >> select * from a, b, c using (id); -- very strange result > > PostgreSQL and MySQL process the query as follows: > >SELECT * FROM a, (b JOIN c USING(id)); > > SQLite processes the query like this: > >SELECT * FROM (a,b) JOIN c USING (

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

On Sunday, 5 January, 2020 04:42, Richard Hipp wrote: >On 1/5/20, Keith Medcalf wrote: >> Hrm. Inconsistent/incorrect results. Consider: >> create table a(id integer primary key, a); >> insert into a values (1,1), (2,1), (3,1); >> create table b(id integer primary key, b); >> insert into b

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

> On 1/5/20, Keith Medcalf wrote: >> >> Hrm. Inconsistent/incorrect results. Consider: >> >> create table a(id integer primary key, a); >> insert into a values (1,1), (2,1), (3,1); >> create table b(id integer primary key, b); >> insert into b values (1,2), (3,2), (4,2); >> create table c(id int

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

On 1/5/20, Richard Hipp wrote: > > Note that both MySQL and SQLite do allow you to use parentheses, as > shown in my examples, to define the order of evaluation. PostgreSQL > does not, sadly. > Apparently, in PostgreSQL you have to say: SELECT * FROM (SELECT * FROM a, b) AS x JOIN c USING(id

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

On 1/5/20, Keith Medcalf wrote: > > Hrm. Inconsistent/incorrect results. Consider: > > create table a(id integer primary key, a); > insert into a values (1,1), (2,1), (3,1); > create table b(id integer primary key, b); > insert into b values (1,2), (3,2), (4,2); > create table c(id integer prima

Re: [sqlite] Bug Report

Bigthing Do, on Friday, December 27, 2019 01:56 PM, wrote... > > Dear sqlite developers: > > We met an accidental crash in sqlite with the following sample: > > CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 > ) SELECT col2 FROM table1 ORDER BY 1 ; > WITH aaa AS ( SELECT

Re: [sqlite] Bug Report

Hi, We tried debugging a little bit with the core dump, it crashes with a null reference actually: ` Program received signal SIGSEGV, Segmentation fault. [--registers---] RAX: 0x74 ('t') RBX: 0x782550 --> 0x76b088 --> 0x1 RCX: 0x61

Re: [sqlite] Bug Report

On Friday, 27 December, 2019 12:50, Igor Korot wrote: >On Fri, Dec 27, 2019 at 12:57 PM Bigthing Do wrote: >> We met an accidental crash in sqlite with the following sample: >> CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 ) >> SELECT col2 FROM table1 ORDER BY 1 ;

Re: [sqlite] Bug Report

Hi, On Fri, Dec 27, 2019 at 12:57 PM Bigthing Do wrote: > > Dear sqlite developers: > > We met an accidental crash in sqlite with the following sample: > > CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 ) > SELECT col2 FROM table1 ORDER BY 1 ; > WITH aaa AS ( SELECT * F

Re: [sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

On 21 Dec 2019, at 21:42, Michael Walker (barrucadu) wrote: > I'm not sure the attachment to my first email got through ... Correct. The list strips them. -- Cheers -- Tim ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http:/

Re: [sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

The mailing list strips attachments, btw. Anyways, looking at that, yeah, they're all text values: sqlite> SELECT bookIsbn, typeof(bookIsbn) FROM books WHERE bookAuthor LIKE '%Ambrose%'; bookIsbntypeof(bookIsbn) -- 0486280381 text 9781496030 text 9781496030 text

Re: [sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

Hi Shawn, Thanks for your response. Though that doesn't seem to be the case: sqlite> select bookIsbn, typeof(bookIsbn) from books where bookIsbn = "9781496030825"; 9781496030825|text sqlite> select bookIsbn, typeof(bookIsbn) from books where bookIsbn = "9780099477310"; 9780099477310|text The

Re: [sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

Without seeing your table definition, this is just a guess, but maybe the duplicate keys are stored as different types, with the primary key column having an affinity that doesn't force one particular storage class: sqlite> CREATE TABLE test(id PRIMARY KEY); sqlite> INSERT INTO test VALUES('12345'

Re: [sqlite] Bug report: cppcheck memory leak

On 2 Dec 2019, at 1:16am, Richard Hipp wrote: > Telling us that the > "return" from malloc() is a memory leak is not helpful information, > even if it were true. Oh, someone needs to write a story about a manager who doesn't understand computers but relies on test suites, and programmers trying

Re: [sqlite] Bug report: cppcheck memory leak

On 12/1/19, David Brouwer wrote: > While playing around with static code analysis with cppcheck, I ran into > the error "[modules/sqlite3_omit.c:22845]: (error) Memory leak: p". I can't > tell whether it's significant or not, but I figured I'd report it anyway. Thanks for taking the time to repor

Re: [sqlite] Bug report

CVE will not record this bug if it doesn't affect a /released/ version of any product. One hopes that none of the products which incorporate SQLite would incorporate a version of SQLite which never received a release number. In other words, the reporters told the developer team before the bug b

Re: [sqlite] Bug report

On Thu, 21 Nov 2019 21:02:57 +, Jose Isaias Cabrera wrote: >Kees Nuyt, on Thursday, November 21, 2019 03:48 PM, wrote... [...] >> >> I see no CVE entered by the OP, but maybe I missed something. > > Yes, you are right. After pasting it, I went through the top 5 > and none of these aren't/were

Re: [sqlite] Bug report

Kees Nuyt, on Thursday, November 21, 2019 03:48 PM, wrote... > > > Thanks, Jose. > > I see no CVE entered by the OP, but maybe I missed something. Yes, you are right. After pasting it, I went through the top 5 and none of these aren't/weren't the one. Apologies. I thought that by searching on

Re: [sqlite] Bug report

Thanks, Jose. I see no CVE entered by the OP, but maybe I missed something. A quick look to your list : > NameDescription > CVE-2019-9937 > In SQLite 3.27.2, interleaving reads and writes in a single transaction with > an fts5 vi

Re: [sqlite] Bug report

On 11/19/19, Yongheng Chen wrote: > Hi, > > This is Yongheng Chen from Gatech and Rui Zhong from PSU. We found 7 crashes > for sqlite of the newest commit 3842e8f166e23a1ed6e6094105e7a23502d414da. > We have attached the samples that crash sqlite in the email. FYI, we have > also reported the bugs

Re: [sqlite] Bug report

software versions prior to v1.3.4. The underlying SQLite database query is subject to SQL injection on the username input parameter. From: sqlite-users on behalf of Kees Nuyt Sent: Thursday, November 21, 2019 09:51 AM To: sqlite-users@mailinglists.sqlite.org Subj

Re: [sqlite] Bug report

On Tue, 19 Nov 2019 00:19:13 -0500, you wrote: > Hi, > > This is Yongheng Chen from Gatech and Rui Zhong from PSU. > We found 7 crashes for sqlite of the newest commit > 3842e8f166e23a1ed6e6094105e7a23502d414da. > We have attached the samples that crash sqlite in the email. The mailing list st

Re: [sqlite] BUG and WORKAROUND sqlite3 shell .parameter command evaluating arguments when it shouldn't.

I think this is a bug. However, looking at the code the way to achieve that is to surround the string in double quotes which will cause exactly what appears between the double-quotes to be stored. I think it is because of the way the parsing and mprintf function works ... sqlite> .param init

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On Friday, 1 November, 2019 10:20, Simon Slavin wrote: >On 1 Nov 2019, at 4:17pm, Simon Slavin wrote: >WHERE (c1 IS NULL) OR (C1 != 2) > which could quite reasonably return rows. However, the NULL possibility > may be redundant. I can't tell without tests. The expression NOT (c1 IS NOT

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On Friday, 1 November, 2019 09:12, And Clover wrote: > CREATE TABLE t0 (c0); > CREATE TABLE t1 (c1); > INSERT INTO t0 VALUES (1); > SELECT c0 > FROM t0 LEFT JOIN t1 ON c1=c0 > WHERE NOT (c1 IS NOT NULL AND c1=2); >Expected result: (1) >Actual result: no rows retu

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On 01/11/2019 16:20, Simon Slavin wrote: It is actually WHERE (c1 IS NULL) OR (C1 != 2) which could quite reasonably return rows. Yes, and with this OR filter the quoted example does indeed return rows. The version with: WHERE NOT (c1 IS NOT NULL AND c1=2) *should* be equivalent to your

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On 1 Nov 2019, at 4:17pm, Simon Slavin wrote: > This is a cut-down example, right ? You can't possibly mean to do that WHERE > clause in production code. It amounts to > >WHERE (c1 IS NULL) AND (C1 != 2) I'm so sorry. It is actually WHERE (c1 IS NULL) OR (C1 != 2) which could quit

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On 1 Nov 2019, at 3:12pm, And Clover wrote: >WHERE NOT (c1 IS NOT NULL AND c1=2); > > Expected result: (1) > Actual result: no rows returned This is a cut-down example, right ? You can't possibly mean to do that WHERE clause in production code. It amounts to WHERE (c1 IS NULL) A

Re: [sqlite] Bug: Infite loop on SELECT with .explain on

ven says a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users On >Behalf Of Richard Hipp >Sent: Saturday, 26 October, 2019 10:08 >To: SQLite mailing list >Subject: Re: [sqlite] Bug: Infite loop on SELECT with .explain on > >Thanks for the

Re: [sqlite] Bug: Infite loop on SELECT with .explain on

Thanks for the report. This problem is fixed on trunk. To be clear, this is an issue in the "sqlite3" shell command, not in the SQLite core. Also, it is an issue in the deprecated and undocumented ".explain on" command of the shell. Years ago, it used to be necessary to run ".explain on" prior

Re: [sqlite] Bug: WINDOW clause within a CTE

On 15/9/62 11:57, Jake Thaw wrote: The following examples demonstrate a possible bug when using a WINDOW clause within a CTE: SQLite version 3.30.0 2019-09-14 16:44:51 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent data

Re: [sqlite] Bug: LSM1 lsm1BestIndex() always chooses table scan

On 8/16/19, James Kafader wrote: > > We think, after trying out a fix that line 845 of lsm_vtab.c contains a > bug. This line > for(i=0; inConstraint && idxNum<16; i++, pConstraint++){ > should perhaps be replaced by this line: >for(i=0; inConstraint && idxNum>16; i++, pConstraint++){ > Tha

Re: [sqlite] Bug report: crash when close blob handle after close_v2 db

On 14/7/62 17:18, Chaoji Li wrote: This problem is only present for 3.28+. A sample test case is attached. Thanks for reporting this. We think it's fixed here:   https://sqlite.org/src/info/52f463d29407fad6 The mailing list stripped off your test case, so if you could either run it with the

Re: [sqlite] Bug when creating a table via select?

On Mon, Jul 15, 2019 at 6:01 AM J. King wrote: > On July 14, 2019 11:56:15 p.m. EDT, Donald Shepherd < > donald.sheph...@gmail.com> wrote: > >sqlite> create table x(a int, b text, c real, d blob, e vartext, > fgarbage); > >sqlite> pragma table_info(x); > >0|a|int|0||0 > >1|b|text|0||0 > >2|c|real

Re: [sqlite] Bug when creating a table via select?

On July 15, 2019 12:01:00 a.m. EDT, "J. King" wrote: >On July 14, 2019 11:56:15 p.m. EDT, Donald Shepherd > wrote: >>Somewhat bizarrely only "BLOB" affinity doesn't make it from the >>original >>table to the new table when using the "select" syntax to create the >new >>table. Even items with alia

Re: [sqlite] Bug when creating a table via select?

On July 14, 2019 11:56:15 p.m. EDT, Donald Shepherd wrote: >Somewhat bizarrely only "BLOB" affinity doesn't make it from the >original >table to the new table when using the "select" syntax to create the new >table. Even items with aliased affinities (VARTEXT, or something that >defaults to NUME

Re: [sqlite] Bug report: crash when close blob handle after close_v2 db

On 14 Jul 2019, at 11:18am, Chaoji Li wrote: > This problem is only present for 3.28+. A sample test case is attached. Thank you for identifying this behaviour. I'm sure the development team will reply to your post. Attachments are automatically ignored by the mailing list. You can include

Re: [sqlite] Bug in all-bnf.html documentation?

Fantastic, thank you! > On Jul 13, 2019, at 1:48 PM, Richard Hipp wrote: > > On 7/13/19, George King wrote: >> Is there any written description of the Sqlite grammar or is it >> now only described by the images? If nothing else, I'd be interested to peek >> at any sort of grammar representatio

Re: [sqlite] Bug in all-bnf.html documentation?

On 7/13/19, George King wrote: > Is there any written description of the Sqlite grammar or is it > now only described by the images? If nothing else, I'd be interested to peek > at any sort of grammar representation in the source code. The images are the definitive description of the language. T

Re: [sqlite] Bug in all-bnf.html documentation?

Thank you. Is there any written description of the Sqlite grammar or is it now only described by the images? If nothing else, I'd be interested to peek at any sort of grammar representation in the source code. > On Jul 13, 2019, at 12:28 PM, Richard Hipp wrote: > > On 7/13/19, George King wr

Re: [sqlite] Bug in all-bnf.html documentation?

On 7/13/19, George King wrote: > I found > the all-bnf.html page after a quick google search. That file is obsolete cruft in the Fossil repository that hosts the SQLite documentation. The BNF representation has not been supported for years. Shane added that support for us almost 10 years ago, b

Re: [sqlite] Bug in sqlite3.c

I tried "INSERT INTO ft(ft) VALUES('integrity-check')" and it also did not give any error. But the rebuild command helped solve my problem as the crashes stopped, otherwise my application was crashing at every commit operation (thanks a lot for that). Is there any command/API which can bypass FTS5

Re: [sqlite] Bug in sqlite3.c

On 4/6/62 12:11, bhandari_nikhil wrote: Thanks Dan. I had checked the database integrity using the following command: sqlite3 myfile.db "PRAGMA integrity_check;" Try "INSERT INTO ft(ft) VALUES('integrity-check')", where "ft" is the name of the fts5 table. And it had reported ok. I will s

Re: [sqlite] Bug in sqlite3.c

Thanks Dan. I had checked the database integrity using the following command: sqlite3 myfile.db "PRAGMA integrity_check;" And it had reported ok. I will see if I can share the database file here. Can you let me know how to check the db file (in case I am not able to share the db file here) ? And

Re: [sqlite] Bug in sqlite3.c

On 3/6/62 12:51, bhandari_nikhil wrote: I am facing a crash in sqlite3fts5BufferAppendBlob. Following is the backtrace: #0 sqlite3Fts5BufferAppendBlob (pRc=pRc@entry=0xf54139c8, pBuf=pBuf@entry=0xf5afeb90, nData=4294967295, pData=0xf49fff76 "90246ture") at sqlite3.c:180474 #1 0xf717b6f8 in

Re: [sqlite] Bug in sqlite: "View with UNION ALL and limit in subquery" (v 3.28.0)

Thank you for the report. The problem is now fixed on trunk. Ticket: https://www.sqlite.org/src/info/c41afac34f15781f Fix: https://www.sqlite.org/src/info/523b42371122d9e1 On 5/29/19, Marco Foit wrote: > Dear SQLite Developers, > > I just noticed the following bug in SQLite version 3.28.0: > >

Re: [sqlite] bug in sqlite3??

Let's not forget that the size of the database is going to grow above and beyond the "number of rows" due to pages that aren't reserved for your data, such index pages, etc. On Tue, May 28, 2019 at 1:49 PM Jens Alfke wrote: > > > > On May 26, 2019, at 7:21 PM, John Brigham wrote: > > > > The s

Re: [sqlite] bug in sqlite3??

On 28 May 2019, at 6:49pm, Jens Alfke wrote: > Try opening a copy of the database with the `sqlite3` CLI tool and entering > “PRAGMA vacuum;”. Then exit and look at the file size. Alternatively use the sqlite3_analyze tool and read the "Pages on the freelist" figures. _

Re: [sqlite] bug in sqlite3??

> On May 26, 2019, at 7:21 PM, John Brigham wrote: > > The size of the file reflects the number of rows that should be present. And > furthermore, the size of the file nicely reflects the number of days. […] > Trust me when I say that this file is way to big for the number of rows. SQLite

Re: [sqlite] bug in sqlite3??

On 5/26/19, John Brigham wrote: > I have an Arduino/Python experiment that generates lots of simple > numerical data; about 7000 records a day. I run it through Python into an > sqlite3 database.I have been running this for 8 months. I start a new > database about every six weeks so every data

Re: [sqlite] Bug: CTE name leaking through views

I tried it out in trunk and it works for me as well. Thanks for your help! Steve On Wed, May 22, 2019 at 3:50 PM Richard Hipp wrote: > Thanks for the test case. This problem should now be fixed on trunk. > Please try it out and let us know if you encounter any additional > probglems. > > -- >

Re: [sqlite] Bug: sqlite ARM endian problem

On Wed, May 22, 2019 at 03:43:13PM -0400, Richard Hipp wrote: > On 5/22/19, Sebastian Kemper wrote: > > > > Hello Richard, > > > > I have run-tested this with qemu on two targets until now: > > > > arm_arm1176jzf-s_vfp > > armeb_xscale > > > > Both worked fine. Unfortunately I still don't have fee

Re: [sqlite] Bug: CTE name leaking through views

Hi Richard, I just realized I didn't include the mailing list in my previous response to you, so I'm doing that now with the contents of the SQL file I sent you previously. I've also included a copy of my original email in plaintext as the HTML formatted SQL queries got mangled when it was process

Re: [sqlite] Bug: CTE name leaking through views

Thanks for the test case. This problem should now be fixed on trunk. Please try it out and let us know if you encounter any additional probglems. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http

Re: [sqlite] Bug: sqlite ARM endian problem

On 5/22/19, Sebastian Kemper wrote: > > Hello Richard, > > I have run-tested this with qemu on two targets until now: > > arm_arm1176jzf-s_vfp > armeb_xscale > > Both worked fine. Unfortunately I still don't have feedback from the > user. He didn't receive my mail. I've sent it again and will get

Re: [sqlite] Bug: sqlite ARM endian problem

On Mon, May 20, 2019 at 09:10:20PM +0200, Sebastian Kemper wrote: > On Mon, May 20, 2019 at 02:46:47PM -0400, Richard Hipp wrote: > > On 5/20/19, Sebastian Kemper wrote: > > > In OpenWrt's forum a user raised a topic about being unable to use > > > Asterisk on his armeb xscale device. > > > > Plea

Re: [sqlite] Bug: sqlite ARM endian problem

On Mon, May 20, 2019 at 02:46:47PM -0400, Richard Hipp wrote: > On 5/20/19, Sebastian Kemper wrote: > > In OpenWrt's forum a user raised a topic about being unable to use > > Asterisk on his armeb xscale device. > > Please download a tarball of the latest trunk version of SQLite > (check-in https:

Re: [sqlite] Bug: sqlite ARM endian problem

On 5/20/19, Sebastian Kemper wrote: > In OpenWrt's forum a user raised a topic about being unable to use > Asterisk on his armeb xscale device. Please download a tarball of the latest trunk version of SQLite (check-in https://www.sqlite.org/src/info/b7aad929619f7043 or later) and verify that it n

Re: [sqlite] Bug in table_info pragma

Jose Isaias Cabrera, on Friday, May 17, 2019 08:28 AM, wrote... >J. King, on Friday, May 17, 2019 07:19 AM, wrote... >>Perhaps I should have been clearer that this is a regression? >> I know, overkill, but here is another look at it, SQLite version 3.28.0 2019-04-16 19:49:53 Enter ".help" for usa

Re: [sqlite] Bug in table_info pragma

Simon Slavin wrote: > On 17 May 2019, at 1:33pm, Clemens Ladisch wrote: >> This keyword behaves magically. ... as far as the SQL standard is concerned. > Mmmm. In that case, to implement this properly you need to store > a default-type flag alongside the default value. The SQLite syntax diagra

Re: [sqlite] Bug in table_info pragma

On 17 May 2019, at 1:33pm, Clemens Ladisch wrote: > This keyword behaves magically. Mmmm. In that case, to implement this properly you need to store a default-type flag alongside the default value. Proposed values might be 0) No default specified, so use … 1) Fixed default specified, so use

Re: [sqlite] Bug in table_info pragma

Simon Slavin wrote: > If you supply "default CURRENT_TIMESTAMP" I would expect SQLite to > evaluate CURRENT_TIMESTAMP, find a string value like > '2019-05-17 12:10:43', and store that string in the schema. This keyword behaves magically. ANSI SQL-92 says: | The default value inserted in the colum

Re: [sqlite] Bug in table_info pragma

J. King, on Friday, May 17, 2019 07:19 AM, wrote... >Perhaps I should have been clearer that this is a regression? > >SQLite version 3.13.0 2016-05-18 10:57:30 >Enter ".help" for usage hints. >Connected to a transient in-memory database. >Use ".open FILENAME" to reopen on a persistent database. >s

Re: [sqlite] Bug in table_info pragma

Please disregard, apologies for the noise. From: "Nelson, Erik - 2" Sent: May 17, 2019 8:17 AM To: sqlite-users@mailinglists.sqlite.org Subject: [External email from sqlite-users-boun...@mailinglists.sqlite.org] Re: [sqlite] Bug in table_info pragma

Re: [sqlite] Bug in table_info pragma

We need to get these into the hive database, if that's helpful From: Simon Slavin Sent: May 17, 2019 8:16 AM To: SQLite mailing list Subject: Re: [sqlite] Bug in table_info pragma On 17 May 2019, at 12:06pm, J. King wrote: > Then there wou

Re: [sqlite] Bug in table_info pragma

On 17 May 2019, at 12:06pm, J. King wrote: > Then there would be no differentiating "default CURRENT_TIMESTAMP" from > "default 'CURRENT_TIMESTAMP'". That interesting. If you supply "default CURRENT_TIMESTAMP" I would expect SQLite to evaluate CURRENT_TIMESTAMP, find a string value like '2019

Re: [sqlite] Bug in table_info pragma

On 2019-05-17 07:08:27, "Warren Young" wrote: On May 17, 2019, at 4:55 AM, J. King wrote: SQLite version 3.28.0 2019-04-16 19:49:53 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> create table t

Re: [sqlite] Bug in table_info pragma

On May 17, 2019, at 4:55 AM, J. King wrote: > > SQLite version 3.28.0 2019-04-16 19:49:53 > Enter ".help" for usage hints. > Connected to a transient in-memory database. > Use ".open FILENAME" to reopen on a persistent database. > sqlite> create table t(a text default '' /* comment */ ); > sqlite

Re: [sqlite] Bug in table_info pragma

On 2019-05-17 06:59:58, "Simon Slavin" wrote: On 17 May 2019, at 11:55am, J. King wrote: I would expect it to print only the string delimiters. I might expect it to print only the thing inside the delimiters, i.e. nothing. Then there would be no differentiating "default CURRENT_TIMESTAM

Re: [sqlite] Bug in table_info pragma

On 17 May 2019, at 11:55am, J. King wrote: > I would expect it to print only the string delimiters. I might expect it to print only the thing inside the delimiters, i.e. nothing. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http:/

Re: [sqlite] Bug report: Segfault in sqlite3_clear_bindings when statement is nullptr

Hi, Since the last mail I sent was not really readable due to problems with my mail settings I resend the possible bug report below. I want to report a (possible) bug in sqlite3. When sqlite3_clear_bindings is called with a nullptr argument, then a SEGFAULT occurs. From the behavior of the othe

Re: [sqlite] Bug: CTE name leaking through views

This mailing list disallows attachments as a anti-spam measure. You can send attachments directly to me, if you like. On 5/1/19, Stephen Hunt wrote: > Hi, > > We use SQLite extensively here at Zaber and are quite pleased with it. > However, we recently added a view that incorrectly returns incor

Re: [sqlite] Bug in sqlite3 (CLI, linux/Ubuntu)

Works fine for me on Centos ... using the default (ancient) version of SQLite3 # sqlite3 /tmp/test.db "CREATE TABLE test (col1); INSERT INTO test VALUES(1);" # touch /tmp/test.init # sqlite3 /tmp/test.db "SELECT * FROM test;" 2>/dev/null 1 # sqlite3 -init /tmp/test.init /tmp/test.db "SELECT * FRO

Re: [sqlite] Bug in sqlite3 (CLI, linux/Ubuntu)

> Dear colleagues > > I detected an unexpected behaviour in sqlite3 (CLI) that I consider a bug as > it seems not documented. > > When using an init file (even if an empty file), sqlite3 outputs an extra > empty line to stdout. This messes up parsing of the sqlite3 output, as this > line is

Re: [sqlite] Bug in sqlite3 (CLI, linux/Ubuntu)

On 30-3-2019 12:28, softw...@quantentunnel.de wrote: Dear colleagues I detected an unexpected behaviour in sqlite3 (CLI) that I consider a bug as it seems not documented. When using an init file (even if an empty file), sqlite3 outputs an extra empty line to stdout. This messes up parsing of

  1   2   3   4   5   6   7   8   9   10   >