Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Character set conversion doesn't work correctly for field and table names using ODBC | ||
---|---|---|---|
Product: | Base | Reporter: | ludob <ludo.brands> |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | UNCONFIRMED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues |
Version: | OOO300m9 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
ludob
2009-06-09 17:22:17 UTC
same behavior in OOO310m11 same behavior in OOO310m11 @ Ludo This issue still in OOo 3.2? Tested on OOO320m12 and the problem is still there. Used the MyQL 5.1 driver and my own driver to test. Created a table named "test" with a field named "tést". Open table and insert row -> error: unknown column 'tÃf st' in field list. The odbc log shows a SQLPREPARE with the following query "INSERT INTO `test` (`ID`, `t\ff\ff\ff\ffst`) VALUES ...) . Clearly the é was translated twice with probably system->utf8 to become 4 bytes. According to the same log the table was created with the field name `t\ff\ffst` which is OK (windows ODBC manager doesn't know utf8 and logs all none ascii characters as \ff). I had a further look into this. Part of the problem is the windows ODBC manager. All drivers tested support wide character ODBC function calls (SQLExecuteW, etc) and the single byte character ones (SQLExecute, etc). The windows driver manager sits between OOO and the driver. OOO uses the single byte version of the ODBC function calls and the windows driver manager translates the single byte function calls to wide character ones. It translates also the parameters from system to utf16 in doing so (é in UTF8 is two bytes, translating with system to utf16 gives two wide characters). The drivers continue with the utf16 values and will use wrong field names. This explains the first 2 errors reported in the original issue. I have to conclude that this is not an OOO issue. The test case in my earlier comment today does however still show a problem with a double translation in OOO. |