I think Keith's recommendation is very appropriate for your problem. In the hope that you will follow it, here is an interpretation and procedure for following it: > Find a row that has a blob that you think ought to be an integer. Examine your results, at the level you originally saw and posted, to find one which was what you wanted or expected, and to find another which led to your original post and the title of this thread. Note the item_id value for these two, which I refer to below as LikedId and WoopsId. Note one column name which had the disappointing results, referred to below as HardColumn. > Find this very same row in your source data that is getting sent to the INSERT statement. Make a copy of your DB to fool around with. Open the copy using the SQLite shell. At that shell's prompt, enter: ``` delete from rsbuddy where not (item_id in (LikedId, WoopsId)); select item_id, typeof(HardColumn) as stored_type from rsbuddy; .exit ``` If the query result shows that the stored type is different between the two result rows, ("integer" in one case and "blob" in the other), concentrate on your insert statements. This means showing them here (if you need more help), including the binding operations that associate values with those '?' tokens. > Examine the "thing" that you think should be an "integer" and see what it is. (Combined with above shell operations.) The shell should be your go-to tool for seeing what is actually in the database. > Thus will your problem be revealed to you. (Hint -- what you are sending is not an integer) Revelation may be a bit more difficultly achieved than said. However, you have a smaller problem to deal with when you know whether or not its genesis is in the storing or the retrieving.