CODEWITHSUNDEEP
androidsqliteandroid-sqlite
Emil Davtyan
Emil Davtyan

Reputation: 14099

SQLiteStatement execute a SELECT / INSERT / DELETE / UPDATE

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?

Upvotes: 6

Views: 5928

Answers (2)

Justin Morris
Justin Morris

Reputation: 7329

Use SQLiteDatabase instead of SQLiteStatement for intereacting with your database. SQLiteStatements are not Thread safe so I would not use them for SELECT / INSERT / DELETE / UPDATE. Also you should try not to use raw database queries for anything other than Selects. There are built in helper functions that will increase your database performance. On your instance of SQLiteDatabase you have .insert, .update, .delete and I use .rawQuery for Selects.

Upvotes: 1

zapl
zapl

Reputation: 63955

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.

Upvotes: 3

Related Questions