--- [EMAIL PROTECTED] wrote:
> Your approach only works in simple cases. The number of changes is a
> connection/sqlite3* wide number - ie any SQLite statements associated with it
> can cause changes. This would certainly be the case when multi-threading is
> used.
Yes, agreed
> Even in single threading, if you have two statements running at the same time
> (eg you are reading rows from one to feed to the other or something something
> similar) then the completion order will affect that changes counter.
This case seems alright, consider the following scheme where a query overlaps
two update statements.
sqlite3 old real
CURSOR OPERATION total_changes total_changes changes
1 execute query
1 fetch row 1
2 execute update 1 0 1
1 fetch row 2
2 execute update 2 1 1
1 end of iteration 2 2 0
The real changes are reflected correctly.
> By far a better approach would be to enter a ticket requesting that the
> sqlite3_stmt_status api include row change counters. That way the numbers
> will be completely unambiguous and unaffected by other statements that are
> executing.
http://www.sqlite.org/cvstrac/tktview?tn=3534
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
