On Tue, 31 Jul 2018 18:00:31 +0200, Richard Hipp wrote:
On 7/31/18, Yngve N. Pettersen wrote:
I sent the email quoted below to the list, but
unfortunately, as far as I can tell, I have so far received no response.
I think that means that nobody has an answer. I don't have any idea
why
Hello SQLite Users, fyi ...
25th Annual Tcl/Tk Conference (Tcl'2018)
http://www.tcl.tk/community/tcl2018/
October 15 - 19, 2018
Crowne Plaza Houston River Oaks
2712 Southwest Freeway, 77098
Houston, Texas, USA
Important Dates:
[[ Attention!
Counting down we are now bit a shy of 4 weeks to
> You may be building on a system where they’ve still got SQLite 3.7.mumble
> installed
In this case there are not two implementations present. Both libsqlite3.24.0.so
and libsqlite3.so.0.8.6 were built from sqlite-autoconf-324. This is the
only copy of libsqlite3 anywhere on the system.
David,
We've been through that level of detail. Thats how we found that after
an Analyse that a new automatic covering index was being created for a
query that was not needed before the Analyse. That puzzled us and still
does.
Rob
On 31 Jul 2018, at 16:58, David Raymond wrote:
Take a look
On 7/31/18, Yngve N. Pettersen wrote:
> I sent the email quoted below to the list, but
> unfortunately, as far as I can tell, I have so far received no response.
>
I think that means that nobody has an answer. I don't have any idea
why your system would work well on Win10 but not on Win7.
Take a look at the queries being run and do an "explain query plan" for each
and look at the output to see what it decides to use. Look for "SCAN TABLE"
cases that might benefit, or other oddities where it's doing anything you're
not expecting.
-Original Message-
From: sqlite-users
On 31 Jul 2018, at 4:42pm, Rob Willett wrote:
> We have not checked that the order of columns in the index match the ORDER BY
> clauses. We never thought of that either,
That is going to make a big difference. Well done Gunter. Rob: don't forget
that once you have your indexes defined and
Gunter,
Thanks for this. We have already started on this as we realised that the
COLLATE NOCASE was irrelevant and actually slowed down integer queries.
What we have not done is reorder the table to match the index queries.
This had not occurred to us.
We think we have already created the
Simon,
Absolutely no need to apologise. We should apologise for all the time we
have taken from other people :(
We recognise that the collate no case is inappropriate for our database.
We suspect this was added from a SQLite tool we used some time ago. We
are going to use this opportunity
Chris,
I'll try and summarise.
1. We have a 60GB database collecting data. This database is accessed by
a single process once every five mins and around 5MB of data (approx
600-800 rows) is added. Data has never been deleted.
2. The database is getting too big for the server it's hosted on.
Hello all,
About four weeks ago, I sent the email quoted below to the list, but
unfortunately, as far as I can tell, I have so far received no response.
TL;DR: Concurrent attempts to exclusively lock the database tend to fail
on Windows 7 Pro, there is no similar problem on Windows 10.
Based on the currently available information I woudl suggest the following
schema:
CREATE TABLE IF NOT EXISTS "Disruptions" (
"id" INTEGER PRIMARY KEY NOT NULL AUTOINCREMENT,
"version" integer NOT NULL,
"Disruption_id" INTEGER NOT NULL,
"status" integer NOT
On 31 Jul 2018, at 2:59pm, Rob Willett wrote:
> We've created a new table based on your ideas, moved the collate into the
> table, analysed the database. We did **not** add COLLATE NOCASE to the
> columns which are defined as integers. Would that make a difference?
What you did is correct. I
I've been following this thread with interest, but this just doesn't make
sense...
> Logically speaking SQLite shouldn't notice the difference in row order,
but things do slow down,
> even with analyse.
Are you accessing each row via its ID? Even so, that should still be
indexed.
I thought you
Dear all,
We think we have now found the issue with the slow commits.
We believe this is due to an inherent (and old) defect in our database
design. We think our original design has an implicit ordering of rows in
a table, when the table is only increasing this flaw in the design isn't
Simon,
As an exercise we have just added in COLLATE NOCASE to our integer
columns.
Whoops! We thought this would make no difference but its added extra 70%
to our processing speeds.
We've now got to the stage where we can make changes quickly, so we'll
back that change out and go back to
Simon,
Apologies for taking so long to get back, we've been building a test
system and its taken a long time.
We're just getting round to trying your ideas out to see what difference
they make,
We've created a new table based on your ideas, moved the collate into
the table, analysed the
On 31-7-2018 10:52, Luuk wrote:
> From: http://www.sqlitetutorial.net/sqlite-full-text-search/
> For example, to get the documents that match the |learn| phrase but
> doesn’t match the |FTS5| phrase, you use the |NOT| operator as follows:
>
> LECT *
+SE
> FROM posts
> WHERE posts MATCH 'learn
On 07/31/2018 12:25 PM, paul tracy wrote:
Forgive me if this is the wrong way to do this but I'm a newbie.
I am using version 3.24.0 with FTS5
Is there a way to perform a full text search that returns every row except
records matching a specified query string?
The following does not work
If you want anything except "cat" then you can use the less than and
greater than comparison - <> .
select * from table where field <> 'cat'
This equates to "select all records where the value in the field column is
less than and is greater than 'cat'. SQL allows you to search for less
than and
On 31-7-2018 10:52, Luuk wrote:
> On 31-7-2018 07:25, paul tracy wrote:
>> Forgive me if this is the wrong way to do this but I'm a newbie.
>> I am using version 3.24.0 with FTS5
>> Is there a way to perform a full text search that returns every row except
>> records matching a specified query
On 31-7-2018 07:25, paul tracy wrote:
> Forgive me if this is the wrong way to do this but I'm a newbie.
> I am using version 3.24.0 with FTS5
> Is there a way to perform a full text search that returns every row except
> records matching a specified query string?
> The following does not work
I thought this was that index index,sqlite_autoindex_
option4_name_1,option4_name,3,
but maybe that's the unique on name.
I see; I guess it is missing; indexes get created now more properly. I
deleted it and recreated it, which created the indexes more properly.
thanx, and sorry for the noise.
> Maybe you're writing for a fixed-space embedded device, which nonetheless
> has space for the gigabytes required
Actually I am at the other end of the spectrum and running out of SSD space
on the server-side,
with the higher SSD storage tiers being quite more expensive.
I am also leaving the
J Decker wrote:
> CREATE TABLE `option4_name` (`name_id` char(36) NOT NULL,`name`
> varchar(255) NOT NULL default '' CONSTRAINT `name` UNIQUE)
> FOREIGN KEY (`name_id`) REFERENCES `option4_name`(`name_id`)
> foreign key mismatch - "option4_map" referencing "option4_name"
name_id must be the
Markos wrote:
> CREATE TABLE user (
> id_user integer PRIMARY KEY,
> ...
> CREATE TABLE loan (
> ...
> FOREIGN KEY(id_admin_loan, id_admin_devolution) REFERENCES user(id_user,
> id_user)
I do not understand what this is trying to accomplish.
Why not two single-column FK
26 matches
Mail list logo
