On Wed, 2007-05-16 at 11:39 +0530, B V, Phanisekhar wrote:
> Igor,
>
> Assume I have a database of the files/folders.
>
> Let it be
>
> Rowid puid
> 1 1
> 2 2
> 3 3
> 4 5
> 5 7
> 6 8
> 7 10
>
> Assume I have a relation table showing which file is in which folder
>
>
Kennedy,
You are using Join that's going to take time. I need the most
efficient query.
Regards,
Phanisekhar
-Original Message-
From: Dan Kennedy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 16, 2007 12:54 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Re: Re: Order of result
Let the database be:
Create table if not exists maintable (rowid INTEGER PRIMARY KEY, puid
INTEGER)
Create Unique Index if not exists puididx on maintable (puid)
Assume a query
"select rowid from maintable where puid = X OR puid = Y or puid = Z"
How will this query work internally?
1 Will it f
B V, Phanisekhar <[EMAIL PROTECTED]> wrote:
Now assume the entries are added to this relation ship table in the
sequence in which the files are created inside the folder along with
the
sequence by which they were moved inside the folder. So the above
table
says file 10 was first added to the sequ
B V, Phanisekhar <[EMAIL PROTECTED]> wrote:
You are using Join that's going to take time.
And how do you think an IN operator is implemented - black magic? Every
time you have more than one table involved in a query, you perform a
join.
Igor Tandetnik
> What I would propose is to be more robust in handling such incorrect Unicode
> strings, so that application can e.g. insert really any string, not only
> those that comply Unicode standards.
>
Doing this can potentially lead to security exploits in programs
that use SQLite. If you want to hand
B V, Phanisekhar wrote:
Kennedy,
You are using Join that's going to take time. I need the most
efficient query.
Dan's one of the SQLite developers, so presumably has a rough idea of
what his suggested query will be doing... ;)
Martin
--
* Jiri Hajek <[EMAIL PROTECTED]> [2007-05-16 14:40]:
> As for security exploits, I don't see any, Unicode 4.0 standard
> allows applications to ignore such incorrect characters.
The Unicode standard is beside the point. There is lots of code
that does not handle charsets and encodings correctly, w
Hello,
I am using LIKE to make a simple query for filename '%path%' and it works
well as long as I am only using ANSI characters, LIKE thinks 'a' and 'A' are
the same. When coming up on Greek characters (i.e.) it doesn't work that
well anymore. Suddenly LIKE is case-sensitive (since LIKE use some
I would like to use the "ICU" extention (cvs: "sqlite\ext\icu.c") in
combination with a preprocessed source code of SQLite3 for Win32.
Is it possible to build sqlite.dll with the big sqlite3.c plus
extentions (e.g. icu.c) ?
Afaik, FTS2 and FTS1 are not included in the amalgamation file as
well.
Hello,
I have no inside-knowledge from SQLite, but I'am in the circumstance
to easily do this experiment. Hope I understand it right and that you
consider a sort of pipe-lining. Anyway, I started the two threads A
and B, and made A exclusively do all the sqlite3_prepare calls, and B
the r
This updated patch greatly improves query times against compound
SELECT statements (i.e., UNIONs) when the parent SELECT has a WHERE
clause.
For example, this query:
SELECT * FROM (
SELECT a,b FROM t1
UNION ALL
SELECT x,y FROM t2
) WHERE a>b;
will be transformed into the more spe
I have recently encountered the same cross-thread library misuse bug, and
ended up re-implement a C++ wrapper to be thread-aware and thread-safe.
It's not yet feature complete, compared to CPPSQLite3DB, but it does have
several good enhancements:
* signed 64-bit integer parameter binding support.
Jonas Sandman wrote:
> I am using LIKE to make a simple query for filename '%path%' and it
> works well as long as I am only using ANSI characters, LIKE thinks
> 'a' and 'A' are the same. When coming up on Greek characters (i.e.)
> it doesn't work that well anymore. Suddenly LIKE is case-sensitiv
"Klemens Friedl" <[EMAIL PROTECTED]> wrote:
> I would like to use the "ICU" extention (cvs: "sqlite\ext\icu.c") in
> combination with a preprocessed source code of SQLite3 for Win32.
>
> Is it possible to build sqlite.dll with the big sqlite3.c plus
> extentions (e.g. icu.c) ?
Sure. It's all C c
"Jonas Sandman" <[EMAIL PROTECTED]> wrote:
>
> I want LIKE to work just as well for non-ANSI characters, I think the
> solution is to override LIKE with sqlite3_create_function but is there any
> examples on how to use this function?
>
The built-in LIKE operator is created using the sqlite3_crea
16 matches
Mail list logo
