Hi, Heiko
Yes, I can understand, that conversion can be a problem, but std::widestring is
a
broblem itself, actually.
Only on windows it represents UCS2, but on all other platforms it is UCS32!
So both ways are error-prone. Question is how to choose between two evils.
I prefer utf8 based implementation cause it is more general and corresponds the
rules of SOCI library from top point of view.
Choosing std::widestring as a base type will cause user of the library to handle
all sort of cross-platform problems instead.
By the way, I tested SOCI with my ODBC backend on about a hundred MSSQL servers
-
all working just fine.
As for collation, I think this is internal thing of server itself, ODBC takes
care on conversion in this case (AFAIR).
You can check it by writing simple ODBC application receiving a string from come
DB.
Anyway, will sand you the file tomorrow.
Regards,
Stepanov Sergey
XMPP: [email protected]
SKYPE: sergey.y.stepanov
mobile: +7(921)345-78-22
Monday June 24, 20:19:20 GMT+0400 2013 пользователь
[email protected] ([email protected]) написал:
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
