Im working with poco-1.5.1.
I build it x64, debug
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 :
const char * my_dbConnString = "DRIVER=SQL Server Native Client 10.0;Trusted_Connection=Yes;DATABASE=Test_81_SqlServer;SERVER=localhost;";
ODBCTest::SessionPtr _session = new Poco::Data::Session(Poco::Data::ODBC::Connector::KEY, my_dbConnString);
select << "SELECT Address FROM Person",
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 '?' characters.
Hope this helps to recreate my problem - I still feel there is something quite fundamental I am missing....
From: Aleksandar Fabijanic [mailto:aleskx@...]
Sent: Thursday, 5 September 2013 10:55 PM
To: Eden, Frank (.)
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?
> -----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
> 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.
> On Tue, Sep 3, 2013 at 7:03 AM, Eden, Frank (.) <frank.eden@...> wrote:
>> 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
>> Is that correct?
>> A sample or two that deal with SQL tables having Unicode columns like
>> NCHAR and NVARCHAR would be good.
>> Frank Eden | Manager Software Systems, Technical Services group HP
>> Software | ph 02 6275 4864 mob 0415 032 644
>> Barry Drive Canberra ACT 2601 | Australia
>> 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 save!
>> c lktrk _______________________________________________
>> poco-develop mailing list