Feedback

Feedback

Did this article resolve your question/issue?

   

Article

Support for wchar_t with the Connect for ODBC drivers on UNIX/Linux

Printable View

Information

 
TitleSupport for wchar_t with the Connect for ODBC drivers on UNIX/Linux
URL Name3072
Article Number000143376
EnvironmentProduct : Connect/Connect64 for ODBC Driver Manager
Version : 7.1
OS : Windows
Database : SQL Server, Ingres, PostgreSQL
Application : All supported applications
Question/Problem Description
Is the wchar_t supported with the DataDirect ODBC drivers on UNIX/Linux?
Steps to Reproduce
Clarifying Information

Applications that have been built to use the native type wchar_t may observe that the DataDirect Connect for ODBC drivers do not always define SQLWCHAR the same way that wchar_t is defined natively by O/S. One commonly cited example is the Solaris platform, which defines a wchar_t as a 32-bit long while for 64-bit applications, a wchar_t is defined to be a 64-bit int. In either case, a wchar_t on Solaris represents a 4-byte character.  By contrast the Connect for ODBC drivers define SQLWCHAR by default as a unsigned char (1 byte) however allow this to be changed to an unsigned short (2 bytes).

Error Message
Defect Number
Enhancement Number
Cause
Resolution

The short answer why the Datadirect components do not define SQLWCHAR to be the same value as the native wchar_t definition on Solaris is because wchar_t can vary from platform to platform. Below is a list of the "native" Unicode encodings for some common platforms:
 

AIX: UTF-16
HPUX: UCS-4
Linux: UCS-4
Solaris: UCS-4
Windows: UTF-16
 

On some platforms, like Windows, a wchar_t will be a 2 byte value. On others, such as Solaris and Linux, it will be a 4 byte value.  Accounting for the differences between how wchar_t is defined across multiple operating systems would make porting applications from one platform to another much more difficult that it has to be.  DataDirect's approach to this situation is to simplify the porting process as much as possible for customers.
 

In general, an application using ODBC should always use ODBC types (such as SQLWCHAR) instead of native types (such as wchar_t) to make sure all components are maximally portable across operating systems.  Doing so ensures that even as you port your application from one platform to another, the size of any character data buffers will stay the same which means one less thing to have to worry about in the porting process.  Most DataDirect customers that write Unicode applications do so on Windows then port their application code to other operating systems.  To aid in this process, DataDirect components now offer support for UTF-16 across all UNIX/Linux platforms in addition to the default support of UTF-8 which has been offered for years.


There is no easy answer to help users avoid making at least some changes to their application to use SQLWCHAR instead of wchar_t. Some faced with this issue have either elected to use a conversion library such as IBM's ICU (see www.icu.org) to perform conversions where necessary or have simply taken the time to modify their code for maximum portability (i.e. use SQLWCHAR instead of wchar_t).

Workaround
Notes
Last Modified Date7/23/2019 9:31 PM
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.


Copyright © 2022 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.

Progress, Telerik, Ipswitch, Chef, Kemp, Flowmon and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.

Terms of Use Privacy Center Security Center Trademarks License Agreements Code of Conduct Careers Offices
Do Not Sell My Personal Information