Hick Gunter wrote:
>create the primary key index ordered properly
>
>CREATE TABLE t (..., PRIMARY KEY ( a ASC, b DESC)...);
DESC is not necessary here; SQLite has no problem reading the index
in reverse order, if needed.
(DESC in an index is useful only when you want to optimize multiple
ORDER
On 12/29/2014 07:57 AM, Yongil Jang wrote:
For more information,
In pager_end_transaction() function,
int bDelete = (!pPager->tempFile &&
sqlite3JournalExists(pPager->jfd)); <-- sqlite3JournalExists() returns
0
I think both of pager_end_transaction() and sqlite3JournalExists()
functions work
Apache Camel: Source
| |
| | | | | |
| Apache Camel: SourceWarning Icon Apache Camel code repository was moved to
git, The old svn repo will not be updated. Web Browsing of git To browse via
the web: |
| |
| View on camel.apache.org | Preview by Yahoo |
| |
| |
Kind regards
On Mon, Dec 29, 2014 at 9:46 AM, Simon Slavin wrote:
>
> On 29 Dec 2014, at 1:09pm, Paul Menzel
> wrote:
>
> > using Debian Sid/unstable and upgrading from libsqlite3-0 3.8.7.2 to
> > 3.8.7.4, Evolution 3.12.9 started to crash with a bus
On 29 Dec 2014, at 1:09pm, Paul Menzel
wrote:
> using Debian Sid/unstable and upgrading from libsqlite3-0 3.8.7.2 to
> 3.8.7.4, Evolution 3.12.9 started to crash with a bus error [1].
Attachments don't work on this list. Please post long text on a web site
Dear Evolution and SQLite folks,
using Debian Sid/unstable and upgrading from libsqlite3-0 3.8.7.2 to
3.8.7.4, Evolution 3.12.9 started to crash with a bus error [1].
After downgrading to SQLite 3.8.7.1 from Debian Jessie/testing I was
unable to reproduce the issue.
Looking at the changelog
Hi,
here is a bug report as posted here: http://stackoverflow.com/q/27678468/684229
I got this query in sqlite
select kvadrat, datum, count(distinct kontrola) as pocet
from b
group by kvadrat, datum
having pocet > 1
The problem was that pocet was actually a column in table b and I didn't
create the primary key index ordered properly
CREATE TABLE t (..., PRIMARY KEY ( a ASC, b DESC)...);
SELECT b FROM t WHERE a = ? LIMIT 1;
If you insist on using a partial index for this (for example if each a has a
lot of b entries) you could add a field b_is_max and keep it current using
You should include both a and b in the index to be most helpful.
CREATE INDEX whatever ON t (a, b);
However, you say that (a, b) is already the primary key and therefore this
index already exists and you do not need to create another one.
Although the index will contain all rows, finding the
On 29/12/2014 4:33 PM, Baruch Burstein wrote:
Hi,
I have a table with a 2 column PK, say 'a' and 'b'. I need to find, for a
given value of 'a', the highest matching 'b'. The query itself it simple:
SELECT max(b) FROM t WHERE a=:whatever
To speed this up, I would add an index on 'a'. Now,
Hi,
I have a table with a 2 column PK, say 'a' and 'b'. I need to find, for a
given value of 'a', the highest matching 'b'. The query itself it simple:
SELECT max(b) FROM t WHERE a=:whatever
To speed this up, I would add an index on 'a'. Now, the question is is
there some way to tell the
11 matches
Mail list logo