2

I was researching how I can use a java.sql.PreparedStatement object to query an SQLite database in my Android app. I am used to coding my query statements in this way, based on my previous experience coding Java apps that query Oracle databases.

During my Googling and Stackoverflowing, I was able to easily conclude that using android.database.sqlite.SQLiteStatement is the widely accepted solution among Android coders (see this post, for example). Still...I remain curious as to why the accepted solution for Android is to use a class that is not an implementer of java.sql.PreparedStatement.

Why does SQLiteStatement not implement PreparedStatement? What are the differences between the two, in terms of performance, the time of statement compilation, etc. Are there any Android implementations of PreparedStatement in existence?

Community
  • 1
  • 1
ecbrodie
  • 11,246
  • 21
  • 71
  • 120

2 Answers2

2

Because the SQLiteStatement API is not the same as the PreparedStatement API! The former does not implement all of the functionality demanded by the latter. For example:

[SQLiteStatement] represents a statement that can be executed against a database. The statement cannot return multiple rows or columns, but single value (1 x 1) result sets are supported.

Matt Ball
  • 354,903
  • 100
  • 647
  • 710
  • Do you know if there is an existing Android implementation of `PreparedStatement`? Or do I just have to accept using the existing `SQLiteStatement`? Which, *BTW*, I have no problem with using, I actually like using the `SQLiteStatement` class very much...I just want to know 100% for sure. – ecbrodie Oct 04 '12 at 14:02
0

My interpretation is:

Android has SQLLite database in built (No other databases), so Android API provide SQLLiteStatement instead of using whole java.sql API.

SQLLite database itself provides limited functionality, you can't do everything you can do with other databases, so I guess they have introduced light weight API.

kosa
  • 65,990
  • 13
  • 130
  • 167