I discovered following problem using PostgreSQL with ODBC:
- I create manually a record in the database with insert
- when I select unicode data in application it is OK
- when I update the same record I get ???? it looks like unicode issue
PostgreSQL database is created as UTF8,
but I guess all the UTF8 - UTF16 conversions shoud be handled trough ODBC layers
(at least in one direction it works)
Igor
UNICODE ODBC
Re: UNICODE ODBC
Maybe it is not TD 5.2 issue...anyway i think it is worth of checking...
Here are some pictures:
After select statement in the app
In the database after update (just added another 3 characters in df and executed update)
Here are some pictures:
After select statement in the app
In the database after update (just added another 3 characters in df and executed update)
You do not have the required permissions to view the files attached to this post.
Re: UNICODE ODBC
Igor: (I wanted to look at this for you, but just tried to install PostgreSQL with ODBC and am unable to test past 'invalid password' in the ODBC mgr. Test pb in the Setup screen.)
Is this still an issue for you? If so, in your last msg. you showed images of a SQL utility (pdAdmin III ?) with create/insert statements and a TD app. with a select showing valid Cyrillic text. When you updated (using the TD app), though, your SQL utility now shows "????" for the text data.
How does the text appear in a query/fetch in TD if you also insert a row from your TD app? Also as "????" in the data field? It seems it might well be a Unicode issue, but I am not sure. Did you try any data conversion in the TD before and/or after the insert,update,select code? Like CAST(), SalStrToMultiByte() or SalStrToWideChar().
It would appear -- assuming Unicode ODBC -- that pdAdmin is inserting/fetching correctly as Unicode. but I'd expect TD (unless it is defaulting to ANSI through the router somehow) to be Unicode as well. The "???" though seems to say the Unicode 2-byte chars got converted to single byte with TD.
Let us know if you find out any more information. Thanks.
Is this still an issue for you? If so, in your last msg. you showed images of a SQL utility (pdAdmin III ?) with create/insert statements and a TD app. with a select showing valid Cyrillic text. When you updated (using the TD app), though, your SQL utility now shows "????" for the text data.
How does the text appear in a query/fetch in TD if you also insert a row from your TD app? Also as "????" in the data field? It seems it might well be a Unicode issue, but I am not sure. Did you try any data conversion in the TD before and/or after the insert,update,select code? Like CAST(), SalStrToMultiByte() or SalStrToWideChar().
It would appear -- assuming Unicode ODBC -- that pdAdmin is inserting/fetching correctly as Unicode. but I'd expect TD (unless it is defaulting to ANSI through the router somehow) to be Unicode as well. The "???" though seems to say the Unicode 2-byte chars got converted to single byte with TD.
Let us know if you find out any more information. Thanks.
Re: UNICODE ODBC
Hi Jeff,
I am using PostgreSQL because it is very simple and quick to install and it was ok for smaller projects until now.
Now I have a request to localize my app in cyrilic. I bought brand new TD 5.2 shelled out some serious cash for it and have two big problems I can not use PostgreSQL database another option would be
MS express DB but I gues there are some serious problems with long strings. (I have not tested my app against that database yet - I was a little bit discouraged by the forum posts).
So now I sit and wait for SP1 for almost 3 months...and time is money.
I was thinking - since your development team will be hacking through ODBC code and hopefully solve reported bugs they can also look a little bit to issue which I reported.
My intention with this test case was to test if there are similar long data issues with ODBC with PostgreSQL database as with MS (reported in forum).
And now answers to your questions:
Maybe if you create new user which will be DB owner for your test DB you be able to test TD 5.2 against PostgreSQL.
After select in my app I get ???.
I did not use SalStrToMultiByte() or SalStrToWideChar() - if it will work by using this functions I guess it is not a solution....
Thanks,
Igor
I am using PostgreSQL because it is very simple and quick to install and it was ok for smaller projects until now.
Now I have a request to localize my app in cyrilic. I bought brand new TD 5.2 shelled out some serious cash for it and have two big problems I can not use PostgreSQL database another option would be
MS express DB but I gues there are some serious problems with long strings. (I have not tested my app against that database yet - I was a little bit discouraged by the forum posts).
So now I sit and wait for SP1 for almost 3 months...and time is money.
I was thinking - since your development team will be hacking through ODBC code and hopefully solve reported bugs they can also look a little bit to issue which I reported.
My intention with this test case was to test if there are similar long data issues with ODBC with PostgreSQL database as with MS (reported in forum).
And now answers to your questions:
Maybe if you create new user which will be DB owner for your test DB you be able to test TD 5.2 against PostgreSQL.
After select in my app I get ???.
I did not use SalStrToMultiByte() or SalStrToWideChar() - if it will work by using this functions I guess it is not a solution....
Thanks,
Igor
Re: UNICODE ODBC
I'm told that TD 5.2 SP1 has a "target date of early next month which can slide depending on what comes out as a result of the remaining fixes." so it should not be long now.So now I sit and wait for SP1 for almost 3 months
I was not able to get an initial connect using ODBC DS Mgr. to work for PostgreSQL, Igor, so I am no farther in trying to duplicate your issue. However, I disagree that using SalStrToMultiByte() or SalStrToWideChar() (or CAST) automatically means that there is a bug.I did not use SalStrToMultiByte() or SalStrToWideChar() - if it will work by using this functions I guess it is not a solution....
You wrote that "PostgreSQL database is created as UTF8" and if so, then it may be that there is a 'translation' step necessary between the DB and TD v5.2 I'll try to get Postgre to work on my machine. If so, I can then test fetch, DML etc. (and find some sample Cyrillic text) to better understand what's going on.
How about using zip or rar to attach a sample SQL script? as you show in pdAdmin?
Who is online
Users browsing this forum: [Ccbot] and 5 guests