Hi,
last time I have posted this bug(?) using an C-API. Here is the same
bug(?) using only SQL statements:
CREATE TABLE Simple (ID integer primary key, Name text);
CREATE VIRTUAL TABLE SimpleFTS USING FTS3 (Name);
CREATE TRIGGER DeleteTrigger AFTER DELETE ON Simple FOR EACH ROW BEGIN
DELETE FROM SimpleFTS WHERE (rowid=OLD.ID); END;
CREATE TRIGGER InsertTrigger AFTER INSERT ON Simple FOR EACH ROW BEGIN
INSERT INTO SimpleFTS (rowid,Name) VALUES(NEW.ID,NEW.Name); END;
INSERT INTO Simple (Name) VALUES('one');
INSERT INTO Simple (Name) VALUES('two');
DELETE FROM Simple WHERE (ID = 1);
INSERT INTO Simple (Name) VALUES('three');
SELECT * FROM Simple;
SELECT last_insert_rowid() FROM Simple;
The output is:
2|two
3|three
4|four
5 <-- BUG?!
5
5
The largest and last row id is 4. Why is SQLite returning 5? I think
it has to do with the FTS3 module but still the trigger statement
should shield the row ids from the trigger statement, or?
Hartwig
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
