[sqlite] bug in PRAGMA ignore_check_constraints?

I do not believe NOT NULL is a CHECK constraint, though you could use gender TEXT CHECK(typeof(gender) <> 'null') is and would work much the same way, though possibly with less?efficiency. Peter? On Thursday, September 10, 2015 4:48 PM, Roman Fleysher wrote: Dear SQLiters, I am

[sqlite] bug in PRAGMA ignore_check_constraints?

...@sqlite.org] Sent: Thursday, September 10, 2015 7:53 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] bug in PRAGMA ignore_check_constraints? On 9/10/15, Richard Hipp wrote: > On 9/10/15, Roman Fleysher wrote: >> Dear SQLiters, >> >> I am trying to temporarily dis

[sqlite] bug in PRAGMA ignore_check_constraints?

Dear SQLiters, I am trying to temporarily disable CHECK constraint given in columns of table definition. As far as I understand, PRAGMA ignore_check_constraints='yes'; should do it. However this example demonstrates that it is not: CREATE TABLE subject( subjectID INT, gender TEXT

[sqlite] bug in PRAGMA ignore_check_constraints?

On 9/10/15, Richard Hipp wrote: > On 9/10/15, Roman Fleysher wrote: >> Dear SQLiters, >> >> I am trying to temporarily disable CHECK constraint given in columns of >> table definition. As far as I understand, >> >> PRAGMA ignore_check_constraints='yes'; > > PRAGMA ignore_check_constraints=YES;

[sqlite] bug in PRAGMA ignore_check_constraints?

On 9/10/15, Roman Fleysher wrote: > Dear SQLiters, > > I am trying to temporarily disable CHECK constraint given in columns of > table definition. As far as I understand, > > PRAGMA ignore_check_constraints='yes'; PRAGMA ignore_check_constraints=YES; -- no quotes. > > should do it. However

[sqlite] BUG: sqlite 3.8.11.x left join

Just realized that this simpler case shows the same problem: SELECT * FROM ( SELECT 'apple' fruit UNION ALL SELECT 'banana' ) a LEFT JOIN ( SELECT 1 isyellow ) c ON a.fruit='banana' ; On 22/08/15 00:58, Mark Brand wrote: > Hi, > > For the query below, versions 3.8.11.0 and

[sqlite] BUG: sqlite 3.8.11.x left join

Hi, For the query below, versions 3.8.11.0 and 3.8.11.1 return only 1 row. For some reason, the LEFT JOIN seems to behave like a JOIN. Older versions (tested 3.8.7.4 and 3.8.10.2) correctly return 2 rows. SELECT * FROM ( SELECT 'apple' fruit UNION ALL SELECT 'banana' ) a JOIN (

[sqlite] BUG: sqlite 3.8.11.x left join

The on-line fix (https://www.sqlite.org/src/artifact/24323faac?ln=3785) together with commentary and test cases is now on trunk (https://www.sqlite.org/src/info/351bc22fa9b5a2e5}. On 8/21/15, Richard Hipp wrote: > Thanks for the test case. The error seems to have been introduced by > check-in

[sqlite] BUG: sqlite 3.8.11.x left join

Thanks for the test case. The error seems to have been introduced by check-in https://www.sqlite.org/src/info/6df18e949d367629 which does some aggressive transformations on nested queries for improved performance. On 8/21/15, Mark Brand wrote: > Hi, > > For the query below, versions 3.8.11.0

[sqlite] Bug report page contains invalid e-mail address

Hi, I tried to file a bug report. However the e-mail address as stated on http://www.sqlite.org/src/wiki?name=Bug+Reports (sqlite-users at sqlite.org) does not exist. It cost me quite some effort to find out the correct address which is sqlite-users at mailinglists.sqlite.org. Can someone

[sqlite] Bug in sqlite3_trace/trigger/delete

ype 0|0|0|SCAN TABLE account_account_template 0|0|0|SCAN TABLE account_account_template 0|0|0|SCAN TABLE account_account 0|0|0|SCAN TABLE account_account - > Fri Jul 31 2015 15:34:56 CEST from "sqlite-mail" > Subject: [sqlite] Bug in >sqlite3_trace/trigger/delete > > H

[sqlite] Bug in sqlite3_trace/trigger/delete

(d_id) REFERENCES ad(id) CONSTRAINT constrained_fkey_ad_id FOREIGN KEY(d_id) REFERENCES ad(id) ); COMMIT; - > Wed Aug 05 2015 12:16:09 CEST from "sqlite-mail" > Subject: Re: [sqlite] Bug in >sqlite3_trace/trigger/delete > > >>Hello ! >>

[sqlite] Bug in sqlite3_trace/trigger/delete

c_id) REFERENCES > ac(id), -- here we have the comma separating a constraint > CONSTRAINT constrained_fkey_ad_id FOREIGN KEY(d_id) REFERENCES ad(id) > ); > > COMMIT; > > - > > Thanks in advance for your time and attention ! > > Mon Aug 03 2015 13:08:08 CES

[sqlite] Bug in sqlite3_trace/trigger/delete

odoo.db and $ sqlite3 ./odoo.db "SELECT count(*) FROM res_users WHERE id = 7;" 0 Is this as expected? Dan. > Cheers ! > > Mon Aug 03 2015 13:08:08 CEST from "Dan Kennedy" > Subject: Re: [sqlite] Bug in > sqlite3_trace/trigger/delete >

[sqlite] Bug in sqlite3_trace/trigger/delete

s depends sqlite3 do not detect it and > simply add a new entry at the end of sqlite3_master. > > > shell script to make the bug test program > MYINC=$HOME/dev/sqlite3 > #MYINC=. > > gcc \ > -DTHREADSAFE=1 \ > -DSQLITE_DEFAULT_FILE_FORMAT=4 \ > -DSQLITE_DEFAULT_AUTOVACUUM

[sqlite] bug in query optimizer

On 2015-07-31 06:16 PM, Allen wrote: > Dear Dr. Hipps > > My bug report could not have been more clear. (And so is your response, > BTW--I will not waste my time sending you bug reports in the future). If I may - there is no reason to be dismayed. The suggestion for optimization seems a great

[sqlite] Bug in sqlite3_trace/trigger/delete

DSAFE=1 \ ??? -DSQLITE_DEFAULT_FILE_FORMAT=4 \ ??? -DSQLITE_DEFAULT_AUTOVACUUM=1 \ ??? -DSQLITE_DEFAULT_FOREIGN_KEYS= 1 \ ??? -DSQLITE_ENABLE_COLUMN_METADATA=1 \ ??? -DSQLITE_ENABLE_FTS4=1 \ ??? -DSQLITE_ENABLE_FTS3_PARENTHESIS=1 \ ??? -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 \ ??? -DSQLITE_ENABLE_RTREE=1 \ ???

[sqlite] bug in query optimizer

Dear Dr. Hipps My bug report could not have been more clear. (And so is your response, BTW--I will not waste my time sending you bug reports in the future). Best Regards.

[sqlite] bug in query optimizer

On 7/31/15, Allen wrote: > I have a table, a partial index and a query, which (somewhat simplified) > are: > > create table Objs (Seqnum int primary key, Status, Timeout int) without > rowid; > > create index DIndex on Objs (Seqnum) where Status == 0; > > select Seqnum from Objs where Status == 0

[sqlite] bug in query optimizer

I have a table, a partial index and a query, which (somewhat simplified) are: create table Objs (Seqnum int primary key, Status, Timeout int) without rowid; create index DIndex on Objs (Seqnum) where Status == 0; select Seqnum from Objs where Status == 0 and strftime('%s','now') >= Timeout

[sqlite] [BUG?] BEFORE INSERT trigger has NEW.pk = -1 when NULL is passed for PK

2015-05-25 15:27 GMT+03:00 Richard Hipp : > > https://www.sqlite.org/mark/lang_createtrigger.html?Cautions+val*ger.#mark > Missed that. Thanks! -- Tomash Brechko

[sqlite] [BUG?] BEFORE INSERT trigger has NEW.pk = -1 when NULL is passed for PK

See: https://www.sqlite.org/mark/lang_createtrigger.html?Cautions+val*ger.#mark On 5/24/15, Tomash Brechko wrote: > Hello, > > The following code > > -- beg -- > CREATE TEMP TABLE t (pk INTEGER PRIMARY KEY, i); > CREATE TEMP TABLE b (before_pk, i); > CREATE TEMP TABLE a (after_pk, i); > >

[sqlite] [BUG?] BEFORE INSERT trigger has NEW.pk = -1 when NULL is passed for PK

Hello, The following code -- beg -- CREATE TEMP TABLE t (pk INTEGER PRIMARY KEY, i); CREATE TEMP TABLE b (before_pk, i); CREATE TEMP TABLE a (after_pk, i); CREATE TEMP TRIGGER tb BEFORE INSERT ON t FOR EACH ROW BEGIN INSERT INTO b VALUES (NEW.pk, NEW.i); END; CREATE TEMP TRIGGER ta AFTER

[sqlite] Bug: Cannot compile the new sqlite-src-3081001: preprocessor and testuite errors

2015-05-11 10:01 GMT+02:00 Jan Stan?k : > 2) When I "fix" the previous error, I'm getting assertion failure > during the test suite run. ... > shell1-5.0...testfixture: > /builddir/build/BUILD/tcl8.6.3/generic/tclIO.c:5815: DoReadChars: > Assertion `!((statePtr)->flags & ((1<<9))) ||

[sqlite] Bug: Cannot compile the new sqlite-src-3081001: preprocessor and testuite errors

Hello, I'm trying to build sqlite from source (sqlite-src) for Fedora. In the latest version (3.8.10.1), I encountered two issues that prevents me from building it: 1) The compilation fails on file sqlite3_analyzer.c, with error sqlite3_analyzer.c:14131:30: error: #if with no expression

[sqlite] Bug: sqlite3_memory_used/highwater truncate to 32 bits

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The sqlite3_memory_used and highwater interfaces are defined to return a 64 bit value. They carefully call the 32 bit limited sqlite3_status method and then cast to 64 bit. Instead they should call sqlite3_status64. Reported indirectly via

[sqlite] bug in transactions implementation ?

Pardon the long post everyone, but it seems from the other posts there is a large misconception to address here and I will attempt to do so as briefly as possible (Also, feel free to chime in where I am vague or wrong): On 2015-03-18 11:24 PM, Jason Vas Dias wrote: > OK, I discovered the OR

[sqlite] bug in transactions implementation ?

> On Mar 18, 2015, at 10:24 PM, Jason Vas Dias > wrote: > > This seems very buggy to me. Correct. http://www.styleite.com/wp-content/uploads/2014/11/legallyblonde.gif

[sqlite] bug in transactions implementation ?

> On Mar 18, 2015, at 9:45 PM, Jason Vas Dias > wrote: > > Would you care to expand on that ? As it says on the tin [1]: you cannot start a transactions inside another transaction (use savepoint if you want that), so? create table foo( value text, constraint uk unique( value ) ); begin

[sqlite] bug in transactions implementation ?

On 18 Mar 2015, at 9:24pm, Jason Vas Dias wrote: > But now I get another error after the constraint violation : > 'Error: cannot commit - no transaction is active' > which gets back to the original point of this post, > which is that SQLite is evidently not considering > all text within 'BEGIN

[sqlite] bug in transactions implementation ?

> On Mar 18, 2015, at 9:11 PM, Jason Vas Dias > wrote: > > am I missing something? rollback?

[sqlite] bug in transactions implementation ?

OK, I discovered the OR clause of the INSERT statement, so I'm trying: BEGIN TRANSACTION; INSERT OR ROLLBACK INTO db VALUES("This breaks a constraint"); COMMIT; But now I get another error after the constraint violation : 'Error: cannot commit - no transaction is active' which gets back to

[sqlite] bug in transactions implementation ?

On 18 Mar 2015, at 8:11pm, Jason Vas Dias wrote: > The problem is, if this transaction runs in a session, then > NO transactions can ever run again in that session - eg. > if I try to run the same transaction twice : > On linux command line: > $ echo ' > BEGIN TRANSACTION; > INSERT INTO

[sqlite] bug in transactions implementation ?

On 18/03/2015, Petite Abeille wrote: > >> On Mar 18, 2015, at 9:11 PM, Jason Vas Dias >> wrote: >> >> am I missing something? > > rollback? > Would you care to expand on that ? How is the script consisting of just the two insert statements shown meant to determine if the first transaction has

[sqlite] bug in transactions implementation ?

Good day - There appears to be a bug in the way SQLite implements transactions : I have an insert transaction which breaks a uniqueness constraint on an index: BEGIN TRANSACTION; INSERT INTO db VALUES("This breaks a constraint"); COMMIT; The problem is, if this transaction runs in a

[sqlite] bug in transactions implementation ?

ilinglists.sqlite.org] On Behalf Of Petite Abeille >Sent: Wednesday, 18 March, 2015 15:02 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] bug in transactions implementation ? > > >> On Mar 18, 2015, at 9:45 PM, Jason Vas Dias >wrote: >> >> Would you c

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

R.Smith wrote: > > > On 2015-03-16 12:49 AM, javaj1811 at elxala.com wrote: >> Hi Joe, >> >> good point, I've tested the fail scenario having the database located >> in a NTFS disk with the result of NO FAIL!!! >> so the insertion was done without sqlite error. >> now the problem seems to be

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

On 2015-03-16 12:49 AM, javaj1811 at elxala.com wrote: > Hi Joe, > > good point, I've tested the fail scenario having the database located > in a NTFS disk with the result of NO FAIL!!! > so the insertion was done without sqlite error. > now the problem seems to be reduced to Windows and FAT32

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

javaj1811 at elxala.com wrote: > Joe Mistachkin wrote: >> What file system is being used on the drive in question (e.g. FAT, >> FAT32, >> NTFS, etc)? >> >> -- >> Joe Mistachkin >> >> ___ >> sqlite-users mailing list >> sqlite-users at

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

Joe Mistachkin wrote: > What file system is being used on the drive in question (e.g. FAT, FAT32, > NTFS, etc)? > > -- > Joe Mistachkin > > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org >

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

javaj1811 at elxala.com wrote: > ales at elxala.de wrote: >> Hi, this is actually a Ticket, the good new is that is already >> pre-analyzed >> and probably also the cause has been found. >> I hope this is the right place to put this >> >> TITLE: Wrong ERROR_DISK_FULL writing a blob on Windows >>

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

ales at elxala.de wrote: > Hi, this is actually a Ticket, the good new is that is already > pre-analyzed > and probably also the cause has been found. > I hope this is the right place to put this > > TITLE: Wrong ERROR_DISK_FULL writing a blob on Windows > > DESCRIPTION: > >Having a sqlite

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

javaj1811 at elxala.com wrote: > > good point, I've tested the fail scenario having the database located in > a NTFS disk with the result of NO FAIL!!! > so the insertion was done without sqlite error. > now the problem seems to be reduced to Windows and FAT32 (and maybe FAT) > drives could you

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

What file system is being used on the drive in question (e.g. FAT, FAT32, NTFS, etc)? -- Joe Mistachkin

[sqlite] BUG in 3.8.8.3 and pre-release: Wrong ERROR_DISK_FULL writing a blob on Windows

Hi, this is actually a Ticket, the good new is that is already pre-analyzed and probably also the cause has been found. I hope this is the right place to put this TITLE: Wrong ERROR_DISK_FULL writing a blob on Windows DESCRIPTION: Having a sqlite database about 4.1 GB writing blobs in

[sqlite] Bug: Command Line Shell: Control-C interrupt handler not enabled on Windows

Hello, The SQLite Command Line Shell is documented (http://www.sqlite.org/sessions/sqlite.html) to support interrupting a long-running SQL statement by using the interrupt character (Control-C). On Windows, the shell is terminated immediately by Control-C, rather than interrupting the SQL

[sqlite] bug report: SELECT fails with BUSY in WAL mode database with concurrent writer

[ Not subscribed; please CC me. ] The attached Testcase.hs is a haskell program using sqlite, that demonstrates what I think may be a bug in WAL mode. Based on the documentation, readers in WAL mode are supposed to not be blocked by concurrent writers. However, this test case demonstrates that a

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 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

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

[sqlite] Bug report on bug reporting page (grammatical errors)

Hello All, Page: https://www.sqlite.org/src/wiki?name=Bug+Reports I recommend this change: >what the problem is. what the problem was. Reason: Rest of discussion is in past tense. >There were also numerous duplicates. There were also numerous duplicate bug reports. Reason: more complete

Re: [sqlite] Bug report: USBAN failure

On Wed, Dec 3, 2014 at 5:46 PM, Simon Slavin wrote: > > On 4 Dec 2014, at 12:26am, James K. Lowden > wrote: > > > What to do is another question. SQLite can surely ignore it. If I > > felt strongly about it, I'd submit a bug report to GCC

Re: [sqlite] Bug report: USBAN failure

On Wed, 03 Dec 2014 08:56:44 +0100 Clemens Ladisch wrote: > James K. Lowden wrote: > > /* Copy N bytes of SRC to DEST. */ > > extern void *memcpy (void *__restrict __dest, > > __const void *__restrict __src, size_t __n) > > __THROW __nonnull ((1,

Re: [sqlite] Bug report: USBAN failure

On Wed, Dec 3, 2014 at 9:50 AM, Stephan Beal wrote: > On Wed, Dec 3, 2014 at 5:35 PM, Scott Robison > wrote: > > > standards have all been ISO standards. Pedantic? Yes. Obviously DRH is > > willing to make the code more portable as long as it

Re: [sqlite] Bug report: USBAN failure

On Wed, Dec 3, 2014 at 5:35 PM, Scott Robison wrote: > standards have all been ISO standards. Pedantic? Yes. Obviously DRH is > willing to make the code more portable as long as it doesn't violate > ANSI-C, hence his patch early in the thread (see >

Re: [sqlite] Bug report: USBAN failure

On Wed, Dec 3, 2014 at 2:17 AM, Clemens Ladisch wrote: > Scott Robison wrote: > > On Dec 3, 2014 12:57 AM, "Clemens Ladisch" wrote: > >> Do you have a standard that allows NULL? The one I quoted does not. > > > > Note: I'll have to double check my copy

Re: [sqlite] Bug report: USBAN failure

Scott Robison wrote: > On Dec 3, 2014 12:57 AM, "Clemens Ladisch" wrote: >> Do you have a standard that allows NULL? The one I quoted does not. > > Note: I'll have to double check my copy of the C90 standard document, but > my re-reading of the C99 quote leads me to the

Re: [sqlite] Bug report: USBAN failure

On Dec 3, 2014 12:57 AM, "Clemens Ladisch" wrote: > > Do you have a standard that allows NULL? The one I quoted does not. Note: I'll have to double check my copy of the C90 standard document, but my re-reading of the C99 quote leads me to the conclusion that NULL is a valid

Re: [sqlite] Bug report: USBAN failure

On Dec 3, 2014 12:57 AM, "Clemens Ladisch" wrote: > > James K. Lowden wrote: > > /* Copy N bytes of SRC to DEST. */ > > extern void *memcpy (void *__restrict __dest, > > __const void *__restrict __src, size_t __n) > > __THROW __nonnull ((1, 2)); > >

Re: [sqlite] Bug report: USBAN failure

James K. Lowden wrote: > /* Copy N bytes of SRC to DEST. */ > extern void *memcpy (void *__restrict __dest, > __const void *__restrict __src, size_t __n) > __THROW __nonnull ((1, 2)); > > IIUC the declaration specifies the pointer cannot be NULL and the > compiler

Re: [sqlite] Bug report: USBAN failure

On Tue, 02 Dec 2014 15:58:47 +0100 Abramo Bagnara wrote: > The point is not about overzealousness, but about the declaration of > memcpy/memset on your machine. > > If it contains the nonnull attribute then (correctly) UBSan detect > that such constraint is not

Re: [sqlite] Bug report: USBAN failure

>> The block of code that refers to is: >> >> if( p->azVar ){ >> p->nzVar = pParse->nzVar; >> memcpy(p->azVar, pParse->azVar, p->nzVar*sizeof(p->azVar[0])); >> memset(pParse->azVar, 0, pParse->nzVar*sizeof(pParse->azVar[0])); >> } >> >> So maybe the check should be on

Re: [sqlite] Bug report: USBAN failure

Il 02/12/2014 15:02, Richard Hipp ha scritto: > On Tue, Dec 2, 2014 at 8:53 AM, Dominique Devienne > wrote: > >> On Tue, Dec 2, 2014 at 2:47 PM, Richard Hipp wrote: >> >>> On Mon, Dec 1, 2014 at 5:46 PM, Hadley Wickham >>> wrote:

Re: [sqlite] Bug report: USBAN failure

On Tue, Dec 2, 2014 at 8:53 AM, Dominique Devienne wrote: > On Tue, Dec 2, 2014 at 2:47 PM, Richard Hipp wrote: > > > On Mon, Dec 1, 2014 at 5:46 PM, Hadley Wickham > > wrote: > > > [...] has started running all R packages with USBAN.

Re: [sqlite] Bug report: USBAN failure

Richard Hipp wrote: > But apparently there is an issue in USBAN in that it does not allow calls > to memcpy() and memset() with NULL pointers even it the count field (the > third parameter) is zero. I couldn't find anything in the memcpy() or > memset() documentation that disallowed this case.

Re: [sqlite] Bug report: USBAN failure

On Tue, Dec 2, 2014 at 2:47 PM, Richard Hipp wrote: > On Mon, Dec 1, 2014 at 5:46 PM, Hadley Wickham > wrote: > > [...] has started running all R packages with USBAN. This reveals a > problem in sqlite.c > > I'm not sure what USBAN is > Most likely a typo.

Re: [sqlite] Bug report: USBAN failure

On Mon, Dec 1, 2014 at 5:46 PM, Hadley Wickham wrote: > Hi, > > I'm the maintainer of RSQLite, the R language binding for SQLite. > Recently, CRAN (the common R archive network) has started running all > R packages with USBAN. This reveals a problem in sqlite.c > ( >

[sqlite] Bug report: USBAN failure

Hi, I'm the maintainer of RSQLite, the R language binding for SQLite. Recently, CRAN (the common R archive network) has started running all R packages with USBAN. This reveals a problem in sqlite.c (http://www.stats.ox.ac.uk/pub/bdr/memtests/UBSAN-gcc/RSQLite/tests/testthat.Rout) >

Re: [sqlite] Bug

As Marc already stated, this mailing List doesn't allow attachments. Please also note that SQLite does not support something like a "Date" Type. See http://www.sqlite.org/datatype3.html . You may store date attributes in a numeric or TEXT

Re: [sqlite] Bug

I think attachments are dropped. If the SQL is reasonable size, just post it. Otherwise, you'll need to host the screen shot somewhere and link to it. > On Nov 19, 2014, at 10:00 PM, Josef Handsuch wrote: > > Dear developer, I'd like to thank you for you brilliant

[sqlite] Bug

Dear developer, I'd like to thank you for you brilliant software. There just seems to be one little bug to report. If I filter a field that I have dedicated to date, the result is always wrong. Please take a look at the screenshot (attached) to see what I mean. What you can see there is that I was

Re: [sqlite] sqlite bug report

On Thu, Nov 13, 2014 at 4:41 PM, Hinrichsen, John wrote: > In this example, bad data is returned. There is no assert. valgrind does > not complain either. > It asserts if you recompile with -DSQLITE_DEBUG > > Is there an ETA on when 3.8.7.2 will be released? > Next

Re: [sqlite] sqlite bug report

In this example, bad data is returned. There is no assert. valgrind does not complain either. Is there an ETA on when 3.8.7.2 will be released? On Thu, Nov 13, 2014 at 1:12 PM, Richard Hipp wrote: > This is https://www.sqlite.org/src/info/094d39a4c95ee4 which has been >

Re: [sqlite] sqlite bug report

This is https://www.sqlite.org/src/info/094d39a4c95ee4 which has been fixed in trunk and will be fixed in 3.8.7.2. On Thu, Nov 13, 2014 at 1:05 PM, Hinrichsen, John wrote: > The following SQL produces an incorrect result with sqlite-3.8.7.1: > > CREATE TABLE A( > symbol

[sqlite] sqlite bug report

The following SQL produces an incorrect result with sqlite-3.8.7.1: CREATE TABLE A( symbol TEXT, type TEXT ); INSERT INTO A VALUES('ABCDEFG','chars'); INSERT INTO A VALUES('1234567890','num'); CREATE TABLE B( chars TEXT, num TEXT ); CREATE TABLE IF NOT EXISTS C AS SELECT A.symbol AS

Re: [sqlite] bug: "no such column" with UNION + subquery + GROUP BY + ORDER BY + COLLATE

RSmith wrote: > On 2014/11/08 14:21, Clemens Ladisch wrote: >> the following query fails to parse, although it should be valid: >> >>sqlite> select 1 union select 1 from (select 1 as x) group by x order by >> 1 collate binary; >>Error: no such column: x > > I don't see how that can ever

Re: [sqlite] bug: "no such column" with UNION + subquery + GROUP BY + ORDER BY + COLLATE

sers- >boun...@sqlite.org] On Behalf Of RSmith >Sent: Saturday, 8 November, 2014 06:01 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] bug: "no such column" with UNION + subquery + GROUP >BY + ORDER BY + COLLATE > > >On 2014/11/08 14:21, Clemens La

Re: [sqlite] bug: "no such column" with UNION + subquery + GROUP BY + ORDER BY + COLLATE

On 2014/11/08 14:21, Clemens Ladisch wrote: Hi, the following query fails to parse, although it should be valid: sqlite> select 1 union select 1 from (select 1 as x) group by x order by 1 collate binary; Error: no such column: x Will call the above Version A. I don't see how that

[sqlite] bug: "no such column" with UNION + subquery + GROUP BY + ORDER BY + COLLATE

Hi, the following query fails to parse, although it should be valid: sqlite> select 1 union select 1 from (select 1 as x) group by x order by 1 collate binary; Error: no such column: x originally reported by Michael Geier here:

Re: [sqlite] Bug report: typo in sqlite3.h

On 7 Nov 2014, at 9:18am, Philip Newton wrote: > The amalgamation-3080701 sqlite3.h file has a comment that reads, in part: > > ** These no-op macros are used in front of interfaces to mark those > ** interfaces as either deprecated or experimental. New applications >

[sqlite] Bug report: typo in vacuum.c

In amalgamation-3080701 in sqlite3.c, in a section apparently originally from vacuum.c, there is a comment that reads in part: ** Only 1x temporary space and only 1x writes would be required if ** the copy of step (3) were replace by deleting the original database ** and renaming the transient

[sqlite] Bug report: Inconsistent usage of "[Jj]ulian [Dd]ay ([Nn]umbers)" in date.c

In the sqlite-amalgamation-3080701, in included file "date.c", the comments refer, at various times, to: - julian day, julian day number, julian day numbers - Julian day number - Julian Day numbers - Julian Day Number These should probably be unified in terms of capitalisation. Also, there is a

[sqlite] Bug report: typo in sqlite3.c (global.c)

The amalgamation-3080701 contains in sqlite3.c a comment that reads in part: ** IMPORTANT: Changing the pending byte to any value other than ** 0x4000 results in an incompatible database file format! ** Changing the pending byte during operating results in undefined ** and dileterious

[sqlite] Bug report: typo in website

http://www.sqlite.org/amalgamation.html says: "The sqlite3.h file is also contained within the amalgamation, in the first few of thousand lines." I'm guessing that used to read "the first couple of thousand lines". But with "few", the "of" is wrong; it should read "the first few thousand

[sqlite] Bug report: typo in sqlite3.h

The amalgamation-3080701 sqlite3.h file has a comment that reads, in part: ** These no-op macros are used in front of interfaces to mark those ** interfaces as either deprecated or experimental. New applications ** should not use deprecated interfaces - they are support for backwards **

[sqlite] bug, or misuse? crash using sqlite3_mutex_alloc()...

I am doing the following, which causes a crash: sqlite3_mutex_enter(sqlite3_mutex_alloc(SQLITE_MUTEX_STATIC_MASTER)); The crash occus if this is the first sqlite call I make. Looking at the source, there is a line: if( id<=SQLITE_MUTEX_RECURSIVE && sqlite3_initialize() ) return 0; Since

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

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

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

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 their own address space.) If not (and I think

Re: [sqlite] Bug and fix in lemon.c

Am Freitag, 12. September 2014, 18:59:24 schrieb Richard Hipp: > On Fri, Sep 12, 2014 at 7:23 AM, Benjamin Franksen < > benjamin.frank...@helmholtz-berlin.de> wrote: > > I am using the lemon parser generator for a different project. It > > appears that an attempt to pro-actively avoid a 64-bit

Re: [sqlite] BUG: Aggregate functions in subqueries

On Sep 15, 2014, at 4:48 PM, Richard Hipp wrote: > On Sun, Sep 14, 2014 at 12:18 AM, Lea Verou wrote: > >> Per the 3.7.11 changelog [1], queries of the form SELECT max(x), y FROM >> table return the value of y from the same row that contains the maximum x >>

Re: [sqlite] BUG: Aggregate functions in subqueries

On Sun, Sep 14, 2014 at 12:18 AM, Lea Verou wrote: > Per the 3.7.11 changelog [1], queries of the form SELECT max(x), y FROM > table return the value of y from the same row that contains the maximum x > value. However, this: > > select y from (SELECT max(x), y FROM table); > >

<    3   4   5   6   7   8   9   10   11   12   >