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
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
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
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
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
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
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
> 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
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
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
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
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
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:
>
>
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
Hi, Sergey,
On Wed, Aug 24, 2016 at 8:55 AM, Sergey Shamshyn
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 to db file
> - onlt
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
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:
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
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
On Sat, 7 Feb 2015 11:27:59 +0530, Abdul Aziz 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 x,y,z as FLOAT, android
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
>
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 + "
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
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 + "
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
>
On 10/18/2014 05:45 AM, Deon Brewis wrote:
I'm trying to follow Richard's advise to work around this issue, which is:
"Is that database ever used by more than a single process. (Use by multiple
threads using separate connections does not count - I mean really used by
multiple processes with
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
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
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
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.
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
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
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
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
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
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
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,
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 ?
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
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
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:
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
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
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
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
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
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
Windows doesn't allow "con" named fodlers or files.
Marian Cascaval
From: Felix Zimmermann
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 create a database
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
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?
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
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
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
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.
>
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
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
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]
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
> -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
"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.
>
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
Perhaps you could provide the exact SQL that crashed. The code seems to be
very well tested automatically, so it is very unlikely that all ANALYZE
executions fail.
--Ned.
http://nedbatchelder.com
-Original Message-
From: Cariotoglou Mike [mailto:[EMAIL PROTECTED]
Sent: Monday, 05
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
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++) {
>
64 matches
Mail list logo