To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102623 Issue #|102623 Summary|Character set conversion doesn't work correctly for fi |eld and table names using ODBC Component|Database access Version|OOO300m9 Platform|PC URL| OS/Version|Windows XP Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|ludob
------- Additional comments from [email protected] Tue Jun 9 16:22:17 +0000 2009 ------- When selecting in Database properties / Additional settings / Data conversion / Character Set the value Unicode(utf8), field and columns names are not displayed or used correctly everywhere when non ascii characters are present in the names. The errors: - column headers in the Table Data View are not correctly displayed. Non ascii characters are replaced with a "white question mark in black square" or other symbol. The fields listed when editing the table structure are correct however. Table was created using originale database client software (Oracle web client, Mysql Query Browser,...) - create a new table in design view with field names containing non-ascii characters. The Table Data View will display the field name correctly but when looking at the database with the database vendor's tools, the field name was created with every non ascii character replaced by 2 other characters. The fields listed when editing the table structure correspond with what is seen on the database. - create a new table with a table name containing non-ascii characters. The table will be created with wrong characters in it's name. This behavior is noticed with ODBC drivers from Oracle and MySQL. I'm also developping a special ODBC driver and I've noticed that for example in case 2, the driver will receive a call to SQLExecDirectW with a wide string "Create table ..." containing in the field name the characters é instead of the expected character é. Since é is the byte representation of é in UTF8, I have to conclude that the UTF8 code is encoded by a single byte codepage (system?) to unicode conversion. When I looked at the character codes sent and received in the other test cases, the conclusion was similar: a wrong encoding/decoding is used: probably system-unicode instead of utf8-unicode. Same problem is noticed in 2.4.1. Ludo Brands --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
