[sqlite] Bug: Using custom function seems to not work on Universal App Platformv. 3.10.2.0 x86 build only

Thanks for Your response. I am using Cdecl calling convention in all dll import attributes (using parameter to set it). I found here: http://www.sqlite.org/cvstrac/wiki? p=SqliteWikiFaq that it is the right one. I tried to check all available calling conventions (Cdecl, StdCall, ThisCall,

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 7 Feb 2016, at 1:51pm, Bernard McNeill wrote: > Is it correct to say that, under Linux, if SQLITE_EXTRA_DURABLE is set (and > all other settings are left as default values), and with the further > assumption that the hardware > reports write status accurately to the OS, then SQLITE_OK will

[sqlite] Bug: Successfully committed transaction rolled back after power failure

=== https://www.sqlite.org/src/timeline?y=ci=af92401826f5cf49e62c === To clarify: Is it correct to say that, under Linux, if SQLITE_EXTRA_DURABLE is set (and all other settings are left as default values), and with the further assumption that the hardware reports write status accurately to

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Please can I formally propose that, for Linux: 1. A Pragma or other compile-time option is created such that SQLITE_OK is not issued on file writes/modifications/deletes until the hardware indicates that all associated Directory syncs, etc., are done. 2. Since the absence of 1. appears to break

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 2/6/16, Bernard McNeill wrote: > Please can I formally propose that, for Linux: > 1. A Pragma or other compile-time option is created such that SQLITE_OK is > not issued on file writes/modifications/deletes until the hardware > indicates that all associated Directory syncs, etc., are done.

[sqlite] Bug: Using custom function seems to not work on Universal App Platformv. 3.10.2.0 x86 build only

by > brakepoint) but SqLite ?step? into result works only for arm and x64 build > ? for x86crashes with .Net NullReferenceException. > > I attached zipped test project (Visual Studio 2015 with UAP SDK is > required) ? have to change build platforms only (x86,x64,arm) to get this > case.

[sqlite] Bug: Using custom function seems to not work on Universal App Platformv. 3.10.2.0 x86 build only

NullReferenceException. I attached zipped test project (Visual Studio 2015 with UAP SDK is required) ? have to change build platforms only (x86,x64,arm) to get this case. I think it could be SqLite bug in x86 dll. Best regards, Artur Kr?l

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Wed, 03 Feb 2016 06:30:13 -0700 "Keith Medcalf" wrote: > > Is this on windows? Any errors in the Eventlogs to the tune "Oooopsie -- > accidentally threw away your data instead of writing it to disk"? Windows > does this quite commonly under some circumstances. MicroSoft created the bug

[sqlite] Bug: Successfully committed transaction rolled back after power failure

> Is this on windows? The original problem was on QNX 6.5 employing a QNX6 filesystem on mNAND flash. S.M. -- Dipl.-Phys. (Univ) Stefan Meinlschmidt, Senior Software Engineer Am Wolfsmantel 46, 91058 Tennenlohe, Germany Tel: +49-8458-3332-531 stefan.meinlschmidt at esolutions.de Fax:

[sqlite] Bug: Successfully committed transaction rolled back after power failure

2 February, 2016 14:58 > To: sqlite-users at mailinglists.sqlite.org > Subject: Re: [sqlite] Bug: Successfully committed transaction rolled back > after power failure > > On Thu, 28 Jan 2016 14:55:28 + > Simon Slavin wrote: > > > > > On 28 Jan 2016, at 1:38pm, Be

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Thu, 28 Jan 2016 14:55:28 + Simon Slavin wrote: > > On 28 Jan 2016, at 1:38pm, Bernard McNeill wrote: > > > === > > Like the user reading ?saving OK? and throwing away the > > Post-It with the original information > > === > > > > This is exactly my concern. > > The user throwing away

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Sun, 31 Jan 2016 20:27:56 -0700 Scott Robison wrote: > On Sun, Jan 31, 2016 at 7:35 PM, Rowan Worth wrote: > > > On 31 January 2016 at 03:56, James K. Lowden > > wrote: > > > > > Surely SQLite does both -- fsync on file and directory -- as part > > > of a commit. That's not in doubt, is

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 2 February 2016 at 08:22, Stephen Chrzanowski wrote: > On Mon, Feb 1, 2016 at 11:20 AM, Rowan Worth wrote: > As I indicated in the last paragraph of my mail, I'm not in favour of > > fsync-directory-on-commit in the general case. But that's because I worry > > about the performance impact,

[sqlite] Bug: Successfully committed transaction rolled back after power failure

> Le 2 f?vr. 2016 ? 03:25, Rowan Worth a ?crit : > > To reiterate, I don't have a problem with sqlite's behaviour at all. I > think it's perfectly acceptable. But I think it deserves to be acknowledged > and understood for what it is; a pragmatic decision by sqlite to improve > performance in

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Hi Stephen, On 1 February 2016 at 21:45, Stephen Chrzanowski wrote: > > SQLite is nothing more than part of a program run by the OS. It completely > relies on whatever the OS tells it. If the OS tells it that things are OK, > then that is all that can be done. SQLite can't take on the

[sqlite] Bug: Successfully committed transaction rolled back after power failure

on O2 -Original Message- From: Rowan Worth <row...@dugeo.com> Sender: sqlite-users-bounces at mailinglists.sqlite.orgDate: Tue, 2 Feb 2016 00:20:55 To: SQLite mailing list Reply-To: SQLite mailing list Subject: Re: [sqlite] Bug: Successfully committed transaction rolled back after

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 1 February 2016 at 18:58, Simon Slavin wrote: > > On 1 Feb 2016, at 9:23am, bm.email01 at gmail.com wrote: > > > --- > > No, SQLite does not. On COMMIT it fsyncs the database file and unlinks > the > > journal[1], but does not fsync the directory. > > --- > > > > Since that can cause the last

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Mon, Feb 1, 2016 at 11:20 AM, Rowan Worth wrote: > > > I've seen situations > > where files have been deleted in Linux (Not allowed in Windows) and data > > still gets dumped into the now deleted file. > > > ? > This is not an error, this is standard POSIX file semantics - if you have a >

[sqlite] Bug: Successfully committed transaction rolled back after power failure

This is steering off topic, but, here's my deal with computers as a whole. Bluntly, I love them, I can't be without them, and I wouldn't change my experiences with them for anything. That doesn't mean that I implicitly trust them. My expectations are "low" because experience has taught me to

[sqlite] Bug: Successfully committed transaction rolled back after power failure

At 17:55 01/02/2016, you wrote: >The above about implementation of RAID is good. There were battery >backed up caching controllers 20 years ago. In the event of a power >loss, the cached writes could be completed later. I run such one RAID Areca controller with 8 server disks in RAID6. Even

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Stephen Chrzanowski wrote: > @Rowan; > > First off, whether the OS or SQLite is ACID or not, if you pull the plug on > your hardware, all bets are off on whether it'll BOOT, let alone recover a > single transaction. I get that this could be a useful tool when doing > disaster proofing, but, at

[sqlite] Bug: Successfully committed transaction rolled back after power failure

At the risk of repeating something mentioned last week on this thread. One tactic to reduce/avoid the no-directory sync problem is to use WAL mode. The commit in WAL is write to the WAL file, so the the directory sync problem goes away. If you want to be in paranoid mode, don't trust others. Why

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 1 Feb 2016, at 11:24am, Rowan Worth wrote: > > I take your point, but as Florian pointed out it's not just one file > system; its a somewhat well known quirk of POSIX fsync. > http://blog.httrack.com/blog/2013/11/15/everything-you-always-wanted-to-know-about-fsync/ > > It's a bit

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 01/25/2016 04:47 PM, Richard Hipp wrote: > On 1/25/16, Matthias-Christian Ott wrote: >> >> Does this mean that if I use SQLite SQLITE_EXTRA_DURABLE=0, PRAGMA >> journal_mode=DELETE and PRAGMA synchronous=FULL, SQLite could loose a >> transaction that it said to be committed depending on the

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 1 Feb 2016, at 9:23am, bm.email01 at gmail.com wrote: > --- > No, SQLite does not. On COMMIT it fsyncs the database file and unlinks the > journal[1], but does not fsync the directory. > --- > > Since that can cause the last transaction to be lost, despite Sqlite > returning a 'Commit

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 31 January 2016 at 03:56, James K. Lowden wrote: > Surely SQLite does both -- fsync on file and directory -- as part of a > commit. That's not in doubt, is it? > No, SQLite does not. On COMMIT it fsyncs the database file and unlinks the journal[1], but does not fsync the directory. This is

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Mon, Feb 1, 2016 at 9:55 AM, Adam Devita wrote: > At the risk of repeating something mentioned last week on this thread. > One tactic to reduce/avoid the no-directory sync problem is to use WAL > mode. The commit in WAL is write to the WAL file, so the the directory > sync problem goes away.

[sqlite] Bug: Successfully committed transaction rolled back after power failure

g list Subject: Re: [sqlite] Bug: Successfully committed transaction rolled back after power failure On 31 January 2016 at 03:56, James K. Lowden wrote: > Surely SQLite does both -- fsync on file and directory -- as part of a > commit. That's not in doubt, is it? > No, SQLite does not. On C

[sqlite] Bug: Successfully committed transaction rolled back after power failure

@Rowan; First off, whether the OS or SQLite is ACID or not, if you pull the plug on your hardware, all bets are off on whether it'll BOOT, let alone recover a single transaction. I get that this could be a useful tool when doing disaster proofing, but, at that stage in the game of

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Sun, Jan 31, 2016 at 7:35 PM, Rowan Worth wrote: > On 31 January 2016 at 03:56, James K. Lowden > wrote: > > > Surely SQLite does both -- fsync on file and directory -- as part of a > > commit. That's not in doubt, is it? > > > > No, SQLite does not. On COMMIT it fsyncs the database file and

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Sat, 30 Jan 2016 20:00:19 + Simon Slavin wrote: > On 30 Jan 2016, at 7:56pm, James K. Lowden > wrote: > > > Given that the fsync has returned successfully, I don't know of any > > hardware that then will take 1000 ms to complete the write. That's > > the basis for my "subsecond

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 30 Jan 2016, at 7:56pm, James K. Lowden wrote: > Given that the fsync has returned successfully, I don't know of any > hardware that then will take 1000 ms to complete the write. That's the > basis for my "subsecond interval" assumption. Writing to a RAID which has other write commands

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Thu, 28 Jan 2016 08:00:08 + Meinlschmidt Stefan wrote: > > But I ask you, what action could the application possibly take, in > > that subsecond interval, that it matters? > > Under the QNX OS using a QNX6 filesystem with default configuration, > that ?subsecond interval? is actually up

[sqlite] Bug: Successfully committed transaction rolled back after power failure

at you pay for. > -Original Message- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin > Sent: Saturday, 30 January, 2016 13:00 > To: SQLite mailing list > Subject: Re: [sqlite] Bug: Succes

[sqlite] Bug: Successfully committed transaction rolled back after power failure

=== ...you must fsync the containing directory... === Is there an Sqlite option to achieve that? In fact, to summarise: Suppose I would like to maximise my chances of avoiding the 'Lost Post-It' problem described above. What are _all_ the Sqlite compile-time options, and their values, needed

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Simon Slavin wrote: > > On 28 Jan 2016, at 1:38pm, Bernard McNeill wrote: > >> === >> Like the user reading ?saving OK? and throwing away the >> Post-It with the original information >> === >> >> This is exactly my concern. >> The user throwing away the Post-It is entirely reasonable if he sees a

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 28 Jan 2016, at 1:38pm, Bernard McNeill wrote: > === > Like the user reading ?saving OK? and throwing away the > Post-It with the original information > === > > This is exactly my concern. > The user throwing away the Post-It is entirely reasonable if he sees a > message like that. > > Do

[sqlite] Bug: Successfully committed transaction rolled back after power failure

> === > Like the user reading ?saving OK? and throwing away the > Post-It with the original information > === > > This is exactly my concern. > The user throwing away the Post-It is entirely reasonable if he sees a > message like that. > > Do you happen to know if Linux/Debian (which I think

[sqlite] Bug: Successfully committed transaction rolled back after power failure

=== Like the user reading ?saving OK? and throwing away the Post-It with the original information === This is exactly my concern. The user throwing away the Post-It is entirely reasonable if he sees a message like that. Do you happen to know if Linux/Debian (which I think uses a journalling

[sqlite] Bug: Successfully committed transaction rolled back after power failure

>> Using the standard defaults (which avoid WAL), is there any >> possibility whatsoever of that last SQL transaction being lost? > > I have an unusual answer: Yes, and it doesn't matter. While I agree in principle, your answer depends on some assumptions that need not hold. > Let's suppose,

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Wed, 27 Jan 2016 08:51:16 + Bernard McNeill wrote: > Using the standard defaults (which avoid WAL), is there any > possibility whatsoever of that last SQL transaction being lost? I have an unusual answer: Yes, and it doesn't matter. Let's suppose, as you did, that the application got

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 25 January 2016 at 18:26, Meinlschmidt Stefan < Stefan.Meinlschmidt at esolutions.de> wrote: > > In your case it sounds like a controlled shutdown - is there a reason you > > don't do a full disk sync before that? > > Yes, it is a controlled shutdown, so in my case the /* post-commit logic >

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 27 Jan 2016, at 8:51am, Bernard McNeill wrote: > Situation: Under Linux/Debian, Sqlite opens an entirely valid DB, and runs > an entirely valid SQL transaction against that database. > Following a Commit, the application gets back a 'Commit Successful' code. > (Ignore any issues of disks

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Just to be clear Situation: Under Linux/Debian, Sqlite opens an entirely valid DB, and runs an entirely valid SQL transaction against that database. Following a Commit, the application gets back a 'Commit Successful' code. (Ignore any issues of disks returning hardware 'write done' flags

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Richard Hipp wrote: > On 1/25/16, Howard Chu wrote: >> >> This is actually quite an unusual requirement; on older Unix systems you >> couldn't even *open* a directory, let alone obtain write access to it or >> fsync it. > > Yeah. When the SQLITE_DISABLE_DIRSYNC compile-time option is present, >

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Jan 25, 2016, at 8:47 AM, Richard Hipp wrote: > > The feedback I receive is that most users of SQLite would much rather > avoid the extra directory syncs, even if it means having the last > transaction rollback following a power loss. Why not do the directory fsync in sqlite3_close_v2()? As

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 2016/01/25 5:08 PM, Matthias-Christian Ott wrote: > On 25/01/16 14:14, Richard Hipp wrote: >> On 1/19/16, Meinlschmidt Stefan wrote: >>> Shutting down power right after a successfully committed >>> transaction rolls back that transaction on next startup. >> Patches checked in: >> >>

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 2016-01-25 16:47, Richard Hipp wrote: > On 1/25/16, Matthias-Christian Ott wrote: >> >> Does this mean that if I use SQLite SQLITE_EXTRA_DURABLE=0, PRAGMA >> journal_mode=DELETE and PRAGMA synchronous=FULL, SQLite could loose a >> transaction that it said to be committed depending on the VFS?

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Matthias-Christian Ott wrote: > On 2016-01-25 16:47, Richard Hipp wrote: >> On 1/25/16, Matthias-Christian Ott wrote: >>> >>> Does this mean that if I use SQLite SQLITE_EXTRA_DURABLE=0, PRAGMA >>> journal_mode=DELETE and PRAGMA synchronous=FULL, SQLite could loose a >>> transaction that it said

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Mon, Jan 25, 2016 at 5:08 PM, Richard Hipp wrote: > On 1/25/16, Stephen Chrzanowski wrote: > > > > You also have to look at balance across many millions (or is it > billions?) > > of devices out there that use SQLite for their primary operations. > > Billions and billions. >

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 1/25/16, Howard Chu wrote: > > This is actually quite an unusual requirement; on older Unix systems you > couldn't even *open* a directory, let alone obtain write access to it or > fsync it. Yeah. When the SQLITE_DISABLE_DIRSYNC compile-time option is present, we disable the directory sync

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 25/01/16 14:14, Richard Hipp wrote: > On 1/19/16, Meinlschmidt Stefan wrote: >> >> Shutting down power right after a successfully committed >> transaction rolls back that transaction on next startup. > > Patches checked in: > > https://www.sqlite.org/src/info/30671345b1c1ee55 >

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 1/25/16, Stephen Chrzanowski wrote: > > You also have to look at balance across many millions (or is it billions?) > of devices out there that use SQLite for their primary operations. Billions and billions. > Slapping a serious performance decrease on devices where time and > performance is

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Mon, Jan 25, 2016 at 10:08 AM, Matthias-Christian Ott wrote: > > If so, why isn't SQLITE_EXTRA_DURABLE=1 the default? Should correctness > be more important than performance, except when the constraints are such > that correctness has to be sacrificed for performance? > I wouldn't want that,

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 1/25/16, Matthias-Christian Ott wrote: > > Does this mean that if I use SQLite SQLITE_EXTRA_DURABLE=0, PRAGMA > journal_mode=DELETE and PRAGMA synchronous=FULL, SQLite could loose a > transaction that it said to be committed depending on the VFS? Sort of. This appears to be true if you are

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Hi Rowan! >> Shutting down power right after a successfully committed >> transaction rolls back that transaction on next startup. > > nitpick: This is sqlite behaving as advertised. See > https://www.sqlite.org/lockingv3.html section 5.0 step 6, and > https://www.sqlite.org/atomiccommit.html

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 1/19/16, Meinlschmidt Stefan wrote: > > Shutting down power right after a successfully committed > transaction rolls back that transaction on next startup. Patches checked in: https://www.sqlite.org/src/info/30671345b1c1ee55 https://www.sqlite.org/draft/compile.html#extra_durable --

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On 1/19/16, Meinlschmidt Stefan wrote: > > Shutting down power right after a successfully committed > transaction rolls back that transaction on next startup. As you observe, this is a file-system dependent thing, and probably only happens on the QNX filesystem. I will see if we can add a

[sqlite] Bug: Successfully committed transaction rolled back after power failure

> Shutting down power right after a successfully committed > transaction rolls back that transaction on next startup. nitpick: This is sqlite behaving as advertised. See https://www.sqlite.org/lockingv3.html section 5.0 step 6, and https://www.sqlite.org/atomiccommit.html section 3.11 which

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Hi everybody! TL;DR: Shutting down power right after a successfully committed transaction rolls back that transaction on next startup. This is a problem in write-on-shutdown-then-power-off scenarios and violates my expectation of SQLite's transactions being ACID. This can be fixed by setting the

[sqlite] Bug in openDatabase function with patch

Hello ! When testing one application that uses sqlite3 with "-fsanitize=address" I was getting an error: ==1310==ERROR: AddressSanitizer: heap-use-after-free on address And after study the code I found that the problem is in the function openDatabase in src/main.c , it only happens when

[sqlite] Bug in sqlite3_prepare16_v2

On 2016/01/09 6:07 PM, Bart Smissaert wrote: > Ah, OK, overlooked that. > It means that sqlite3_prepare can't be used to check the validity of pragma > statements, also because the pragma could actually run! > Thanks for pointing me to this. > Will need to add some parsing code. Aye, I do this

[sqlite] Bug in sqlite3_prepare16_v2

On 2016/01/09 5:22 PM, Bart Smissaert wrote: > If I run sqlite3_prepare16_v2 on this statement: > > PRAGMA compile_optionsXXX > > I get a return value of 0 and there is a non-zero statement handle. > I would expect a return value of 1 and a zero statement handle. > > But if I run instead

[sqlite] Bug in sqlite3_prepare16_v2

Ah, OK, overlooked that. It means that sqlite3_prepare can't be used to check the validity of pragma statements, also because the pragma could actually run! Thanks for pointing me to this. Will need to add some parsing code. RBS On Sat, Jan 9, 2016 at 3:57 PM, Richard Hipp wrote: > On 1/9/16,

[sqlite] Bug in sqlite3_prepare16_v2

If I run sqlite3_prepare16_v2 on this statement: PRAGMA compile_optionsXXX I get a return value of 0 and there is a non-zero statement handle. I would expect a return value of 1 and a zero statement handle. But if I run instead sqlite3_prepare16_v2 on this statement: PRAGMA compile_options XXX

[sqlite] Bug in sqlite3_prepare16_v2

On 1/9/16, Bart Smissaert wrote: > If I run sqlite3_prepare16_v2 on this statement: > > PRAGMA compile_optionsXXX > > I get a return value of 0 and there is a non-zero statement handle. > I would expect a return value of 1 and a zero statement handle.

[sqlite] sqlite bug report

Bug report I downloaded sqlite 3.10.0 released in 2016-1-6, earlier I downloaded sqlite 3.9.2 and earlier version. I found below 2 bugs: bug1: Database directory which contains Simplified Chinese Character not support. bug2: Simplified Chinese Character in database table display error. bug1:

[sqlite] Apparent sqlite bug

> On 3 Jan 2016, at 6:52pm, Richard Hipp wrote: > > On 1/3/16, Simon Slavin wrote: >> >> I've seen references to imposter tables in the SQLite comments. What is an >> imposter table ? > > An undocumented and unsupported feature that allows two or tables in > the schema to refer to the same

[sqlite] Apparent sqlite bug

On 03-01-16 00:11, richard parkins wrote: > An INSERT statement which fails with no explicit conflict clause appears to > throw away a pending SAVEPOINT. > The following sequence demonstrates this behaviour > SAVEPOINT demonstration; > CREATE TABLE IF NOT EXISTS "PK" ( "first name" "TEXT", >

[sqlite] Apparent sqlite bug

On 3 Jan 2016, at 5:49pm, Richard Hipp wrote: > /* Make sure every column of the PRIMARY KEY is NOT NULL. (Except, > ** do not enforce this for imposter tables.) */ I've seen references to imposter tables in the SQLite comments. What is an imposter table ? Simon.

[sqlite] Apparent sqlite bug

On 1/3/16, Simon Slavin wrote: > > On 3 Jan 2016, at 5:49pm, Richard Hipp wrote: > >> /* Make sure every column of the PRIMARY KEY is NOT NULL. (Except, >> ** do not enforce this for imposter tables.) */ > > I've seen references to imposter tables in the SQLite comments. What is an >

[sqlite] Apparent sqlite bug

On 1/3/16, Luuk wrote: > > > On 03-01-16 00:11, richard parkins wrote: >> An INSERT statement which fails with no explicit conflict clause appears >> to throw away a pending SAVEPOINT. >> The following sequence demonstrates this behaviour >> SAVEPOINT demonstration; >> CREATE TABLE IF NOT EXISTS

[sqlite] Apparent sqlite bug

An INSERT statement which fails with no explicit conflict clause appears to throw away a pending SAVEPOINT. The following sequence demonstrates this behaviour SAVEPOINT demonstration; CREATE TABLE IF NOT EXISTS "PK" ( "first name" "TEXT", "last name" "TEXT", "address", PRIMARY KEY ( "first name",

[sqlite] Bug with DATETIME('localtime')

On Sun, 13 Dec 2015 20:11:32 -0700 Scott Robison wrote: > > It's not fixed, although gacial progress is being made. Even though > > we've had the TZ database & Posix datetime functions since 1986, 30 > > years later we're still struggling with it, and not only on Windows. > > The problem would

[sqlite] bug when columns are missing in embedded subselect

20:50 An: sqlite-users at mailinglists.sqlite.org Betreff: [sqlite] bug when columns are missing in embedded subselect Consider the following table definitions: DROP TABLE IF EXISTS flightplans; CREATE TABLE flightplans ( id text NOT NULL, ident text, recvd integer, orig

[sqlite] bug when columns are missing in embedded subselect

I work for a flight planning software house, so I had to take a double-look at this. Competition, eh? ;) On Tue, Dec 15, 2015 at 4:14 PM, Richard Hipp wrote: > > > Interesting timing: I was monitoring an inbound flight on flightaware > when this issue report arrived in my inbox. :-) > > -- >

[sqlite] bug when columns are missing in embedded subselect

Consider the following table definitions: DROP TABLE IF EXISTS flightplans; CREATE TABLE flightplans ( id text NOT NULL, ident text, recvd integer, orig text, dest text, PRIMARY KEY (id) ); DROP TABLE IF EXISTS inflight; CREATE TABLE inflight ( fp text,

[sqlite] bug when columns are missing in embedded subselect

On 12/15/15, Karl Lehenbauer wrote: > > sqlite> select fp from flightplans; > > Error: no such column: fp > > But if I select a column that doesn?t exist within an embedded subquery, it > is not an error? > > sqlite> delete from inflight where fp in (select fp from flightplans); > The "fp" in

[sqlite] Bug: sqlite ships with old autotools

Dear SQLite developers, The newest released version 3.9.2 of sqlite-autotools ships with an old version of autotools. In particular, it fails to compile on this system: $ uname -a Linux sardonis 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:13 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux

[sqlite] Bug with DATETIME('localtime')

>... >We need a metric calendar. I propose redefining the second so that a day is >100,000 seconds long... ;) > >-- >Scott Robison And while we are already redefining the fundamental constants of measuring, we could redefine the meter to be exactly three feet and the kilogram to be exactly two

[sqlite] Bug with DATETIME('localtime')

On Sun, Dec 13, 2015 at 6:44 PM, Keith Medcalf wrote: > We have been doing daylight savings changes to and from twice a year for > as long as I remember (that is more than 100 times) and we still cannot > manage to do it properly. Leap years have been occurring for a long time > and somehow we

[sqlite] Bug with DATETIME('localtime')

nces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of James K. Lowden > Sent: Sunday, 13 December, 2015 19:00 > To: sqlite-users at mailinglists.sqlite.org > Subject: Re: [sqlite] Bug with DATETIME('localtime') > > On Thu,

[sqlite] Bug with DATETIME('localtime')

On Sun, Dec 13, 2015 at 5:00 PM, James K. Lowden wrote: > On Thu, 10 Dec 2015 06:34:44 -0700 > "Keith Medcalf" wrote: > > > The only way to convert datetime data on windows is to use a > > third-party package that does it properly, or write it yourself. > > Using the WinAPI functions is

[sqlite] Bug with DATETIME('localtime')

On Thu, 10 Dec 2015 06:34:44 -0700 "Keith Medcalf" wrote: > The only way to convert datetime data on windows is to use a > third-party package that does it properly, or write it yourself. > Using the WinAPI functions is equivalent to "writing it yourself" > because they do not actually do

[sqlite] Bug with DATETIME('localtime')

:49 > To: sqlite-users at mailinglists.sqlite.org > Subject: [sqlite] Bug with DATETIME('localtime') > > Hi, > I've found a bug with using 'localtime' in functions DATETIME(), DATE(), > TIME(). > > Platform: Windows 7. > Steps to reproduce: > 1. Set your system time z

[sqlite] Bug with DATETIME('localtime')

Hi, I've found a bug with using 'localtime' in functions DATETIME(), DATE(), TIME(). Platform: Windows 7. Steps to reproduce: 1. Set your system time zone as "Russia Time Zone 2, (UTC+03:00) Moscow, St. Petersburg, Volgograd)". 2. Execute the following script: SELECT DATETIME(1414267200,

[sqlite] Bug report for MAX()

Many thanks to all. I should have checked - That table was not supposed to be able to even get strings in there - this exposed a bug in an application of ours too. Adding check constraints right away. Thanks! On 2015/11/25 1:56 PM, Richard Hipp wrote: > On 11/25/15, Dave McKee wrote: >> I

[sqlite] Bug report for MAX()

It seems there are some instances where MAX() does not return a value. I will send such an offending DB direct, but the sqlite3.exe results as follows: F:\[BACKUP]>sqlite3.exe IPDB_ImptData.idb SQLite version 3.9.2 2015-11-02 18:31:45 Enter ".help" for usage hints. sqlite> SELECT max(UnitCost)

[sqlite] Bug report for MAX()

On 25 Nov 2015, at 11:39am, Dave McKee wrote: > Is this a possible explanation? You got it. This is part of what I was worried about. MAX processes not just numbers. It would be useful to know what kind of values Ryan has stored in that column. Simon.

[sqlite] Bug report for MAX()

I can replicate this behaviour if I insert a zero-length string into the column. sqlite> create table foo(a); sqlite> insert into foo values(5); sqlite> insert into foo values(""); sqlite> select max(a) from foo; sqlite> select min(a) from foo; 5 sqlite> select avg(a) from foo; 2.5 Is this a

[sqlite] Bug report for MAX()

On 25 Nov 2015, at 11:09am, R Smith wrote: > sqlite> SELECT max(UnitCost) FROM BOMData; > > sqlite> SELECT min(UnitCost) FROM BOMData; > 0.0 Can you please post the result of SELECT DISTINCT typeof(UnitCost) FROM BOMData; (I think that's how you do it. You might need to use GROUP BY.)

[sqlite] Bug report for MAX()

On 11/25/15, Dave McKee wrote: > I can replicate this behaviour if I insert a zero-length string into the > column. > > sqlite> create table foo(a); > sqlite> insert into foo values(5); > sqlite> insert into foo values(""); > sqlite> select max(a) from foo; > > sqlite> select min(a) from foo; > 5

[sqlite] bug in R-tree table syntax checking

Hi, creating an R-tree table with what looks like a table constraint results in an inconsistent number of columns, with funny results: > create virtual table t using rtree(id, x1, x2, y1, check(1)); > insert into t default values; > select * from t; 1|0.0|0.0|1.74906711200709e-38 Regards,

[sqlite] bug in PRAGMA ignore_check_constraints?

On Fri, 11 Sep 2015 02:02:05 +0100 Simon Slavin wrote: > Looking at > > > > maybe the 'constraints' that the documentation refers to are the ones > specifically declared using CHECK in the table definition. Perhaps > NOT NULL and UNIQUE

[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 @@ }

[sqlite] bug in PRAGMA ignore_check_constraints?

On 11 Sep 2015, at 1:17am, Peter Aronson wrote: > 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. Looking at

[sqlite] bug in PRAGMA ignore_check_constraints?

Meh. ?Formatting: sqlite> create table cc (c1 integer not null,c2 integer check(typeof(c2)<>'null')); sqlite> insert into cc values (null,null); Error: NOT NULL constraint failed: cc.c1 sqlite> insert into cc values (1,null); Error: CHECK constraint failed: cc sqlite> insert into cc values (1,1);

[sqlite] bug in PRAGMA ignore_check_constraints?

That would be my assumption. ?And experimentation seems to back it up (at least for NOT NULL): sqlite> create table cc (c1 integer not null,c2 integer check(typeof(c2)<>'null'));sqlite> insert into cc values (null,null);Error: NOT NULL constraint failed: cc.c1sqlite> insert into cc values

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