Using execSQL for INSERT operation in Android SQLite

Question

From the documentation and this post I know execSQL() executes a single SQL statement that is not a SELECT or any other SQL statement that return

Answer 1

insert operation can be done in the Following way

 SQLiteDatabase db = this.getWritableDatabase();

    ContentValues values = new ContentValues();
    values.put(KEY_NAME, contact.getName()); // Contact Name
    values.put(KEY_PH_NO, contact.getPhoneNumber()); // Contact Phone

    // Inserting Row
    db.insert(TABLE_CONTACTS, null, values);
    //2nd argument is String containing nullColumnHack
    db.close(); // Closing database connection

for more information refer the link with code http://www.blazin.in/2016/02/understanding-sqlite-database-in-android.html

Answer 2

You can use it, it is just not recommended because you won't receive any information that might be generated by the DB. The methods you are supposed to use return codes/cursors/other info to let you know what happened so you can deal with them if there is a problem.

The key is this line in the execSQL docs:

It has no means to return any data (such as the number of affected rows). Instead, you're encouraged to use insert...

The important word there is "encouraged". You can use execSQL for any SQL command, but you get no feedback on the process, which makes it rather dangerous to use for something where you should get feedback (unless you don't care than an insert failed, or only 2 of 5 records got updated).

Answer 3

INSERT statements do not return result sets, at least not in Sqlite.

The Android docs says this about execSQL:

Execute a single SQL statement that is NOT a SELECT or any other SQL statement that returns data. It has no means to return any data (such as the number of affected rows). Instead, you're encouraged to use insert(String, String, ContentValues), update(String, ContentValues, String, String[]), et al, when possible.

I am not an Android programmer, but I would certainly not be encouraged to use the insert function instead of execSQL, except if I want to retrieve the rowid of the inserted record. Furthermore, the quoted explanation is at best confusing as it implies that insert could return some data.

Note that it's possible that there is some side effect that would make insert a better choice than execSQL, or that "best practices" dictate you use insert.