Why is the assignment of Android cursor from SQLite returning 0 for true

Question

I'm developing an Android app, whilst learning, that accesses an SQLite database which holds some boolean data (amongst other data) in columns but I'm confused about how the boolean data is being represented.

As I understood it, for SQLite purposes, 0 is false and 1 is true. This is bourne out by my searches regarding my problem (see get-boolean-from-database-using-android-and-sqlite and SQLite Docs for two examples).

Regarding my particular problem, the table I am querying has two boolean columns and in the row in question, both columns are 'true' at this moment in time. However, when I assign the values from these columns in my app, they are 'false'. Here is the scenario in code terms;

SQLiteDatabase db = getReadableDatabase();
String[] result_cols = new String[] { KEY, FD_CONTACT_FNAME, FD_CONTACT_SNAME, FD_IS_PUPIL, FD_IS_ACTIVE };
String where = KEY + " = ?";
String whereArgs[] = {id};
String groupBy = null;
String having = null;
String order = null;

Cursor cursor = db.query(DB_TABLE_CONTACTS, result_cols, where, whereArgs, groupBy, having, order);
Log.d("ACONTACT", DatabaseUtils.dumpCursorToString(cursor));

while (cursor.moveToNext()) {
    int three = cursor.getInt(3);
    int four = cursor.getInt(4);

    if (cursor.getInt(3) == 1) {
        Log.d("ONE", "1");
    } else if (cursor.getInt(3) == 0) {
        Log.d("ZERO", "0");
    }

    Contact mContact = new Contact(cursor.getLong(0), cursor.getString(1), cursor.getString(2), ((cursor.getInt(3) == 1)? true : false), (cursor.getInt(4) > 0));
    Log.d("ACONTACT", String.valueOf(mContact.getIsPupil()) + " .... " + String.valueOf(mContact.getIsActive()));
    Log.d("ACONTACT", String.valueOf(cursor.getInt(3)) + " .... " + String.valueOf(cursor.getInt(4)));
    Log.d("ACONTACT", cursor.getString(1) + " .... " + cursor.getString(2));
    Log.d("ACONTACT", String.valueOf(cursor.getLong(0)));
    return  mContact;
}

The logging aspect of the code results in;

D/ACONTACT: >>>>> Dumping cursor android.database.sqlite.SQLiteCursor@418c5f28
        0 {
           _id=24
           fname=Harry
           sname=Ballard
           is_pupil=true
           is_active=true
        }
        <<<<<
D/ZERO: 0
D/ACONTACT: false .... false
D/ACONTACT: 0 .... 0
D/ACONTACT: Harry .... Ballard
D/ACONTACT: 24

'Contact' is a custom class, nothing complicated, that has a constructer like so;

    public Contact( long id, String fname, String sname, Boolean isPupil, Boolean isActive ) {
    this.id = id;
    this.fname = fname ;
    this.sname = sname ;
    this.isPupil = isPupil;
    this.isActive = isActive;
}

I can see from the logging that the cursor is correct when it is dumped by 'DatabaseUtils' but when I read the cursor values, either into my class or into any other variables for debugging, they appear wrong (both int 'three' and int 'four' hold zero for example, so false, after assignment). The data in the three other columns is always correct.

I'm obviously missing something but as I see it, the cursor holds the correct data (two boolean columns, both with values of 'true', as seen by cursor dump) but then cursor.getInt(3) and cursor.getInt(4) both return zero, ie false. How can the cursor appear to change, it's doing my head in :)

Have said all that, my title probably isn't accurate, as the cursor is at first correct but then something goes wrong. Anybody any clues as to what?

Answer 1

When the documentation says that "Boolean values are stored as integers 0 (false) and 1 (true)", then it means exactly that: you have to store them as the numbers 0 and 1 .

At the moment, you are storing the strings true or false in the database. These values cannot be converted into an integer.

Answer 2

Ok, my apologies for the noise. The boolean data was inserted into the database using literal values 'true' and 'false'. Therefore, using integer logic ('cursor.getInt(0) > 0' or equivalent) to determine true or false always returned false because the value held was literally 'true' and not '1'.

I hope that's clear. Again, apologies for the noise.