Code: Select all
sqlite3_open(strDatabase.c_str(), &m_pDatabase);
Is it planned to support Unicode build in a future version of databaselayer? If yes, when one may expect this to be the case?
Regards,
Ulrich
Code: Select all
sqlite3_open(strDatabase.c_str(), &m_pDatabase);
Thanks for your reply. Since Unicode builds are my primary target maybe I'm able to assist in this regard. As soon as my limited time resources allow I'll take a closer look at the databaselayer code.jb_coder wrote:I'll see what I can do to get databaselayer Unicode compatible. Unfortunately, I can't give you a time frame since I haven't worked with wxWidgets compiled for Unicode before.
Great!jb_coder wrote:I've got the SQLite code working with Unicode builds in CVS.
When I implemented my component wxSQLite3 the wxWidgets book wasn't available yet. I wish I had known those methods then. Maybe I change my conversion code in the next release since the methods from the wxWidgets book seem to be simpler.jb_coder wrote:I ended up using the ConvertToUTF8 and ConvertFromUTF8 functions from the wxWidgets book.
In case of a blob you shouldn't convert to UTF8. If the string contains non-ASCII characters the length of the UTF8 string is greater than that of the original string. Ok, this is not the case in your test code, but you add 1 to the length. Since you have no longer a C string as before introducing UTF8 conversion you don't have the terminating null character in the converted string but probably a random character. This may cause an invalid UTF8 string which is not converted at all when you read back from the database. But even if the UTF8 string is valid your result will be one character longer (since you added 1) causing the comparison to fail.jb_coder wrote:I think that I messed up something somewhere (maybe SqliteDatabaseLayer::PrepareStatement) because now the unit test fails when attempting to store a string as a blob.
Except for the blob case the code seems to be ok.jb_coder wrote:I'll start working on the rest of the database backends. Please let me know if the methods that I'm using aren't comprehensive enough for regular Unicode usage.
For me it would be ok to use void* parameter.jb_coder wrote:Also, I'm wondering about switching the PreparedStatement::SetParamBlob from using an unsigned char* parameter to using a void* parameter. Would anyone object to that?
Ah, good news!jb_coder wrote:All four database backends now compile and pass the unit tests under Unicode builds now.
Strange. I'll take a look at the code later, maybe I have an idea what's causing the problem.jb_coder wrote:One funny thing that I found was that I had to fix a memory leak under MySQL to get the Unicode build to pass the unit tests, but that memory leak fix caused a segmentation fault under the non-Unicode build so I had to wrap it in a "#if wxUSE_UNICODE" block.