Hi Sergey,
I'm interested into the modified version, you can send me a zip file if you
want.
In meantime i have done a complete implementation of a second string type
(std::wstring) beside the existing std::string type.
If have tested it with vectors, use/into and also with row and rowset support.
I would prefere to have this as additional type beside the standard one to have
full control over converting. Otherwise we have to introduce a new dependency to
one of the conversion libs out there.
Furthermore the problem at MSSQL Server is:
example case 1: varchar(50) column
You have to know wether the collation inside is "ISO-8859-1" or any other to
deal correctly with the std::string data because it's simply ascii at the given
encoding.
example case 2: nvarchar(50) column
You have to interprete at MSSQL the result as UCS2 coded widestring
(std::wstring) and you are now reposible to convert to requested format.
I'm not a friend of behind the scenes conversions, because this may always lead
to unpredictable results in future or real live systems.
I have tested conversions with help of Boost Library as follows:
example case 1: varchar(50) column
string utf8_string =
boost::locale::conv::to_utf<char>(names[i],"ISO-8859-1");
wstring wide_string =
boost::locale::conv::to_utf<wchar_t>(names[i],"ISO-8859-1");
example case 2: nvarchar(50) column
std::string utf8_string =
boost::locale::conv::utf_to_utf<char>(names[i]);
This works properly as expected. At first case you need to know exactly the
collation of the column to get a qualified converted utf8.
So if you have to deal with N databases, all having different ANSI encodings
(ru,pl,ger, sv, etc....) then you need a qualified convert.
If anyone have good reasons for doing implicite converts, please let me know.
Keep in mind, that above converting is portable and WideCharToMultiByte() stuff
isn't.
So I would delegate (rarely) necessary convert to the enduser of library.
BTW: Some C++ middleware code may internally use always std::wstring management
because of sorting, searching, up/downcases and special sorting like
Lexicograpical sorting. (lex sorting: as example the german 'ΓΌ' will not be
sorted to the end of alphabet but within the 'u', this also happens at svenska
and other languages)
regards
Heiko
PS: a push to github will follow during this week, that's my current timeline so
far.
> Sergey Stepanov <[email protected]> hat am 24. Juni 2013 um 15:50
> geschrieben:
>
>
>
> Hi, Everyone
>
> If you really interested, I have fully working version of the ODBC backend
> with Unicode fields implemented.
> I can share the code, but it would be really cool if someone will help me
> pushing those changes to SOCI repository.
> In my implementation I used UTF8 based columns support with translation to
> MSSQL`s UCS2 and back.------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
