Question

I’m using a compiled SQLiteStatement with transactions in optimizing SQLite transactions but I’m reading the documentation for the execute function:

Execute this SQL statement, if it is not a SELECT / INSERT / DELETE / UPDATE, for example CREATE / DROP table, view, trigger, index etc.

This seems to imply that this function should not be used with SELECT / INSERT / DELETE / UPDATE statements, but I have code that uses it with an insert and works.

I’m aware of executeInsert and the other methods, but executeUpdateDelete is not available in my API level, so can I use execute?

Also if I don’t need the last insert id or the number of rows affected should I use execute instead of executeInsert and etc., in other words is it more efficient?

Answer 1

execute is probably not faster than executeInsert, could even be slower (on ICS execute calls executeUpdateDelete and discards the return value). You need to test that but I doubt you will find a real difference here.

AFAIK, It is safe to use just execute if you don’t need return values but I would not count on that holding true in future Android versions. The documentation says no, so maybe someone is going to change the behavior to reflect that. Older implementations seem to use execute too (e.g. 2.1 delete() sourcecode). Jelly Bean for example changed a lot behind the scenes of SQLite, but it should still work when using execute

Besides, if you don’t use the same SQLiteStatement over and over again while just rebinding the args it’s probably not worth using it. Building a new one each time you call the regular insert, update, … methods is fast compared to the actual database access and the required disk I/O. Transactions on the other hand help a lot, since synchronizing database state on the disk for each statement is really slow.