-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edzard Pasma wrote: > It appears satisfactory so far. Still wonder why a work-around like this is > needed.
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. 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. 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://sqlite.org/c3ref/stmt_status.html Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklA+LEACgkQmOOfHg372QQK6ACeKw9kEyKEfba9UHn3eSPqyPy8 AbAAnA83TPMI6CUxpkzff9AJkz/dqDwF =zBrQ -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
