In your example, the only way SQLite can do what you expect is to notice
that your UPDATE didn't modify any rows.
But you don't want an UPDATE statement throwing errors simply because it
didn't modify any rows. There are many situations where that happens
and is considered normal behavior.
UPDATE table1 SET site='Site1' WHERE site='garbage';
In your example, you know what garbage looks like. SQLite does not.
Mere absence of that value from the column does not qualify it as garbage.
OTOH, I do sometimes like to put this line (or something like it):
assert(1 == sqlite3_changes(db));
after an UPDATE when I know that it should have changed exactly one row.
--
E
On 2/22/13 3:15 PM, Frederick Wasti wrote:
[A "newbie to SQLite" here...]
>From the documentation on sqlite3_exec(), it seems as if it should return
SQLITE_OK (=0) upon processing a successful SQL query. However, I was a
bit surprised to see that an SQL statement such as "UPDATE table1 SET
site='Site1' WHERE site='garbage' (where garbage really is garbage, as in
not being present in the database) results in an SQLITE_OK return.
I guess there are two ways of looking at this: On the one hand, the SQL
statement cannot succeed, so the return should not be SQLITE_OK. On the
other hand, an SQL statement which would be impossible to process, but
which would nonetheless be handled with aplomb by sqlite3_exec(), should
return SQLITE_OK after all (in the sense that sqlite3_exec() did do its job
OK). (???)
So, my question is: Is it correct for sqlite3_exec() to return SQLITE_OK if
the SQL query is doomed to failure (but is otherwise properly formed)?
Thanks.
Fred
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
