: [sqlite] Behavior change: INTEGER PRIMARY KEY and PRAGMA index_list
Paul Quinn wrote:
> In 3.7, issuing "PRAGMA index_list(tablename)" to retrieve the details
> of an index, sqlite3_column_count() would return 0 for automatic
> integer primary key indexes, b
"" (empty string).
Is this behavior change by design?
We are working around it by checking for the "" (empty string) named index. Is
there a better way to identify this index returned by the Pragma is the
automatically create one?
Thanks
-Paul Quinn
It appears that the long-running task of 'PRAGMA integrity_check' does not
respond to being cancelled during operation. We've experimented with
"sqlite3_interrupt" and "sqlite3_progress_handler" both which say they can
interrupt long running tasks. Looking at SQLite's implementation it appears
Very simple to replicate:
CREATE VIRTUAL TABLE fts_table USING fts2(text);
INSERT OR REPLACE INTO fts_table (rowid, text) VALUES (1, 'text1');
INSERT OR REAPLCE INTO fts_table (rowid, text) VALUES (1, 'text2');
The first insert succeeds, the second fails.
Is FTS not supposed to
! Seeking a passionate developer to join our team building
products. Position is in the Washington D.C. metro area. If interested
contact [EMAIL PROTECTED]
-Original Message-
From: Paul Quinn [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 07, 2007 11:54 AM
To: sqlite-users@sqlite.org
Subject: Re:
Quite simply, both the FTS1 and FTS2 modules return an error on INSERT OR
REPLACE when there is a conflict. The rowid is being supplied with the
INSERT statement which is generating the conflict.
Is this by design, a known issue, or a defect?
I'm also having trouble with FTS inserts/deletes
I did set up a trigger for DELETEs, but even then the fts_table would find a
way to have more rows than master after a short while. Some delete's are
simply being ignored/failed by the FTS module it seems.
I would have liked to also use triggers for INSERTs, but how do you create a
trigger
7 matches
Mail list logo
