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

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

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

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

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

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

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

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

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

[sqlite] Bug in SQLite version 3.31.1 and 3.32?

Hi, I am not sure if I found a bug in SQLite version 3.31.1 and 3.32. Could you please check? CREATE TABLE t ( textid TEXT ); INSERT INTO t VALUES ('12'); INSERT INTO t VALUES ('34'); CREATE TABLE i ( intid INTEGER PRIMARY KEY ); INSERT INTO i VALUES (12); INSERT INTO i VALUES (34); CREATE

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 versi

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

Dear SQLite Developers, I just noticed the following bug in SQLite version 3.28.0: create table t AS values (1), (2); .print "select with correct output ..." select * from ( select * from t limit 1 ) union all select * from t ; .print "same select leads to incorrect result w

Re: [sqlite] bug in sqlite when

On 8/24/16, Sergey Shamshyn wrote: > - *PRAGMA journal_mode=OFF* (when not execute this pragma, all is ok). With journal_mode=OFF, the database may go corrupt if: (1) The program is ever terminated (ex: using SIGKILL) while the database is open. (2) If a COMMIT

Re: [sqlite] bug in sqlite when

Hi, Sergey, On Wed, Aug 24, 2016 at 8:55 AM, Sergey Shamshyn <sergey2...@victorovich.com> wrote: > Hi. > I have a big trouble using SQLite: got an error SQLITE_CORRUPT (11), I think > this is a 100% SQLite bug, because: > - only ONE THREAD of my process is writing periodically t

[sqlite] bug in sqlite when

Hi. I have a big trouble using SQLite: got an error SQLITE_CORRUPT (11), I think this is a 100% SQLite bug, because: - only ONE THREAD of my process is writing periodically to db file - onlt ONE ANOTHER THREAD of my another process reads from this db file - version 3.14.1 - PRAGMA synchronous

[sqlite] Bug in SQLite 3.8.11.1 source code

Hello ! This is a real simple bug fix but it seems that no one is caring about it !!! Cheers ! > Sat Sep 12 2015 8:52:04 pm CEST CEST from "chris0e3" >Subject: [sqlite] Bug in SQLite 3.8.11.1 source code > > Hello, > > I was just looking at updating to SQ

[sqlite] Bug in SQLite 3.8.11.1 source code

ture. I'm sure someone will address it Real Soon Now if they haven't already. > > > Cheers ! > > Sat Sep 12 2015 8:52:04 pm CEST CEST from "chris0e3" < chris0e3 at gmail.com> > >Subject: [sqlite] Bug in SQLite 3.8.11.1 source code > > > > Hello, > &

[sqlite] Bug in SQLite 3.8.11.1 source code

Hello, I was just looking at updating to SQLite 3.8.11.1 when I spotted what appears to be an error. Here?s a patch to fix it: --- sqlite-amalgamation-3081101/sqlite3.c 2015-07-30 03:06:58.0 +0100 +++ sqlite3.c 2015-09-12 19:03:55.0 +0100 @@ -92265,7 +92265,7 @@ }

Re: [sqlite] Bug in SQLite FLOAT values

l Aziz >Sent: Saturday, 7 February, 2015 07:22 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Bug in SQLite FLOAT values > >OK, understood, thanks but can anyone explain me I was creating db of >different sensors, I used same methods, but in fields which were FLOAT

Re: [sqlite] Bug in SQLite FLOAT values

On 7 Feb 2015, at 2:22pm, Abdul Aziz wrote: > but in fields which were FLOAT were > filling with junk values (after 6 decimal places, see in SENSOR_1) why? Take a look at what happens when you try to write 1/13th in decimal:

Re: [sqlite] Bug in SQLite FLOAT values

OK, understood, thanks but can anyone explain me I was creating db of different sensors, I used same methods, but in fields which were FLOAT were filling with junk values (after 6 decimal places, see in SENSOR_1) why? even I was cutting it to 6 decimal places (as shown previously, was then again

Re: [sqlite] Bug in SQLite FLOAT values

un...@sqlite.org [mailto:sqlite-users- >boun...@sqlite.org] On Behalf Of Kees Nuyt >Sent: Saturday, 7 February, 2015 18:14 >To: sqlite-users@sqlite.org >Subject: Re: [sqlite] Bug in SQLite FLOAT values > >On Sat, 7 Feb 2015 11:27:59 +0530, Abdul Aziz <abduldblog...@gmail.com> >w

Re: [sqlite] Bug in SQLite FLOAT values

On Sat, 7 Feb 2015 11:27:59 +0530, Abdul Aziz <abduldblog...@gmail.com> wrote: > Hi there! > I hope you are well! > > Recently I was working on project based on Android Sensors and encountered > a bug in sqlite db, situation was this: > I was setting there three values

Re: [sqlite] Bug in SQLite FLOAT values

On 7 Feb 2015, at 5:57am, Abdul Aziz wrote: > *again I converted back to float this string formatted value, and printed > into Log, I was clearly seeing values upto 6 decimal places , but after > insertion into sqlite db, when after generation of sqlite db file, was >

Re: [sqlite] Bug in SQLite FLOAT values

On 2015/02/07 15:47, Abdul Aziz wrote: Thanks for replybut I am now using VARCHARS, then how this is working? not generating any errors? Please elaborate, my query to create DB is: mSQLiteDatabase.execSQL("CREATE TABLE " + tableName + " ( " + EVENT_TIME + " INTEGER, " + SYSTEM_TIME + "

Re: [sqlite] Bug in SQLite FLOAT values

On 2/7/2015 8:47 AM, Abdul Aziz wrote: Thanks for replybut I am now using VARCHARS, then how this is working? not generating any errors? When Tim said "Read this", he meant it. http://www.sqlite.org/datatype3.html answers your questions (but only if you read it). -- Igor Tandetnik

Re: [sqlite] Bug in SQLite FLOAT values

Thanks for replybut I am now using VARCHARS, then how this is working? not generating any errors? Please elaborate, my query to create DB is: mSQLiteDatabase.execSQL("CREATE TABLE " + tableName + " ( " + EVENT_TIME + " INTEGER, " + SYSTEM_TIME + " INTEGER PRIMARY KEY, " + ACCURACY + "

Re: [sqlite] Bug in SQLite FLOAT values

On 07 Feb 2015 at 05:57, Abdul Aziz wrote: > *I think this is a bug, this means float values in sqlite will always be > filled upto 11-12 decimal places, in any case, you will have to fill it, or > sqlite will fill it itself with junk values, **this may create lot of >

[sqlite] Bug in SQLite FLOAT values

Hi there! I hope you are well! Recently I was working on project based on Android Sensors and encountered a bug in sqlite db, situation was this: I was setting there three values x,y,z as FLOAT, android inbuilt sensors were receiving values as float upto 8 decimal places, but I wanted to store

[sqlite] Bug in SQLite FLOAT values

Hi there! I hope you are well! Recently I was working on project based on Android Sensors and encountered a bug in sqlite db, situation was this: I was setting there three values x,y,z as FLOAT, android inbuilt sensors were receiving values as float upto 8 decimal places, but I wanted to store

Re: [sqlite] Bug 993556 - SQLite crash in walIndexTryHdr due to Windows EXCEPTION_IN_PAGE_ERROR exception

l" causes a similar effect. Second section here: http://www.sqlite.org/vfs.html Dan. -- View this message in context: http://sqlite.1065341.n5.nabble.com/Bug-993556-SQLite-crash-in-walIndexTryHdr-due-to-Windows-EXCEPTION-IN-PAGE-ERROR-exception-tp78695.html Sent from the S

[sqlite] Bug 993556 - SQLite crash in walIndexTryHdr due to Windows EXCEPTION_IN_PAGE_ERROR exception

de=EXCLUSIVE while still using multiple threads with connections? -- View this message in context: http://sqlite.1065341.n5.nabble.com/Bug-993556-SQLite-crash-in-walIndexTryHdr-due-to-Windows-EXCEPTION-IN-PAGE-ERROR-exception-tp78695.html Sent from the SQLite mail

Re: [sqlite] Bug in sqlite? Can't read tables just after creating them

On 11 Mar 2014, at 11:31am, Fabrice Triboix wrote: > The problem is actually elsewhere. I changed the filesystem and it works > fine. > > So the problem is not with sqlite but with our special filesystem. Make sure your code tests the results returned by all API

Re: [sqlite] Bug in sqlite? Can't read tables just after creating them

t;d...@sqlite.org> Sender: sqlite-users-bounces@sqlite.orgDate: Tue, 11 Mar 2014 07:27:37 To: General Discussion of SQLite Database<sqlite-users@sqlite.org> Reply-To: General Discussion of SQLite Database <sqlite-users@sqlite.org> Subject: Re: [sqlite] Bug in sqlite? Can't read tables j

Re: [sqlite] Bug in sqlite? Can't read tables just after creating them

On Tue, Mar 11, 2014 at 6:35 AM, wrote: > Hi, > > I found a problem in sqlite. > > In essence, here is what my code does: > 1 - It opens a database file > 2 - If it doesn't find certain tables, it assumes this is a new one and > creates the necessary tables and add a

[sqlite] Bug in sqlite? Can't read tables just after creating them

Hi, I found a problem in sqlite. In essence, here is what my code does: 1 - It opens a database file 2 - If it doesn't find certain tables, it assumes this is a new one and creates the necessary tables and add a few entries in one of them (let's call it mytable) 3 - It queries mytable by

Re: [sqlite] Bug in SQLite 3.8.2

Thanks for the bug report. Ticket: http://www.sqlite.org/src/info/c34d0557f740c45070 Fixed here: http://www.sqlite.org/src/info/5d01426ddf On Wed, Feb 12, 2014 at 5:31 AM, Paweł Salawa wrote: > Hi, > > The bug affects 3.8.2 and 3.8.3.1, I haven't tested other versions.

Re: [sqlite] Bug in SQLite 3.8.2

On Wed, 12 Feb 2014 11:31:05 +0100, Pawe? Salawa wrote: > - open database A and attach database B: > ATTACH 'database_b.db' AS 'attached'; This is not the main cause, but that should be: ATTACH 'database_b.db' AS attached; (attached should not be a literal but

[sqlite] Bug in SQLite 3.8.2

Hi, The bug affects 3.8.2 and 3.8.3.1, I haven't tested other versions. *Preconditions:* - 2 databases: A and B. - database A has table "test": CREATE TABLE test (id integer PRIMARY KEY, val text) WITHOUT ROWID - database B has table "test2": CREATE TABLE test2 (EID INTEGER, node1 INTEGER,

[sqlite] Bug Report SQLITE JDBC driver 3.7.2: problem calling "wasNull" function in the ResultSet.

Hi, if the user calls "getObject" before calling wasNull then wasNull returns either the "wasNull" value of the previous called get call, or it throws an Exception, if it is called the first time. How to replicate this bug: DBConnection conn = DatabaseMetaData md = conn.getMetaData();

Re: [sqlite] Bug in SQLITE regarding HAVING?

Hi Simon, no its OK -- did not take anything personal. I think I stay with my SQL-statements... Thanks again for your hint, Tobias ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] Bug in SQLITE regarding HAVING?

On 25 Dec 2013, at 8:54am, Tobias Steinmann wrote: > thanks for your hint. I needed some time to figure out, how to use this > mailing-list and I hope, you will get my answer. > > I tried the same im MySQL and it worked -- I know, that is no reason I just > wanted to

Re: [sqlite] Bug in SQLITE regarding HAVING?

Hi Simon, thanks for your hint. I needed some time to figure out, how to use this mailing-list and I hope, you will get my answer. I tried the same im MySQL and it worked -- I know, that is no reason I just wanted to say. I also tried, to rename one of the depth's to depth1 -- and then it

Re: [sqlite] Bug in SQLITE regarding HAVING?

On Mon, 23 Dec 2013 23:50:30 +0100 "E.Pasma" wrote: > > . See if you can make the simplest possible SELECT that comes up > > with unexpected results. > > select 0 as depth > from(select 1 as depth) > group by null > having depth < 1 > ; > This returns no rows. Thus

Re: [sqlite] Bug in SQLITE regarding HAVING?

Op 23 dec 2013, om 14:32 heeft Simon Slavin het volgende geschreven: General note: when making up a name for a calculation like 'depth', try to make sure it's not the name of any of the columns in the tables mentioned in your SELECT. This avoids ambiguity. . See if you can make the

Re: [sqlite] Bug in SQLITE regarding HAVING?

On 22 Dec 2013, at 11:12pm, Tobias Steinmann wrote: > SELECT node.id,node.lft, node.rgt, (COUNT(parent.id) - (sub_tree.depth + 1)) > AS depth FROM target_directory AS node, target_directory AS parent, > target_directory AS sub_parent, (SELECT node.id,

Re: [sqlite] Bug report: Sqlite seg fault, probably after database gets corrupt

On Thu, Aug 1, 2013 at 3:30 PM, Brian Vincent wrote: > if( d1>=(u32)nKey1 && sqlite3VdbeSerialTypeLen(serial_type1)>0 ) break; > > The next line will likely segfault if d1>=nKey1, right? What if d1>=nKey1, > but it's not true that sqlite3VdbeSerialTypeLen(serial_type1)>0 ?

Re: [sqlite] Bug report: Sqlite seg fault, probably after database gets corrupt

if( d1>=(u32)nKey1 && sqlite3VdbeSerialTypeLen(serial_type1)>0 ) break; The next line will likely segfault if d1>=nKey1, right? What if d1>=nKey1, but it's not true that sqlite3VdbeSerialTypeLen(serial_type1)>0 ? Wouldn't this still cause a segfault? Is that a valid concern? -Brian

Re: [sqlite] Bug report: Sqlite seg fault, probably after database gets corrupt

On Thu, Aug 1, 2013 at 2:20 PM, Brian Vincent wrote: > I think I can describe, is a > possibly way that a corrupt database is causing sqlite to segfault. > Thanks. Fixed in http://www.sqlite.org/src/info/c3baca99f4 including a test case. -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] Bug report: Sqlite seg fault, probably after database gets corrupt

On Thu, Aug 1, 2013 at 8:20 PM, Brian Vincent wrote: > next line assigns it to d1, which is a signed integer, so d1 gets a > negative value. To be strictly pedantic, overflow/underflow are undefined for _signed_ types in C. Here are some details:

Re: [sqlite] Bug report: Sqlite seg fault, probably after database gets corrupt

On 8/1/2013 12:20, Brian Vincent wrote: Let me first say that we sometimes see databases that go corrupt. I haven't pinpointed the cause yet, This may be enlightening: "How to Corrupt an SQLite Database File" https://www.sqlite.org/howtocorrupt.html

[sqlite] Bug report: Sqlite seg fault, probably after database gets corrupt

Let me first say that we sometimes see databases that go corrupt. I haven't pinpointed the cause yet, but what I think I can describe, is a possibly way that a corrupt database is causing sqlite to segfault. I use a java wrapper for sqlite. I've seen this exact segfault happen on an older

Re: [sqlite] Bug in SQLite 3.7.15-3.7.17 regarding group by query after joining two table with primary key index

lite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Richard Hipp Sent: Wednesday, June 05, 2013 6:21 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Bug in SQLite 3.7.15-3.7.17 regarding group by query after joining two table with primary key index On Tue, Jun 4, 2013

Re: [sqlite] Bug in SQLite 3.7.15-3.7.17 regarding group by query after joining two table with primary key index

On Tue, Jun 4, 2013 at 2:42 PM, Chen, Mi wrote: > All, I encountered a likely bug during development with latest SQL > versions (3.7.17)... It appears to be affecting the result of queries with > GROUP BY clause with partial join over two primary keys. > Your test case has

[sqlite] Bug in SQLite 3.7.15-3.7.17 regarding group by query after joining two table with primary key index

All, I encountered a likely bug during development with latest SQL versions (3.7.17)... It appears to be affecting the result of queries with GROUP BY clause with partial join over two primary keys. SQL Version 3.7.14 does not have this behavior, and SQL Version 3.7.15 - 3.7.17 are all

Re: [sqlite] Bug in SQlite .NET Version 1.0.82.0

Michael Endres wrote: > > After performing Database Actions, we used > SQLiteConnection Close() to close the database connection. > > Afterwards, I use File.ReadAllBytes() on the Database File, which lead to a > Access Violation because the file was still opened in a different process. > When

[sqlite] Bug in SQlite .NET Version 1.0.82.0

Dear Community, I found a bug/different behavior in your current Sqlite .NET Version 1.0.82.0: After performing Database Actions, we used SQLiteConnection Close() to close the database connection. Afterwards, I use File.ReadAllBytes() on the Database File, which lead to a Access Violation

Re: [sqlite] bug with sqlite

nd contains "stdout file here". Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Simon Slavin [slav...@bigfraud.org

Re: [sqlite] bug with sqlite

On 29 Mar 2011, at 12:38pm, Arjen Markus wrote: > is this under Windows? con is one of the reserved file names, dating > from the DOS days (or even before that). Bah. Arjen beat me to it. Yes 'con' is the filename you used to use when you wanted to talk to the CONSOLE: the terminal connected

Re: [sqlite] bug with sqlite

Windows doesn't allow "con" named fodlers or files. Marian Cascaval From: Felix Zimmermann <fea...@yahoo.de> To: sqlite-users@sqlite.org Sent: Mon, March 28, 2011 10:26:59 PM Subject: [sqlite] bug with sqlite hi why isnt it possible to c

Re: [sqlite] bug with sqlite

Hi, is this under Windows? con is one of the reserved file names, dating from the DOS days (or even before that). Other reserved names are aux, nul and prn (I think there is a fifth, but I cannot remember that one). So, that has nothing to do with SQLite itself. Regards, Arjen On 2011-03-28

[sqlite] bug with sqlite

hi why isnt it possible to create a database file with the name "con" ? i just doesnt work. no matter what file extension im taking. regrets Felix ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] BUG in SQLite? Still the rowid question

Am 30.08.2009 um 17:56 schrieb Kit: > 2009/8/29 Wanadoo Hartwig : >> The largest and last row id is 4. Why is SQLite returning 5? I think >> it has to do with the FTS3 module but still the trigger statement >> should shield the row ids from the trigger statement, or?

Re: [sqlite] BUG in SQLite? Still the rowid question

2009/8/29 Wanadoo Hartwig : > The largest and last row id is 4. Why is SQLite returning 5? I think > it has to do with the FTS3 module but still the trigger statement > should shield the row ids from the trigger statement, or? > Hartwig CREATE TABLE Simple (ID integer

Re: [sqlite] Bug in SQLite 3.6.14 / wrong rowid returned

Hi Simon, I am not complaining about the autoincrement's result but that sqlite3_insert_rowid returns the wrong rowid. Hartwig Am 29.06.2009 um 23:09 schrieb Simon Slavin: > > On 29 Jun 2009, at 8:54pm, Wanadoo Hartwig wrote: > >> I have posted a while ago a bug (at least I think that it is

Re: [sqlite] Bug in SQLite 3.6.14 / wrong rowid returned

On 29 Jun 2009, at 8:54pm, Wanadoo Hartwig wrote: > I have posted a while ago a bug (at least I think that it is a bug) > but only in a very abstract form. Now, I have written a C-program > showing the bug. I assume that if you type those commands into the sqlite3 command-line tool, you get

Re: [sqlite] Bug in SQLite 3.6.14 / wrong rowid returned

Hi, actually, I also tested it with 3.6.16 and the bug still exists. Hartwig Am 29.06.2009 um 21:54 schrieb Wanadoo Hartwig: > Hello, > > I have posted a while ago a bug (at least I think that it is a bug) > but only in a very abstract form. Now, I have written a C-program > showing the bug. >

[sqlite] Bug in SQLite 3.6.14 / wrong rowid returned

Hello, I have posted a while ago a bug (at least I think that it is a bug) but only in a very abstract form. Now, I have written a C-program showing the bug. Brief description: An FTS related trigger combination leads to a wrong determination of the last inserted row id. Triggers that are

Re: [sqlite] Bug in SQLITE? "Joins + Order By" Changing row count!?!

Create an sql dump using the ".dump" command of the sqlite3 shell tool: $ echo .dump | sqlite3 database_file.db > dump.sql Or just put the database file up for download somewhere. Or if you prefer, send it to me by email. If this bug is present in current versions, we need to fix it. But

Re: [sqlite] Bug in SQLITE? "Joins + Order By" Changing row count!?!

Thanks Dan for the reply, How would I go about creating a sql dump? As for the ORDER BY clause, I do this: SELECT * FROM tableA a INNER JOIN tableB b INNER JOIN tableC c INNER JOIN tableD d LEFT JOIN tableE ON a.b_id = b.id AND a.c_id = c.id AND a.d_id = d.id AND c.e_id = e.id ORDER BY

[sqlite] Bug in SQLITE? "Joins + Order By" Changing row count!?!

Hello, I am executing a query such as: 1. SELECT * FROM tableA a INNER JOIN tableB b INNER JOIN tableC c INNER JOIN tableD d LEFT JOIN tableE ON a.b_id = b.id AND a.c_id = c.id AND a.d_id = d.id AND c.e_id = e.id; 2. 3. CREATE TABLE tableA ( 4. id INTEGER NOT NULL

RE: [sqlite] Bug in SQlite ?

What assertion failure are you seeing? What is the exact message? Can you use a debugger to step into the code where the assertion failure happens? RobR - To unsubscribe, send email to [EMAIL PROTECTED]

Re: [sqlite] Bug in SQlite ?

On 9/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I am seeing an assert crash on my system here. I think it is caused by the following code, --select.c (line 88)-- /* ** Delete the given Select structure and all of its substructures. */ void

[sqlite] Bug in SQlite ?

I am seeing an assert crash on my system here. I think it is caused by the following code, --select.c (line 88)-- /* ** Delete the given Select structure and all of its substructures. */ void sqlite3SelectDelete(Select *p){ if( p ){

RE: [sqlite] bug in sqlite 3.2.5 compilation and ANALYZE

> -Original Message- > From: Miha Vrhovnik [mailto:[EMAIL PROTECTED] > Sent: Monday, September 05, 2005 7:14 PM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] bug in sqlite 3.2.5 compilation and ANALYZE > > "Cariotoglou Mike" <[EMAIL PROTECTED]> je o

RE: [sqlite] bug in sqlite 3.2.5 compila tion and ANALYZE

"Cariotoglou Mike" <[EMAIL PROTECTED]> je ob 5.9.2005 14:49:54 napisal(a): >ok. >I use sqlite3Explorer (which should not matter), I create a new >database, then I run : > >create table test1(id integer); >analyze > >this crashes immediately, with dll 3.2.5. it works fine from the >command-line. >

RE: [sqlite] bug in sqlite 3.2.5 compilation and ANALYZE

TECTED] > Sent: Monday, September 05, 2005 3:10 PM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] bug in sqlite 3.2.5 compilation and ANALYZE > > Perhaps you could provide the exact SQL that crashed. The > code seems to be very well tested automatically, so it is > ver

RE: [sqlite] bug in sqlite 3.2.5 compilation and ANALYZE

September, 2005 5:46 AM To: sqlite-users@sqlite.org Subject: [sqlite] bug in sqlite 3.2.5 compilation and ANALYZE I tried the ANALYZE statement with sqlite 3.2.5 in dll form, (both the pre-compiled version downloaded from the site, AND a local compilation). in both cases, the statement fails

[sqlite] bug in sqlite 3.2.5 compilation and ANALYZE

I tried the ANALYZE statement with sqlite 3.2.5 in dll form, (both the pre-compiled version downloaded from the site, AND a local compilation). in both cases, the statement fails with an ACCESS VIOLATION. however, the same statement, when run from the pre-compiled sqlite3.exe, works. further,

RE: [sqlite] Bug in SQLite C++ Wrapper?

Aha, thanks! -Original Message- From: Cory Nelson [mailto:[EMAIL PROTECTED] Sent: Saturday, June 25, 2005 11:30 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Bug in SQLite C++ Wrapper? cmd.executenonquery() creates a reader, which calls reset when destructed :) On 6/25/05

Re: [sqlite] Bug in SQLite C++ Wrapper?

cmd.executenonquery() creates a reader, which calls reset when destructed :) On 6/25/05, Brown, Dave <[EMAIL PROTECTED]> wrote: > > In looking at the SQLite C++ Wrapper (http://dev.int64.org/sqlite.html) I > noticed the example insert code has a loop like: > > for(int i=0; i<1; i++) { >

[sqlite] Bug in SQLite C++ Wrapper?

In looking at the SQLite C++ Wrapper (http://dev.int64.org/sqlite.html) I noticed the example insert code has a loop like: for(int i=0; i<1; i++) { cmd.bind(1, i); cmd.executenonquery(); } but sqlite3_reset() isn't being called each time after the statement is executed