Cursor does not contain column that exists

Question

I have a database in and android application I am modifying (Open Data Kit) that keeps track of the status and other relevant information of a set of .xml documents which are represented as forms.

To facilitate a ListView to display information about these forms to the user, I am using a cursor to hold information from a query to the database like so (Yes, I know that managedquery is deprecated):

    String selection = InstanceColumns.RANDOM_ID + " = ? AND " 
    + InstanceColumns.STATUS + " = ? AND " + InstanceColumns.JR_FORM_ID + " = ?";

     String[] selectionArgs = {"2433", InstanceProviderAPI.STATUS_COMPLETE, "sample"};
     String sortOrder = InstanceColumns.STATUS + " DESC, " 
     + InstanceColumns.DISPLAY_NAME + " ASC";

     Cursor c = managedQuery(InstanceColumns.CONTENT_URI, null, selection, selectionArgs,
                    sortOrder);

In my current setup, this returns a cursor of 1 row, 10 columns. However, I should be getting 11 columns - I am missing the column corresponding to InstanceColumns.RANDOM_ID

This row is new to the table - the previous 10 were pre-existing before I began working on the code.

I know this columns exists in my database. I write to it elsewhere in my code and I have also manually inspected the .db file, which does contain the column and data I have inserted.

I can provide more code if necessary (which I suspect it will be), but this application is fairly large and open source. This may be caused by some internal setting I am unaware of.

This is what I get on a crash:

E/CursorWindow: Failed to read row 0, column -1 from a CursorWindow which has 1 rows, 10 columns.

Typically whenever I attempt to access that column, such as:

int randomID = c.getInt(c.getColumnIndex(InstanceColumns.RANDOM_ID));

This is from a clean install to ensure a new database file and occurs both on the emulator and on my device.

How can I make my cursor contain all the rows of my table?

Answer 1

Coming back to this just to close, there was a projection hashmap defined elsewhere in the code that I found after much digging that put constraints on querying the table. Adding a row to the hashmap and updating it allowed the query to go through.