On Mon, 29 Apr 2019 at 01:22, Lullaby Dayal
wrote:
>
> Considering all this, I have written a test application running on Linux
> with sqlite3 library in serialized mode. My test application has 200
> parallel threads in which 100 threads are executing SELECT * operation from
> a table and 100
On Thursday, 25 April, 2019 19:10, Lullaby Dayal
wrote:
>We use sqlite3 in an embedded automotive system based on QNX
>hypervisor running multiple virtual machines. Software is
>architectured in a service oriented way.
Interestingly, the default "database" service in QNX is (or at least was
On Sunday, 28 April, 2019 11:23, Lullaby Dayal asked:
To answer your specific questions:
>So my questions are:-
>1. In auto-commit mode in serialized threading mode, how command
>queueing works?
auto-commit and transactions are an attribute of the connection and have
nothing whatsoever to
On 28 Apr 2019, at 7:58pm, Manuel Rigger wrote:
> 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 index.
Correct. Because you cannot depend that every
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 index. For example, the example below results
in "Error: non-deterministic functions prohibited in index
I will leave aside the use of SHARED_CACHE which massively trades performance
for memory usage (that is, it "totally kills" performance but also "hugely
reduces" memory requirements) -- it trades a huge reduction in performance for
a huge reduction in memory usage and changes some other things
Great, thanks for opening the bug report and for the attribution!
Best,
Manuel
Am So., 28. Apr. 2019 um 17:07 Uhr schrieb Richard Hipp :
> On 4/28/19, Manuel Rigger wrote:
> >
> > CREATE TABLE test (c1 TEXT PRIMARY KEY) WITHOUT ROWID;
> > CREATE INDEX index_0 ON test(c1 COLLATE NOCASE);
> >
On 28 Apr 2019, at 6:22pm, Lullaby Dayal wrote:
> SQLite supports an unlimited number of simultaneous readers, but it will only
> allow one writer at any instant in time.
Please note that this is a statement about how one journal mode (WAL) works.
Are you telling us that you're using that
Thank you for your valuable suggestion.
As you mentioned, the possibility of a concurrent transaction with
auto-commit transaction is already handled in our design using some flag
variables.
I would like to understand some points discussed in sqlite3 documentation
in detail.
1. Compile time
On 4/28/19, Manuel Rigger wrote:
>
> CREATE TABLE test (c1 TEXT PRIMARY KEY) WITHOUT ROWID;
> CREATE INDEX index_0 ON test(c1 COLLATE NOCASE);
> INSERT INTO test(c1) VALUES ('A');
> INSERT INTO test(c1) VALUES ('a');
> SELECT * FROM test;
>
> Is this indeed a bug, or a misunderstanding on my
Hi everyone,
I found what could be a bug. Consider the example below:
CREATE TABLE test (c1 TEXT PRIMARY KEY) WITHOUT ROWID;
CREATE INDEX index_0 ON test(c1 COLLATE NOCASE);
INSERT INTO test(c1) VALUES ('A');
INSERT INTO test(c1) VALUES ('a');
SELECT * FROM test;
The query returns only one
@Simon: Thanks for pointing that out! The difference in the effects of
using single vs. double quotes in the select query is still the same though.
@Richard: Thanks for taking time to explain this to me and for pointing me
to the comment in the source code! I've found another case where,
Simon Slavin schrieb am Sa. 27. Apr. 2019 um 14:28:
> On 27 Apr 2019, at 10:47am, Frank Kemmer wrote:
>
> > I can connect to the database, create a table, select from the table,
> insert into the table, but the first time I try to read after an insert I
> get the following exception:
>
> >> Are
13 matches
Mail list logo
