Re: [sqlite] Human readable SQL from prepared statement

2010-12-05 Thread BareFeetWare
On 04/12/2010, at 3:34 PM, Jay A. Kreibich wrote: > You can register a trace callback with sqlite3_trace(). The second > parameter of the callback will have the SQL statement, complete > with expanded parameters. > > You can't get this information at an arbitrary time, however, only > when

Re: [sqlite] setting autoincrement value on table with two primarykeys

2010-12-05 Thread Igor Tandetnik
Kees Nuyt wrote: > If you need a compound index for performance reasons, you can use > the autoincrement key as the primary key for the table and define a > unique index on the compound key. I can't think of any statement that would run faster if you, in addition to an existing unique index on A

Re: [sqlite] setting autoincrement value on table with two primary keys

2010-12-05 Thread Christophe Danker
Hi, * Kees Nuyt [2010-12-05 22:09:08 +0100]: > If you need a compound index for performance reasons, you can use > the autoincrement key as the primary key for the table and define a > unique index on the compound key. Is doesn't serve as a constraint > though, because the primary key constraint

Re: [sqlite] setting autoincrement value on table with two primary keys

2010-12-05 Thread Kees Nuyt
On Sun, 5 Dec 2010 20:53:43 +0100, Christophe Danker wrote: > thanks for answering. Well, without wanting to open up a general discussion > on the merits or not of having compound primary keys with one auto-increment > value, i had other technical constraints in mind relating to perl's > Catalyst

Re: [sqlite] setting autoincrement value on table with two primary keys

2010-12-05 Thread Christophe Danker
Hello Igor, * Igor Tandetnik [2010-12-05 11:53:17 -0500]: > If you want ID to be auto-incremented, then it will always be unique on its > own. Why then do you want a compound primary key? Just declare > > ID integer primary key thanks for answering. Well, without wanting to open up a general

Re: [sqlite] SQLite Documentation

2010-12-05 Thread Dagdamor
Artur Reilin писал(а) в своём письме Sun, 05 Dec 2010 22:35:01 +0600: > Thanks for this. I use many documentations that way. > > A suggestion: Making the index a little but clearer. Then I type "create > index" it doesn't found it. > > >> Hello. >> >> Would you like to have a downloadable versi

Re: [sqlite] setting autoincrement value on table with two primary keys

2010-12-05 Thread Igor Tandetnik
Christophe Danker wrote: > sqlite> create table test("ID" INTEGER NOT NULL, "a" VARCHAR(100), "b" > VARCHAR(100), PRIMARY KEY("ID","b")); > > Also: couldn't that bug be resolved for multi-column primary key situations > if only one column is of type "INTEGER" (vs "VARCHAR" or even "INT")? If yo

[sqlite] setting autoincrement value on table with two primary keys

2010-12-05 Thread Christophe Danker
Hi all, I did look at archives and found one way to do this: bash:~$ sqlite3 test.db SQLite version 3.2.8 Enter ".help" for instructions sqlite> create table test("ID" INTEGER NOT NULL, "a" VARCHAR(100), "b" VARCHAR(100), PRIMARY KEY("ID","b")); sqlite> insert into test ("a","b") VALUES ('foo',

Re: [sqlite] SQLite Documentation

2010-12-05 Thread Artur Reilin
Thanks for this. I use many documentations that way. A suggestion: Making the index a little but clearer. Then I type "create index" it doesn't found it. > Hello. > > Would you like to have a downloadable version of the SQLite Documentation? > I've created one in Windows HTML Help (.chm) format.

Re: [sqlite] Possible bug: wrong query result when using an index

2010-12-05 Thread Gerry Snyder
On Sun, Dec 5, 2010 at 7:25 AM, Gavrie Philipson wrote: > Hi, > > > The query is as follows: > > SELECT entry_type AS entry_type_int, entry_types.name as > entry_type_name, entry_id > FROM timeline JOIN entry_types ON entry_type_int = entry_types.id > WHERE > (entry_type_name = 'cli_command'

[sqlite] Possible bug: wrong query result when using an index

2010-12-05 Thread Gavrie Philipson
Hi, I'd like to report a possible bug in SQLite that causes a query to give wrong results when an index exists on one of the columns. Without the index the results are correct. I have honed down the data to the smallest possible set that still shows the bad behavior. The behavior was observed wit