On 2014/09/20 23:08, Richard Hipp wrote:
On Sat, Sep 20, 2014 at 12:45 PM, Merike wrote:
A question: is the query being fast again after analyze call indicative
of the bug being fixed? Because I tried it on my original database too
and there I don't see a speedup after
On 2014/09/21 14:12, RSmith wrote:
On 2014/09/20 23:08, Richard Hipp wrote:
On Sat, Sep 20, 2014 at 12:45 PM, Merike wrote:
A question: is the query being fast again after analyze call indicative
of the bug being fixed? Because I tried it on my original database too
and
On 2014/09/20 23:23, Simon Slavin wrote:
...calls themself Tarquin
Fin-tim-lin-bin-whin-bim-lim-bus-stop-F'tang-F'tang-Olé-Biscuitbarrel
Oh you know him? We go way back... old Tim Biscuits we used to call him. It was fun watching the undertakers figure out how to get
all that on his
I find it something of a shortcoming that the doc pages (
http://www.sqlite.org/lang_with.html) do not mention the applicable version
of sqlite.
Example: I read about the 'with clause'. Exciting! But when trying it, it
didn't work because I am using an older version. Not that old but still old
On Sun, Sep 21, 2014 at 2:46 PM, HarryD wrote:
> I find it something of a shortcoming that the doc pages (
> http://www.sqlite.org/lang_with.html) do not mention the applicable
> version
> of sqlite.
>
> Example: I read about the 'with clause'. Exciting! But when trying it,
On Sun, Sep 21, 2014 at 2:53 PM, Stephan Beal wrote:
> fossil has its own built-in copy of sqlite. It sounds like you're using
> one which was built with the --internal-sqlite=0 flag.
>
My UTMOST apologies - i'm confusing traffic from two lists here (and
thought yours was
http://www.sqlite.org/changes.html
2014-02-03 (3.8.3)
•Added support for common table expressions and the WITH clause.
--
--
--
--Ô¿Ô--
K e V i N
On Sun, Sep 21, 2014 at 8:46 AM, HarryD wrote:
> I find it something of a shortcoming that the doc
On Sat, 20 Sep 2014 20:21:29 +0100
Simon Slavin wrote:
> > Your suggestion essentially amounts to "names are not
> > decomposable, so keep one version for the user and one for the
> > system."
>
> Sorry, I don't think I got that across effectively. If I make up a
>
On 21 Sep 2014 at 16:18, James K. Lowden wrote:
> Really? HM Revenue and Customs doesn't require you to distinguish
> between your given and family names once a year?
Search me. As long as I get my tax adviser to file my tax return once a year,
and send them dosh
On 2014/09/21 17:18, James K. Lowden wrote:
...to get web payment forms to allow, for the love of God, spaces in credit
card numbers. --jkl
Now there's a worthy cause. Ditto for phone numbers (though they mostly are more lenient today). Also to allow hashes and dashes in
the address field.
21.09.2014 15:12, RSmith kirjutas:
> Merike: Running Analyze did not fix the bug, it simply changed some
> internal-use values that allowed the bug to be circumvented. If you
> re-make a table as you had without running analyze, the problem will
> surely remain using the same codebase. Updating
21.09.2014 00:08, Richard Hipp kirjutas:
> On Sat, Sep 20, 2014 at 12:45 PM, Merike wrote:
>
>> 19.09.2014 04:21, Richard Hipp kirjutas:
>>> A simple script to reproduce the problem in the latest SQLite is as
>>> follows: CREATE TABLE t1(a INTEGER PRIMARY KEY, b INTEGER, c
On 2014/09/21 15:39, Merike wrote:
Now I could very well be wrong about that as you say in your other reply that "It might simply be that Analyze did not get your QP
to react on that size DB as it did for us". You seem to be saying that analyze behaves differently depending on database size...
Hi,
Can you please tell me where is the definition of the struct sqlite3_stmt ?
A search in sqlite3.c yields on the typedef statement of the struct ,
typedef struct sqlite3_stmt sqlite3_stmt;
Thanks for your help.
___
sqlite-users mailing list
14 matches
Mail list logo