Re: [sqlite] Possible bug in storing text values in numeric columns

On 10/13/19, Shawn Wagner wrote: > The documentation for a column with NUMERIC affinity says > >> When text data is inserted into a NUMERIC column, the storage class of > the text is converted to INTEGER or REAL (in order of preference) if such > conversion is lossless and reversible. > Thank

Re: [sqlite] Possible bug in storing text values in numeric columns

On 10/13/2019 8:04 PM, Shawn Wagner wrote: That's what I told the guy having the original issue to do, yes. That's not important. My concern is why a conversion that's only supposed to happen if it's lossless is in fact happening and causing data loss. You define the term "lossless"

Re: [sqlite] Possible bug in storing text values in numeric columns

That's what I told the guy having the original issue to do, yes. That's not important. My concern is why a conversion that's only supposed to happen if it's lossless is in fact happening and causing data loss. On Sun, Oct 13, 2019, 4:48 PM Igor Tandetnik wrote: > On 10/13/2019 7:25 PM, Shawn

Re: [sqlite] Possible bug in storing text values in numeric columns

On 10/13/2019 7:25 PM, Shawn Wagner wrote: I wouldn't call that conversion, or any other, lossless unless it can be turned back into a string that's character for character identical with the one that was originally inserted. If you want the text preserved character for character, store it in

Re: [sqlite] Possible bug in storing text values in numeric columns

ell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users On >Behalf Of Shawn Wagner >Sent: Sunday, 13 October, 2019 17:26 >To: SQLite mailing list >Subject: Re: [sqlite] Possible bug in storing text values in

Re: [sqlite] Possible bug in storing text values in numeric columns

On October 13, 2019 7:25:50 p.m. EDT, Shawn Wagner wrote: >I wouldn't call that conversion, or any other, lossless unless it can >be >turned back into a string that's character for character identical with >the >one that was originally inserted. It's lossless if you consider the input as the

Re: [sqlite] Possible bug in storing text values in numeric columns

Yes, I know. (This all comes from someone on stack overflow who used "string" as a column type and thus ran into this issue because that of course results in numeric affinity) On Sun, Oct 13, 2019, 4:27 PM Simon Slavin wrote: > On 13 Oct 2019, at 10:11pm, Shawn Wagner wrote: > > > As you can

Re: [sqlite] Possible bug in storing text values in numeric columns

On 13 Oct 2019, at 10:11pm, Shawn Wagner wrote: > As you can see, the leading zeros in the original string are gone and it's > been converted to an integer. This seems to violate the "lossless and > reversible" constraint. Shouldn't it be kept as text? You defined the column as 'numeric'.

Re: [sqlite] Possible bug in storing text values in numeric columns

I wouldn't call that conversion, or any other, lossless unless it can be turned back into a string that's character for character identical with the one that was originally inserted. On Sun, Oct 13, 2019, 4:10 PM Igor Tandetnik wrote: > On 10/13/2019 5:11 PM, Shawn Wagner wrote: > > The

Re: [sqlite] Possible bug in storing text values in numeric columns

On 10/13/2019 5:11 PM, Shawn Wagner wrote: The documentation for a column with NUMERIC affinity says When text data is inserted into a NUMERIC column, the storage class of the text is converted to INTEGER or REAL (in order of preference) if such conversion is lossless and reversible.

Re: [sqlite] Possible bug in storing text values in numeric columns

3.30, though it goes back to at least 3.8.7 (the oldest version I have available to test with) On Sun, Oct 13, 2019, 3:03 PM Igor Korot wrote: > Hi, > > On Sun, Oct 13, 2019 at 4:12 PM Shawn Wagner > wrote: > > > > The documentation for a column with NUMERIC affinity says > > > > > When text

Re: [sqlite] Possible bug in storing text values in numeric columns

Hi, On Sun, Oct 13, 2019 at 4:12 PM Shawn Wagner wrote: > > The documentation for a column with NUMERIC affinity says > > > When text data is inserted into a NUMERIC column, the storage class of > the text is converted to INTEGER or REAL (in order of preference) if such > conversion is lossless

[sqlite] Possible bug in storing text values in numeric columns

The documentation for a column with NUMERIC affinity says > When text data is inserted into a NUMERIC column, the storage class of the text is converted to INTEGER or REAL (in order of preference) if such conversion is lossless and reversible. But consider: sqlite> create table foo(bar

Re: [sqlite] Possible bug in Alter Table

Nov 2018 14:11:54 -0500 Subject: Re: [sqlite] Possible bug in Alter Table On 11/25/18, Balaji Ramanathan wrote: > I expected the Alter Table command to find and replace all occurrences of > that column name in my schema with the new name. Here is simplified SQL that illustrates the problem:

Re: [sqlite] Possible bug in Alter Table

> On Nov 27, 2018, at 06:16, Wout Mertens wrote: > > If it's on a mac, this terrible misfeature can be turned off in system > preferences - keyboard - text - smart quotes. Oh my... right you are :| Grrr indeed. ___ sqlite-users mailing list

Re: [sqlite] Possible bug in Alter Table

> > > You have something mucking about and "helping you" to be cutie-pie. If > you turn that crap off, your problems will go away... > If it's on a mac, this terrible misfeature can be turned off in system preferences - keyboard - text - smart quotes. I lost a couple hours this way too, I

Re: [sqlite] Possible bug in Alter Table

On Monday, 26 November, 2018 12:19, Petite Abeille wrote: ... > Talking of which, the CLI doesn’t seem to handle the following > statement very gracefully: > > sqlite> select DATE '1998-12-25’; > ...> > ...> > …> >Note how the CLI doesn’t recognize the semicolon marking the end-of-

Re: [sqlite] Possible bug in Alter Table

> On Nov 26, 2018, at 21:16, Shawn Wagner wrote: > > It's waiting on a plain single quote to end the string. You have a Unicode > smart quote character U+2019 (’) instead of a ' at the end before the > semicolon, which doesn't count. D’oh. Facepalm. Right you are. Long live Unicode! :)

Re: [sqlite] Possible bug in Alter Table

It's waiting on a plain single quote to end the string. You have a Unicode smart quote character U+2019 (’) instead of a ' at the end before the semicolon, which doesn't count. On Mon, Nov 26, 2018, 11:19 AM Petite Abeille > > > On Nov 26, 2018, at 20:11, Richard Hipp wrote: > > > > though

Re: [sqlite] Possible bug in Alter Table

> On Nov 26, 2018, at 20:25, Richard Hipp wrote: > > Unable to repro: Hmmm… ok… then… local problem of some type… $ uname -a Darwin 18.2.0 Darwin Kernel Version 18.2.0: Fri Oct 5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64 x86_64 $ brew info sqlite3 sqlite: stable 3.25.3

Re: [sqlite] Possible bug in Alter Table

On 11/26/18, Petite Abeille wrote: > the CLI doesn’t seem to handle the following statement > very gracefully: > > sqlite> select DATE '1998-12-25’; > ...> > ...> > …> Unable to repro: SQLite version 3.25.3 2018-11-05 20:37:38 Enter ".help" for usage hints. Connected to a transient

Re: [sqlite] Possible bug in Alter Table

> On Nov 26, 2018, at 20:11, Richard Hipp wrote: > > though there probably is not time to get warnings in to the forthcoming > 3.26.0 release. Talking of which, the CLI doesn’t seem to handle the following statement very gracefully: sqlite> select DATE '1998-12-25’; ...> ...> …>

Re: [sqlite] Possible bug in Alter Table

On 11/25/18, Balaji Ramanathan wrote: > I expected the Alter Table command to find and replace all occurrences of > that column name in my schema with the new name. Here is simplified SQL that illustrates the problem: CREATE TABLE t1(x); CREATE VIEW v1 AS SELECT x FROM t1; CREATE VIEW v2 AS

Re: [sqlite] Possible bug in Alter Table

On Mon, Nov 26, 2018 at 2:52 AM Balaji Ramanathan < balaji.ramanat...@gmail.com> wrote: > SQLite> Alter Table Trip rename column StartGMTOffset to StartUTCOffset; > Error: error in view CumulativeStatisticsByPlaceName after rename: no such > column: StartGMTOffset > > I was able to reproduce this

[sqlite] Possible bug in Alter Table

Hi, I am writing to report a possible bug in the Alter Table command. It seems to fail on a somewhat complex schema with multiple tables and views, and views that reference other views. I was not able to come up with a simple one table, one view schema where this error actually shows up.

[sqlite] Possible bug in window function queries.

Been playing around with the new window functions in 3.25, and ran into something that looks like an infinite loop. Working with the t1 table many of the examples in the documentation use, I've come up with a minimal test case: sqlite> select id, b, lead(c, 1) over (order by c) as x from t1

Re: [sqlite] possible bug affecting 3.22 and 3.23 - load_extension()

I have checked in a change to address this on trunk. Meanwhile, your work-around is to include the ".so" suffix on the library name. xample: SELECT load_extension('mod_spatiallite.so'); On 5/6/18, a.furi...@lqt.it wrote: > it seems that some unexpected regression is

[sqlite] possible bug affecting 3.22 and 3.23 - load_extension()

it seems that some unexpected regression is affecting load_extension() on Linux when using the most recent versions of SQLite (3.22 and 3.23). my test configuration: - sqlite3 installed on the current directory - extension module installed on /usr/local/lib (/usr/local/lib/mod_spatialite.so)

Re: [sqlite] possible bug: select clause column alias shadowing

Jean-Christophe Deschamps wrote: > At 23:36 18/03/2018, you wrote: >> In other words, aliases in the SELECT clause are evaluated _after_ the >> FROM and WHERE clauses are done. > > I must be misinterpreting: I was talking about the SQL standard. (I might have mentioned that somewhere ...) >

Re: [sqlite] possible bug: select clause column alias shadowing

Compared to PostgreSQL, SQLite does a better job here when there is no input column collision. The column collision case below returns no rows in both SQLite and PostgreSQL: WITH t(a) AS (VALUES ('foo')) SELECT a||'!' AS a FROM t WHERE a='foo!'; But the following edit with intermediating alias

Re: [sqlite] possible bug: select clause column alias shadowing

On 3/18/2018 5:31 AM, Moritz Bruder wrote: I just came across a strange behaviour in sqlite3 (3.22.0 2018-01-22 18:45:57 0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2171d). Consider the following test case:     CREATE TABLE test (name varchar);     INSERT INTO test VALUES

Re: [sqlite] possible bug: select clause column alias shadowing

At 23:36 18/03/2018, you wrote: In other words, aliases in the SELECT clause are evaluated _after_ the FROM and WHERE clauses are done. The order of the SELECT/WHERE clauses in the SQL syntax is misleading; the actual behaviour would be better represented by something like this: ( FROM

Re: [sqlite] possible bug: select clause column alias shadowing

Simon Slavin wrote: > As best I can find, SQL92 does not specify what happens when you choose > an AS clause giving a value name the same as a column. | 7.3 | | Function | |Specify a table or a grouped table. | | Format | | ::= | | [ ] | [ ] | [ ] |

Re: [sqlite] possible bug: select clause column alias shadowing

On 18 Mar 2018, at 9:31am, Moritz Bruder wrote: > I'm not exactly sure what the SQL standard says As best I can find, SQL92 does not specify what happens when you choose an AS clause giving a value name the same as a column. It doesn't go into much detail at all

[sqlite] possible bug: select clause column alias shadowing

Hi, I just came across a strange behaviour in sqlite3 (3.22.0 2018-01-22 18:45:57 0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2171d). Consider the following test case:     CREATE TABLE test (name varchar);     INSERT INTO test VALUES ("foo"),("bar"); -- Returns a single row

Re: [sqlite] possible bug: separator string and quote mode

p dev wrote: > https://www.sqlite.org/cli.html 5. Changing Output Formats > > All columns are separated from each other by a comma (or whatever alternative > character is selected using ".separator"). This is indeed a bug in the documentation; quote mode ignores the .separator setting. > I

Re: [sqlite] possible bug: separator string and quote mode

Pamela. Shell .mode quote uses hardwired separator, presumably to rule out errors when the mode is requested to generate SQL compatible strings. It seems to me the enhancement you're requesting could be made backward compatible by using p->colSeparator instead of the hardwired ',' and then

[sqlite] possible bug: separator string and quote mode

I have been using SQLite for a small data-processing application. I am hoping to get quote mode output with a field separator that is not a comma.Many thanks, Pamela-- Problem Quote mode output ignores separator string Background https://www.sqlite.org/cli.html5. Changing Output

Re: [sqlite] Possible bug when adding "on delete cascade" via DB Browser for SQLite

DB Browser for SQLite is a third party product which just uses SQLite. Any support issues should be directed to their gitHub support page. https://github.com/sqlitebrowser/sqlitebrowser/issues To confirm whether its an issue in DB Browser for SQLite or SQLite itself, you can 'reproduce' the

[sqlite] Possible bug when adding "on delete cascade" via DB Browser for SQLite

Today I used DB Browser for SQLite, version 3.10.1 on a windows 7 machine, and encountered what seems to be a bug, either in the SQLite browser or SQLite as such. If this is not the correct mailing list to post this in I apologize, just let me know. I had a table with foreign keys, and

[sqlite] Possible bug when compiling with SQLITE_OMIT_TRIGGER option

Hello, I'm trying to create a minimal SQLite3 library build and seems like the foreign keys logic is not properly run on DELETE when building the sources with -DSQLITE_OMIT_TRIGGER=1. Here's the patch against amalgamation v3.21.0 sqlite.c: --- sqlite3.c.orig 2017-12-08 14:06:04.814913000 +0100

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

I feel safer now :) On Fri, Oct 13, 2017, 12:57 PM Rowan Worth wrote: > In that case you would be well advised to use a monotonic clock source, > rather than a "date-generating" clock. In linux this is the difference > between providing CLOCK_MONOTONIC or CLOCK_REALTIME as the

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

In that case you would be well advised to use a monotonic clock source, rather than a "date-generating" clock. In linux this is the difference between providing CLOCK_MONOTONIC or CLOCK_REALTIME as the first argument to clock_gettime(). But any API you might use to set a trigger for 2 seconds

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

On 2017/10/13 12:42 PM, Wout Mertens wrote: Thank you, very interesting! The leap second behavior is slightly worrying, basically anything time-based (animations etc) will take a second longer? What if you want an engine burn to last 2 seconds, set a trigger for 2 seconds from now, and then

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

Thank you, very interesting! The leap second behavior is slightly worrying, basically anything time-based (animations etc) will take a second longer? What if you want an engine burn to last 2 seconds, set a trigger for 2 seconds from now, and then it's burning 50% longer? On Thu, Oct 12, 2017,

[sqlite] Possible bug with strftime('%s') < strftime('%s')

This has not much to do with the original question, but as physicist I cannot resist: National institutes (NIST in the US, NPL in the UK, PTB in Germany, to name just a few) provide reference times in UTC, which are distributed nowadays also via the internet, e.g. the NTP protocol. Therefore

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

>Better yet, either one of the datetime() or julianday() functions >(with the same one used consistently in all places) will work best >for comparison since the output for either one sorts correctly >against itself. strftime() should be saved for display formatting. Only for a timestring with a

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

sqlite> select datetime('now', '+300 seconds') < datetime('now'); > 0 > > sqlite> select datetime('now', '-300 seconds') < datetime('now'); > 1 > > -Original Message- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > On Behalf

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

-300 seconds') < datetime('now'); 1 -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Don V Nielsen Sent: Wednesday, October 11, 2017 1:15 PM To: SQLite mailing list Subject: Re: [sqlite] Possible bug with strftime('%s') < strfti

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

On 11 Oct 2017, at 18:53, R Smith wrote: > Yes. When you concatenate/add a string and integer together some SQL > engines will try to give a sensible result, so that '5' + 3 will yield 8 > because 3 is INT and it reckons that '5' probably meant 5 since it is > added to

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

On 2017/10/11 7:15 PM, Don V Nielsen wrote: So strftime always returns TEXT. Correct? Yes. The "str" in "strftime" means "string" which is text output. You can read the name "strftime" as "string-formatted-time value". It was the application of +300 to that result that changed the type to

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

17-10-11 10:04:43') + 300 < > strftime('%s','2017-10-11 10:04:43') + 0; > strftime('%s', '2017-10-11 10:04:43') + 300 < strftime('%s','2017-10-11 > 10:04:43') + 0 > 0 > > > -Original Message- > From: David Raymond > Sent: Wednesday, October 11, 2017 9:10 AM >

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

nal Message- From: David Raymond Sent: Wednesday, October 11, 2017 9:10 AM To: sqlite-users@mailinglists.sqlite.org Subject: RE: [sqlite] Possible bug with strftime('%s') < strftime('%s') See https://sqlite.org/draft/datatype3.html in section 4.1, Sort Order. Any integer is less than any te

Re: [sqlite] Possible bug with strftime('%s') < strftime('%s')

ice +1 603 306 8498 | www.tomtom.com -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Eric Bollengier Sent: Wednesday, October 11, 2017 8:55 AM To: sqlite-users@mailinglists.sqlite.org Subject: [sqlite] Possible bug with strfti

[sqlite] Possible bug with strftime('%s') < strftime('%s')

Hello, I have noticed a problem in SQLite 3.20.1 for a simple operation based on strftime('%s'). With SQLite 3.20.1 and 3.6.18 sqlite> select (strftime('%s', '2017-10-11 10:04:43') + 300) <  strftime('%s', '2017-10-11 10:04:43'); 1 If I use the CAST operator on the second member, it works

[sqlite] Possible bug in cli: .schema --indent mishandles trailing comments

Here is a sample output to illustrate the problem of mishandled trailing comments. The original create table statement included two leading spaces for each attribute. $ sqlite3 ~/db-lib/data.db SQLite version 3.17.0 2017-02-13 16:02:40 Enter ".help" for usage hints. sqlite> .schema rating_answer

Re: [sqlite] Possible bug when creating a calculated index

On 26 Jan 2017, at 11:33pm, Ersin Akinci wrote: > (Please someone correct me if I'm wrong here. I'm a SQLite n00b who > managed to stumble onto a subtle problem while debugging Rails. =) Nope, you got it right. And Michael has too. I took your original report and

Re: [sqlite] Possible bug when creating a calculated index

Thank you Simon, I do see the inconsistency and thanks for those examples. I had answered previously before I saw your explanation and I now see why there is concern. It certainly appears to be inconsistent given such use cases. On 27 January 2017 at 10:26, Michael Falconer

Re: [sqlite] Possible bug when creating a calculated index

Michael, I think part of the problem is that the "obviously" (or 'obviously', ha) useful behavior here would be for single quoted arguments to result in column interpretation. You're quite right to say that you want to be told that your column doesn't exist--that is very helpful information!. But

Re: [sqlite] Possible bug when creating a calculated index

Ersin, apologies if I seem to be suffering from terminal thickness, but I still don't get it. Why would I expect anything other than column interpretation from a single quoted argument. I *want to be told* that my column does not exist, I don't want a calculated index so why should I be expecting

Re: [sqlite] Possible bug when creating a calculated index

On 26 Jan 2017, at 10:56pm, Michael Falconer wrote: > as I see it there is no problem here. Explicit quoting regardless, the > column does not exist and an error is returned, isn't this the expected > outcome? Yet it’s not consistent. I should have given more

Re: [sqlite] Possible bug when creating a calculated index

Michael, If I understood DRH and Simon correctly, I think the cause for concern is that SQLite should be interpreting the single quotes as a string literal, yet it interprets it as a column. Perhaps it's a strange example (i.e., why would you want to index a string literal?), but still, the

Re: [sqlite] Possible bug when creating a calculated index

Simon, as I see it there is no problem here. Explicit quoting regardless, the column does not exist and an error is returned, isn't this the expected outcome? In the DRH quoted section a reason is presented as to why no error is returned due to a built in default action. This may or may not be a

Re: [sqlite] Possible bug when creating a calculated index

On 25 Jan 2017, at 12:50pm, Simon Slavin wrote: > Bug is as follows: Anyone ? Did I miss something and you’re all too polite to point it out ? Simon. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

[sqlite] Possible bug when creating a calculated index

Bug is as follows: SQLite version 3.14.0 2016-07-26 15:17:14 Enter ".help" for usage hints. sqlite> CREATE TABLE reports (a INT, b TEXT); sqlite> CREATE INDEX index_reports_quotes ON reports ("yearz_doesnt_exist"); sqlite> PRAGMA index_xinfo('index_reports_quotes'); 0|-2||0|BINARY|1

Re: [sqlite] Possible bug with union and join.

1; returns 0. -Ursprüngliche Nachricht- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Don V Nielsen Gesendet: Dienstag, 27. Dezember 2016 16:18 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: Re: [sqlite] Possible bug with u

Re: [sqlite] Possible bug with union and join.

Thanks for the correction/information! Merry Christmas and Happy New Year to you. On Tue, Dec 27, 2016 at 9:48 AM, Richard Hipp wrote: > On 12/27/16, Don V Nielsen wrote: >> Theory related question. I'm being argumentative, I know. But this >> issue is in

Re: [sqlite] Possible bug with union and join.

On 12/27/16, Don V Nielsen wrote: > Theory related question. I'm being argumentative, I know. But this > issue is in the same category as one discussed weeks ago. > > SQLite is, in a sense, typeless. All data is stored as text (ignore > blob). Correct? It is when one casts

Re: [sqlite] Possible bug with union and join.

Theory related question. I'm being argumentative, I know. But this issue is in the same category as one discussed weeks ago. SQLite is, in a sense, typeless. All data is stored as text (ignore blob). Correct? It is when one casts a column to something other than text that triggers SQLite to treat

Re: [sqlite] Possible bug with union and join.

Fortunately names of columns are much more transparent and documented in our internal specification. 'Id' was created only for example, but thanks for advice :) Adrian 2016-12-25 13:44 GMT+01:00 Simon Slavin : > > On 23 Dec 2016, at 4:55pm, Adrian Stachlewski

Re: [sqlite] Possible bug with union and join.

On 23 Dec 2016, at 4:55pm, Adrian Stachlewski wrote: > Id field in one table is defined as TEXT, because there are stored > identifiers which can be numeric or text mostly like in the example ("4", > "4,5", "10-1") (to be precise this map is created on the fly by >

Re: [sqlite] Possible bug with union and join.

Simon, Id field in one table is defined as TEXT, because there are stored identifiers which can be numeric or text mostly like in the example ("4", "4,5", "10-1") (to be precise this map is created on the fly by concatenating some ids and names from another tables). In second table there are

Re: [sqlite] Possible bug with union and join.

On 22 Dec 2016, at 5:55pm, Adrian Stachlewski wrote: > In this case I think that the best way to do this is cast integer column to > text. > CREATE VIEW id_map(id, name) as > SELECT CAST(id AS TEXT), name > FROM map_integer > UNION ALL > SELECT id, name > FROM

Re: [sqlite] Possible bug with union and join.

Richard, Thank you for your answer. Datatypes in sqlite was always weird for me, mostly the fact that for example TEXT can be inserted in INTEGER column. In this case I think that the best way to do this is cast integer column to text. CREATE VIEW id_map(id, name) as SELECT CAST(id AS TEXT),

Re: [sqlite] Possible bug with union and join.

On 12/22/16, David Raymond wrote: > Problem appears to be coming from an automatic index. Thanks for the insight, David. Automatic indexes do appear to be a factor, but not the only factor. The script below shows different answers depending on whether the VIEW is

Re: [sqlite] Possible bug with union and join.

6 8:14 AM To: sqlite-users@mailinglists.sqlite.org Subject: [sqlite] Possible bug with union and join. Hi everyone. When I was working with sqlite3 I've found weird behavior of JOIN clause when I was trying to merge table with union of tables. Let me explain this using database with reproduced problem.

[sqlite] Possible bug with union and join.

Hi everyone. When I was working with sqlite3 I've found weird behavior of JOIN clause when I was trying to merge table with union of tables. Let me explain this using database with reproduced problem. Database dump: CREATE TABLE map_integer (id INTEGER PRIMARY KEY, name TEXT); INSERT INTO

[sqlite] Possible bug with union and join.

Hi everyone. When I was working with sqlite3 I've found weird behavior of JOIN clause when I was trying to merge table with union of tables. Let me explain this using database with reproduced problem. Database dump: CREATE TABLE map_integer (id INTEGER PRIMARY KEY, name TEXT); INSERT INTO

Re: [sqlite] Possible Bug in VTable handling in SQLite 3.14.2

lite-users@mailinglists.sqlite.org Betreff: Re: [sqlite] Possible Bug in VTable handling in SQLite 3.14.2 On 10/14/2016 04:59 PM, Hick Gunter wrote: > In the vdbeaux.c source, the function > > resolveP2Values(...) > > is not resetting p->readOnly when it encounters an OP_VUpdate

Re: [sqlite] Possible Bug in VTable handling in SQLite 3.14.2

On 10/14/2016 04:59 PM, Hick Gunter wrote: In the vdbeaux.c source, the function resolveP2Values(...) is not resetting p->readOnly when it encounters an OP_VUpdate opcode is not setting p->bIsReader when it encounters an OP_VFilter opcode Additionally, the frunction sqlite3VdbeHalt(...)

[sqlite] Possible Bug in VTable handling in SQLite 3.14.2

In the vdbeaux.c source, the function resolveP2Values(...) is not resetting p->readOnly when it encounters an OP_VUpdate opcode is not setting p->bIsReader when it encounters an OP_VFilter opcode Additionally, the frunction sqlite3VdbeHalt(...) is only checking p->bIsReader and omitting to

[sqlite] Possible bug in SQLite in sqlite3VdbeSorterInit for PMA sorter size

I am using the option to set the main cache size *PRAGMA **schema.**cache_size = -**kibibytes**;* In function sqlite3VdbeSorterInit it seems that the calculation of mxCache does not take into account the above alternate way to set cache_size that uses the *-**kibibytes* option.

[sqlite] Possible bug in the SQL parser

Sorry for the late reply. That output (--1 etc.) was me manually "formatting" the results. I came across this issue using SQLiteStudio v3.0.7 on Windows. I just create a new DB and run that script: it outputs two rows, with one column each, with the values 1 and 2 respectively, instead of an

[sqlite] Possible bug

On 10 Mar 2016, at 4:43am, Marv Anderson wrote: > SQL Logic error or missing database near "SELECT": syntax error > >SELECT CONVERT(Int,SCOPE_IDENTITY()) AS [value] This involves two things which are not built into SQLite: CONVERT() SCOPE_IDENTITY() Assuming that they're provided by

[sqlite] Possible bug

Hello, I am a member of this list, but I am not sure which email address you have. I have tried the ones that I usually use, but my messages are getting held due to not recognizing my address. I am having a problem doing a Linq Insert using SQLite in Visual Studio 2015 (Community version) in

[sqlite] Possible bug in the SQL parser

On 2016/02/29 12:49 PM, Jo?o Ramos wrote: > Maybe this has been fixed then? This is what I'm getting: > > select sqlite_version(); -- 3.8.10 > > select sqlite_source_id(); -- 2015-05-04 19:13:25 > 850c11866686a7b39d7b163fb60898c11283688e > > > WITH > > tA(id, name) AS > > ( > > SELECT 1, "a"

[sqlite] Possible bug in the SQL parser

Maybe this has been fixed then? This is what I'm getting: select sqlite_version(); -- 3.8.10 select sqlite_source_id(); -- 2015-05-04 19:13:25 850c11866686a7b39d7b163fb60898c11283688e WITH tA(id, name) AS ( SELECT 1, "a" UNION ALL SELECT 2, "b" ), tB(name) AS ( SELECT "a" UNION ALL

[sqlite] Possible bug in the SQL parser

On 2/29/16, Jo?o Ramos wrote: > Maybe this has been fixed then? This is what I'm getting: > > select sqlite_version(); -- 3.8.10 > > select sqlite_source_id(); -- 2015-05-04 19:13:25 > 850c11866686a7b39d7b163fb60898c11283688e Compiling with that exact same version of the source code, it works

[sqlite] Possible bug in the SQL parser

On 02/27/2016 12:49 AM, Jo?o Ramos wrote: > I'm using SQLite 3.8.10.2 and the following query illustrates the problem: > > WITH > tA(id, name) AS > ( > SELECT 1, "a" UNION ALL SELECT 2, "b" > ), > tB(name) AS > ( > SELECT "a" UNION ALL SELECT "b" > ) > SELECT tB.id FROM tA INNER JOIN tB

[sqlite] Possible bug in the SQL parser

I'm using SQLite 3.8.10.2 and the following query illustrates the problem: WITH tA(id, name) AS ( SELECT 1, "a" UNION ALL SELECT 2, "b" ), tB(name) AS ( SELECT "a" UNION ALL SELECT "b" ) SELECT tB.id FROM tA INNER JOIN tB ON (tA.name = tB.name); There is no _id_ column in the tB table,

[sqlite] Possible bug?

SQLite version 3.9.2 2015-11-02 18:31:45 sqlite> .header on sqlite> select 0x1zzz; zzz 1 sqlite>

[sqlite] Possible bug?

On 11/13/15, Quan Yong Zhai wrote: > SQLite version 3.9.2 2015-11-02 18:31:45 > sqlite> .header on > sqlite> select 0x1zzz; > zzz > 1 > sqlite> This is parsed as: SELECT 0x1 AS zzz; PostgreSQL the same thing (modulo the fact that postgres 7.3 does not support hexadecimal integer literals).

[sqlite] Possible bug

On 11 Nov 2015, at 10:38pm, Adams, Justin wrote: > VARCHAR(20) Not a solution to the problem or a diagnosis of the bug, it's worth saying that SQLite has no VARCHAR type. Columns where you specify VARCHAR will be understood as TEXT, and truncation will never occur. Simon.

[sqlite] Possible bug

On 11/11/15, Adams, Justin wrote: > > I was trying to create a table with a column for IPv4 addresses as VARCHAR. > It seems when I set the .mode to column that some records are truncated on > the right. Changing the .mode fixes the problem, so I would think it has to > do with the column width

[sqlite] Possible bug

Hello, I searched the bug tracker and the only thing I saw that looked relevant was ticket UUID 6c266900a22574d4d6474503da5bfe849c8b244f. http://www.sqlite.org/src/tktview?name=6c266900a2 However, that seems to deal with special Unicode characters and I'm not dealing with that here. I'm using

[sqlite] Possible bug in shell .open command?

The aftermath... dir *. /x /b h8 08 @_8 0o8 hN Q N xa8 b8 0f8 10 soubor?, 14,336 bajt?

[sqlite] Possible bug in shell .open command?

I took that the .open command could be issued as ".open" to open a new in-memory database and ".open ''" (followed by a pair of single quotes) to open a new unnamed temporary file database. I wonder what is going on here: After issuing a short combination of these commands with/without putting

[sqlite] Possible bug in shell .open command?

Should be fixed now on trunk. On 6/17/15, Jean Chevalier wrote: > I took that the .open command could be issued as ".open" to open a new > in-memory database and ".open ''" (followed by a pair of single quotes) > to open a new unnamed temporary file database. > > I wonder what is going on here:

[sqlite] Possible Bug

On 31 May 2015, at 2:22am, Alan Bryan wrote: > SELECT *, Sum(MyField) AS MySumField FROM MyTable > > Now run sqlite3 and type the following: > > PRAGMA table_info(MyView); > > You will notice there is no data type for some reason. I think you get datatypes only for exact copies of a source

[sqlite] Possible Bug

:22 > To: sqlite-users at mailinglists.sqlite.org > Subject: [sqlite] Possible Bug > > I am running into an issue with SQLite that I think might be a bug. When I > run the PRAGMA table_info > <http://t.signauxcinq.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XZsRz > DgTW5vwkZs8pTgPFVRbxS056dNRV

  1   2   3   >