However, it was awhile I were active with POCO but this might help you.
The question is whether your POCO has been compiled with native wchar
(UTF16) support, and of course whether your source were compiled with this
Just converting a L' ' long (UTF16) string won't make a match with the
appropriate function calls. I think what you must look for is that ODBC
function calls are consistent with the UNICODE_win32.cpp calls (which Alex
refered to). If you see function names on the call stack ending with A
(ASCII) and W (widechar, native UTF16) mixed then it is definitely an error.
If your program were compiled with widechar, native UTF16 support then in
the code you might need to prefix the strings with L' ' (since your source
file also can be encoded in UTF8 or UTF16 depending on your editor) but
otherwise it is safe to pass wchar / wstring to the functions. In this case
use std:wstring to handle the strings.
If no wchar support were compiled in then you must use all other libs also
without wchar support and of course you should only use std:string and
convert all L' ' UTF16 strings to UTF8 with the appropriate function before
storing in std:string.
It might happen that I refer something wrong since I dig POCO in the past
but the general idea and problems of *char* (ASCII and UTF8 *only*) vs. *
wchar* (UTF16 *only*) is this. It is the compile time when the internals
get refered so the string handling must be consistent over all the code and
Hope this help some..
PS: I use this site for C++ reference:
On Mon, Sep 9, 2013 at 6:57 AM, Eden, Frank (.) <frank.eden@...> wrote:
> Hi Alex,
> Im working with poco-1.5.1.
> I build it x64, debug
> - Foundation_x64_vs110.sln,
> - Data_x64_vs110.sln,
> - CppUnit_x64_vs110.sln
> - ODBC_x64_vs110.sln,
> I then added the ...\poco\bin64 folder to my path, restarted Visual Studio.
> I commented out all but the SQLserver tests:
> // addTest(pSuite, ODBCMySQLTest::suite());
> // addTest(pSuite, ODBCOracleTest::suite());
> // addTest(pSuite, ODBCPostgreSQLTest::suite());
> // addTest(pSuite, ODBCSQLiteTest::suite());
> Then I added some code into :
> CppUnit::Test* ODBCSQLServerTest::suite()
> const char * my_dbConnString = "DRIVER=SQL Server Native Client
> ODBCTest::SessionPtr _session = new
> Poco::Data::Session(Poco::Data::ODBC::Connector::KEY, my_dbConnString);
> std::string address;
> Statement select(*_session);
> select << "SELECT Address FROM Person",
> range(0, 1);
> while (!select.done())
> address = address; // <<< put breakpoint here
> Name (varchar(30), null)
> Address (nvarchar(30), null) << - Note NVARCHAR
> Age (int, null)
> SELECT * FROM Person
> Name Address Age
> NULL Canberra 10
> Run program, correct results at breakpoint, all good
> SELECT * FROM Person
> Name Address Age
> NULL который 10 << Note Russian word here
> Run program, address does not have anything useful - just full of '?'
> Hope this helps to recreate my problem - I still feel there is something
> quite fundamental I am missing....
> -----Original Message-----
> From: Aleksandar Fabijanic [mailto:aleskx@...]
> Sent: Thursday, 5 September 2013 10:55 PM
> To: Eden, Frank (.)
> Cc: poco-develop@...
> Subject: Re: [poco-develop] ODBC UTF8 Unicode
> It depends on what your driver manager and driver itself is doing as well
> as how the DB is configured. I'd have to know how POCO was compiled and
> reproduce your environment to give you the accurate answer. It will help
> you to trace whether and where exactly your calls end up here:
> and also, enable tracing for the ODBC driver to see what the driver
> manager exactly calls. That may give you a better idea of what's going on.
> On Tue, Sep 3, 2013 at 6:03 PM, Eden, Frank (.) <frank.eden@...> wrote:
> > Hi Alex,
> > Yes thanks, that helps a lot, but I am not quite there yet. I must
> still be doing something fundamentally wrong.
> > Perhaps this is a support question, but if you can guide me a bit I will
> put together a detailed explanation of how to do this - which may be of
> benefit to others.
> > So using SQLServer, I changed the first column of the Person table to be
> Unicode by making it NVARCHAR:
> > session << "CREATE TABLE Person (Name NVARCHAR(30), Address
> > VARCHAR(30), Age INTEGER)", now;
> > Then I did this:
> > std::string name;
> > Poco::UnicodeConverter::convert(L"который", name);
> > session << "INSERT INTO Person VALUES(?, 'Springfield', 10)",
> > use(name), now;
> > But that didn't work - when I run a query against the database I get
> rubbish in that first column.
> > Any thoughts?
> > Cheers,
> > Frank
> > -----Original Message-----
> > From: Aleksandar Fabijanic [mailto:aleskx@...]
> > Sent: Tuesday, 3 September 2013 10:18 PM
> > To: Eden, Frank (.)
> > Cc: poco-develop@...
> > Subject: Re: [poco-develop] ODBC UTF8 Unicode
> > Frank,
> > Yes, that is correct. The best way to deal with Unicode in
> platform-independent way is UTF-8, so POCO internally does everything in
> terms of UTF-8 and std::string, interfacing UTF-16 and UTF-32 APIs by means
> of conversion from/to UTF-8.
> > On Windows, Unicode flavor of the ODBC library should be in good shape.
> On other platforms there are additional complications; unixODBC is UTF-16
> oriented by default while iODBC is UTF-32, so Unicode was not thoroughly
> tested there. Some contributions in forms of testing and github pull
> request patches are highly desirable and encouraged.
> > Hope this helps.
> > Alex
> > On Tue, Sep 3, 2013 at 7:03 AM, Eden, Frank (.) <frank.eden@...>
> >> Hi,
> >> I have done a lot of work to introduce support for std::wstring into
> >> the POCO ODBC library.
> >> Sadly I think my efforts were wasted, because I am starting to
> >> suspect that Unicode support is already there in the form of UTF8.
> >> Is that true? If so I will wind back all my changes and do it the
> >> correct way ( if I can work out what that is)
> >> Am I right in thinking that f I have a table with an NCHAR(10)
> >> column, and I do a SELECT on it, the data for that column will end up
> >> in an std::string, which, on Windows, I can convert from UTF8 to
> >> std:;wstring
> >> Is that correct?
> >> A sample or two that deal with SQL tables having Unicode columns like
> >> NCHAR and NVARCHAR would be good.
> >> Cheers,
> >> Frank
> >> Frank Eden | Manager Software Systems, Technical Services group HP
> >> Software | ph 02 6275 4864 mob 0415 032 644
> >> Barry Drive Canberra ACT 2601 | Australia
> >> http://www.hp.com/go/software
> >> P Please consider the environment before printing this e-mail.
> >> HP TRIM is the perfect place to store vital emails for future reference.
> >> ---------------------------------------------------------------------
> >> -
> >> -------- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL
> >> 2012, more!
> >> Discover the easy way to master current and previous Microsoft
> >> technologies and advance your career. Get an incredible 1,500+ hours
> >> of step-by-step tutorial videos with LearnDevNow. Subscribe today and
> >> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.
> >> c lktrk _______________________________________________
> >> poco-develop mailing list
> >> poco-develop@...
> >> https://lists.sourceforge.net/lists/listinfo/poco-develop
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> poco-develop mailing list