Possibly my previous post was too short. Any way I have a satisfactory solution
now. My question araised when trying to change the apswtrace tool available to
Python users. This gathers execution times via a sqlite3_profile callback
function. When I call sqlite3_changes from this profiler function, and just
blindly display the results on the summary report, this looks like:
CALLS TIME ROWS SQL
1 .002 12 DELETE FROM t1
1 .002 12 SELECT * FROM t1
Which is wrong as the SELECT statement just repeats the number of rows of the
last DML (DELETE).
My solution is to use sqlite3_total_changes instead of sqlite3_changes, more or
less like this:
realchanges=sqlite3_total_changes()-old_total_changes
if realchanges>0:
old_total_changes+=realchanges
<add to report>
It appears satisfactory so far. Still wonder why a work-around like this is
needed.
Edzard Pasma
--- [EMAIL PROTECTED] wrote:
From: "Edzard Pasma" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Subject: [sqlite] reporting number of changes
Date: Tue, 9 Dec 2008 01:36:39 -0800
Hello,
The API function sqlite_changes reports the number of rows changed in the last
update/insert/delete. I'd like to use this in a generic SQL-tracing tool and
find it a bit inconvenient as the value can only be used if the statement was
an update/insert/delete. Is there a reason that the value is not reset for
other type of statements? Or is there an easy way to find if a statement was an
update?
Edzard Pasma
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
