Bug 68676 - ODBC: optionally use W variants of ODBC calls
Summary: ODBC: optionally use W variants of ODBC calls
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: All All
: medium enhancement
Assignee: Mike Kaganski
URL:
Whiteboard: target:25.2.0
Keywords: difficultyInteresting, easyHack, skillCpp, skillSql
Depends on:
Blocks: Database-Connectivity
  Show dependency treegraph
 
Reported: 2013-08-28 17:51 UTC by Lionel Elie Mamane
Modified: 2024-07-28 08:26 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2013-08-28 17:51:45 UTC
Currently, LibreOffice only uses the "ANSI" variants of the ODBC calls, never the Unicode variants (with a W suffix). However, much (but not all) of the code is actually prepared to use the Unicode variants.

Using the Unicode variants can be useful because it allows us not to mess with encodings, we get more-or-less directly the UTF-16 that our OUStrings need. Also, it allows to work around bugs in ODBC drivers, see e.g. the discussion in comment 13 of bug 68426. But it may trigger *other* bugs in ODBC drivers...

Some decision needs to be done when to use which variant. Possibly it should just be an "Advanced setting" (see menu edit / database / advanced settings), or even better something set in the same dialog tab as the connection charset.

See in directory connectivity/source/drivers/odbcbase/:

 - OTools.cxx: argument _bUseWChar to various functions

 - OPreparedStatement.cxx: constant useWChar

 - OResultsetMetaData.cxx: this one is not ready;
   need to use N3SQLColAttribute OR  N3SQLColAttributeW
   depending on conditions / configuration / ...

directory connectivity/source/drivers/odbc/:

 - OFunctions.cxx

 - ORealDriver.cxx

these to add the W variants to these two functions.

There is a good explanation on ODBC and Unicode in general at
http://www.easysoft.com/products/data_access/odbc_oracle_driver/unicode.html#odbc
the authoritative reference is at
http://msdn.microsoft.com/en-us/library/windows/desktop/ms716246(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms709439(v=vs.85).aspx
Comment 1 Alex Thurgood 2015-01-03 17:39:26 UTC Comment hidden (noise)
Comment 2 Robinson Tryon (qubit) 2015-12-13 13:24:12 UTC Comment hidden (noise)
Comment 3 Robinson Tryon (qubit) 2016-02-18 14:52:23 UTC Comment hidden (noise)
Comment 4 Mike Kaganski 2024-07-27 12:10:19 UTC
When I saw and decided to fix bug 131238, I didn't know about this easyhack. I accidentally fixed it :-)
Comment 5 Commit Notification 2024-07-27 12:11:34 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5ed1415d1cf03a3d671ebd11582dfaa90f1168bd

tdf#68676, tdf#131238: implement and use Unicode ODBC functions on Windows

It will be available in 25.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Commit Notification 2024-07-28 08:26:48 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/fac23917fcc6b8846c5cf1e6f88c03e74e332f9e

tdf#68676 Fix textual data length sent to SQLBindCol

It will be available in 25.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.