>>
>>
>>> kdb "select * from kfz where CRC32=-1509747892;"
>>> 48482364|48|0|0C|00|00|0||20|5B93|-1509747892|||0|GP-T 1006|0
>>> 20209667|20|1|3C|00|32|202880||99|4FBD|-1509747892|||0|FL-AK 98|1
>>> 20209667|20|1|3C|00|32|202880||99|4FBD|-1509747892|||0|FL-AK 98|1
>>
>> What could cause 48482364 t
"Marian Aldenhoevel"
wrote in
message news:49a65fac.5060...@mba-software.de
> I am having a strange problem with a sqlite3 database. See the
> following transcript:
>
>> sqlite3 kdb "select * from kfz where kfznr=48482364;"
>> 48482364|48|0|0C|00|00|0||20|5B93|1746294314|||0|GP-T 1006|0
>
> kfznr
Hi,
>> > CREATE TABLE IF NOT EXISTS KFZ (
>
> Is that as reported by the command-line sqlite3 executable program, or
> is it from some script that you hope is the one that was used to create
> the table?
That is from the script I _know_ is the one that created the table. I
will send output f
On 26/02/2009 9:45 PM, John Machin wrote:
> On 26/02/2009 8:23 PM, Marian Aldenhoevel wrote:
>> Hi,
>>
>> I am having a strange problem with a sqlite3 database. See the following
>> transcript:
>>
>> > sqlite3 kdb "select * from kfz where kfznr=48482364;"
>> > 48482364|48|0|0C|00|00|0||20|5B93|1
On 26/02/2009 8:23 PM, Marian Aldenhoevel wrote:
> Hi,
>
> I am having a strange problem with a sqlite3 database. See the following
> transcript:
>
> > sqlite3 kdb "select * from kfz where kfznr=48482364;"
> > 48482364|48|0|0C|00|00|0||20|5B93|1746294314|||0|GP-T 1006|0
>
> kfznr is the prima
Hi,
I am having a strange problem with a sqlite3 database. See the following
transcript:
> sqlite3 kdb "select * from kfz where kfznr=48482364;"
> 48482364|48|0|0C|00|00|0||20|5B93|1746294314|||0|GP-T 1006|0
kfznr is the primary key, so this is to be expected. Now two queries as
fired from t
are/are not present, which I think is a good sign.
-Tom
> -Original Message-
> From: Ted Unangst [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 19, 2005 1:28 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Indexing problem
>
> Thomas Briggs wrote:
On Tue, 2005-04-19 at 10:27 -0700, Ted Unangst wrote:
> Two tables in a where can use two indices in sqlite?
>
Correct. SQLite (and every other SQL RDBMS that I know
of) uses as many as but no more than one index per table
in a join. If the same table is used more than once in
a join, then each
Thomas Briggs wrote:
I think the common misconception is that indexes on multiple
individual columns can be used in conjunction with one another, which
isn't the case (unless you're talking about bitmap indexes, but since
SQLite doesn't have those, we clearly aren't :P). Once you get
comfortabl
Thank you for spelling out that only one index can be
used per query - probably a basic principle for sqlite
experts, but one that had passed me by!
The following tuning guide mentions that "if there is
a choice of indexes, the query optimizer may make a
bad choice":
http://web.utk.edu/~jplyon/sq
> I was puzzled that removing the single-column index on
> Season actually enabled the original query to
> complete, having read somewhere in the sqlite docs
> that indexing columns used in WHERE conditions
> improves performance. Is this something to do with the
That's a true statement in ge
Season)
on the YM203 table
would make a huge difference in how this query will
perform, I think.
-Tom
> -Original Message-
> From: John Proudlove [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 10:26 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Indexing
; -Original Message-
> From: John Proudlove [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 10:26 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] Indexing problem
>
> Hello,
>
> Can anyone shed light on the following problem,
> experienced
Hello,
Can anyone shed light on the following problem,
experienced with the SQLite command line utility
(v3.0.8) on Solaris/SPARC?
The query below hangs (fails to complete within 5
minutes) using the indices shown, but after removing
the index on the Season column (used in the WHERE
condition), i
14 matches
Mail list logo
