08-01-2010 01:45 AM
thanks you all! i try with String s = new String(a.getbyte,"UTF-8") before i store in SQLite but it doesnt work.
@Ted : can you tell me how to do with statement PRAGMA ENCODING="UTF-8"
08-01-2010 02:06 AM
Details can be found here. It seems that the pragma must be used before creating the main data base. But from that thread, there may be a problem somewhere before the data gets to the data base.
08-01-2010 09:17 AM
My understanding, and I am not a SQLite expert at all, is that you should provide a String (Unicode) and SQLite should convert it to bytes using the encoding method specified by the pragma. So there is no conversion required at all in your application program.
If this doesn't solve your problem, read on.
I have had problems with this in some devices running earlier OS Levels. The data was correctly stored on device (in fact the database was created on a PC and shipped to the device), but the bytes were being converted using ISO-8859-1 - the default for the BB (at least that is what it looked like to me). So some characters were not correct.
If you think your problem is related to this, then ship your database to a PC, and review the contents using a PC based SQLite Browser, which should respect the pragma directive.
Note that I saw this problem in device and on some simulators too.
08-01-2010 09:39 AM
Peter - Did the behavior change with later OS levels?
Regarding the encoding pragma -- according to the SQLite docs, setting the encoding is a session-level action that must be done before a data base is created. But in RIM's implementation, I don't see where this can be done. There are no methods in DatabaseFactory or anywhere else that I could find to execute statements independent of an existing data base.
If this is the case, and the default encoding ends up being ISO-8859-1, one work-around is to do the String encoding/decoding in the app and store it in a BLOB field.
08-01-2010 11:20 AM
Good points Ted. I actually don't know what the default encoding will be for an on device created database. But I doubt it will be ISO-8859-1, I would have expected UTF-8. I'm not in a position to test this atm, perhaps some one else will?
The issue for me was that the text was being converted using ISO-8859-1, even though the encoding was set correctly to UTF-8.
This is not a problem with the later level OS 5.0. Sorry, I've not noted when it is corrected. However, it was a problem on all devices I tested including Bold 9000. Bold 9700 and Storm 2.