OK, now I see the problem, but sqlite3_total_changes() will not help here too - it behaves the same way as sqlite3_changes(), it doesn't accumulate changes over several statements. So without introducing some difference between SELECT queries and any data-changing queries in your program you won't be able to distinguish them using SQLite API. Maybe PRAGMA count_changes can be of any help (http://www.sqlite.org/pragma.html#pragma_count_changes) but I really doubt about it.
Actually I believe it's pretty easy to distinguish it by simple looking into query text. SELECT statements always begin with the word "SELECT". Statements changing something in the database begin with words "INSERT", "REPLACE", "UPDATE" or "DELETE". Pavel On Tue, Mar 2, 2010 at 7:45 AM, Max Vlasov <[email protected]> wrote: > On Mon, Mar 1, 2010 at 6:31 PM, Pavel Ivanov <[email protected]> wrote: > >> sqlite3_changes() is exactly what you should use in this case. And I >> didn't understand why did you find it unsuitable for you? >> >> Pavel >> > > > I think I understand his confusion. Imagine if for some reason you don't > know whether last query is amongst INSERT, UPDATE, or DELETE (for example it > could be SELECT). But he probably wants that some call or fragment of code > return number of changes or 0 for any recent operation including SELECT. If > he just relies on sqlite3_changes() after INSERT with two rows affected and > simple SELECT afterward, this call will still return 2. In this case I'd > recommend using difference between consequitive sqlite3_total_changes() > values. For any read-only query this difference will always be zero. > > Max > _______________________________________________ > 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
