Please don't try to go there. Relying on the implicit visitation order is a
frequent cause of code breaking when the query planner changes the plan (eg .in
a new SQLite release or if the "shape" of your data changes and ANALYZE is run).
If your application depends on the rows being returned in
On 5/1/19, Tom Bassel wrote:
> Hi,
>
> In this page in the docs: https://sqlite.org/queryplanner.html#searching
>
> it says:
> "The rows are logically stored in order of increasing rowid"
>
> Would this imply that executing a SELECT would always return the rows in
> order or increasing rowid?
>
>
On Wednesday, 1 May, 2019 15:56, Tom Bassel wrote:
>In this page in the docs:
>https://sqlite.org/queryplanner.html#searching
>it says:
>"The rows are logically stored in order of increasing rowid"
>Would this imply that executing a SELECT would always return the rows
>in order or increasing
Sorry for the recent spam messages that got through. I accidentally
pressed the "Accept" button rather than the "Discard" button.
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
Hello ,
We got your email contact from a web business journal and we have no intention
of wasting your time.
We give out loans to individuals and companies. The interest rate will be 3%
annually. We have investors who are interested in financing projects of large
volume and we give out loan
Hi,
We use SQLite extensively here at Zaber and are quite pleased with it.
However, we recently added a view that incorrectly returns incorrect/NULL
data. It appears to be cause by CTE names leaking outside of the view and
being confused with another CTE with the same name but only if both CTEs
Hi,
In this page in the docs: https://sqlite.org/queryplanner.html#searching
it says:
"The rows are logically stored in order of increasing rowid"
Would this imply that executing a SELECT would always return the rows in order
or increasing rowid?
So that a "SELECT * from MyTable" would return
Again, I think this is a problem with applying affinity when the index is
created. The result of applying real affinity to the string '+/' should
probably be the string '+/' not the real value 0. On the gripping hand, '+/'
looks like a number with "crud" at the end of the string. I believe
On May 1, 2019, at 3:31 PM, Manuel Rigger wrote:
>
> CREATE TABLE test (c0 REAL);
> CREATE INDEX index_0 ON test(c0 COLLATE NOCASE);
> INSERT INTO test(c0) VALUES ('+/');
> SELECT * FROM test WHERE (c0 LIKE '+/‘);
That behavior *does* reproduce here.
Making the final query’s predicate “c0 =
I'm very sorry, after finding the issue using the latest stable Linux
version, I accidentally used an outdated version (3.24.0) to produce a
minimal failing case. Here is a reduced example that triggers the bug on
the latest stable [1] and snapshot [2] versions:
CREATE TABLE test (c0 REAL);
On May 1, 2019, at 1:18 PM, Richard Hipp wrote:
>
> I am unable to reproduce the observed behavior.
Nor I, on 3.28.0 release with our custom build.
Thank you for providing a simple test case, Manuel: it helps greatly!
> What version of
> SQLite are you testing with? Are you compiling it
On 5/1/19, Manuel Rigger wrote:
>
> CREATE TABLE test (c0 REAL);
> CREATE INDEX index_0 ON test(c0 COLLATE NOCASE);
> INSERT INTO test(c0) VALUES ('/');
> SELECT * FROM test WHERE (c0 LIKE '/');
>
> Unexpectedly, the SELECT statement does not return a result.
I am unable to reproduce the
Hi everyone,
Consider the example below:
CREATE TABLE test (c0 REAL);
CREATE INDEX index_0 ON test(c0 COLLATE NOCASE);
INSERT INTO test(c0) VALUES ('/');
SELECT * FROM test WHERE (c0 LIKE '/');
Unexpectedly, the SELECT statement does not return a result. If the
statement for the creation of the
Hi,
We have a large C# application which uses the System.Data.SQLite.Core NuGet
package. We have been running with version 1.0.107.0 since it was released
without any issues. Last week we updated to version 1.0.110.0, and now we are
seeing occasional odd errors appearing (fortunately we are
Addressed by https://www.sqlite.org/src/info/713caa382cf7ddef
On 5/1/19, Manuel Rigger wrote:
> Hi everyone,
>
> I think that I found a bug that occurs when setting legacy_file_format to
> true and calling REINDEX, which then results in "Error: UNIQUE constraint
> failed: index 'index_0'" in the
See ticket https://www.sqlite.org/src/info/a340eef47b0cad59
On 4/28/19, Manuel Rigger wrote:
> Hi everyone,
>
> It seems that setting "PRAGMA case_sensitive_like" to either false (the
> default behavior) or true results in no longer being able to use a LIKE or
> GLOB clause when creating an
I looked into the JDBC driver source code and found the following two code
lines mentioned in the stack trace.
Sqlline is trying to get the tablename of the resultSet which results in
the invocation of:
Hi everyone,
I think that I found a bug that occurs when setting legacy_file_format to
true and calling REINDEX, which then results in "Error: UNIQUE constraint
failed: index 'index_0'" in the specific example below:
CREATE TABLE test (c0, c1 TEXT);
CREATE UNIQUE INDEX IF NOT EXISTS index_0 ON
18 matches
Mail list logo
