Right Truncation, varchar in SQL Server, double-byte in Oracle

Question

Hi.
We have a DB Link using DG4MSQL from Oracle 11.1.0.7.0 to a SQL Server 2005 database. The Oracle database is set up to use UTF-8 so all character fields are double-byte on the oracle side.
On the SQL Server table we have a column defined as varchar(32). When doing a select * from this table (from Oracle, over the DB link), everything works fine if that column contains values with a length of 16 characters or less. When the column contains 17 - 32 characters we get the following error:
Error report:
SQL Error: ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
[Oracle][ODBC SQL Server Driver]String data, right truncation {01004}
ORA-02063: preceding 2 lines from SQLUAT
28500. 00000 - "connection from ORACLE to a non-Oracle system returned this message:"
*Cause:    The cause is explained in the forwarded message.
*Action:   See the non-Oracle system's documentation of the forwarded
message.
It looks like Oracle (or the ODBC driver) is bringing the data back as double-byte even though it is declared as varchar. If we change the column on the SQL server side to nvarchar, everything works fine.
Is this a bug? Or is there a setting that can be specified for the gateway so that it recognizes SQL Server varchar columns as single-byte, to prevent them from coming over as double-byte and messing up the ODBC driver? Or is there anything else we should do to prevent this problem?
Thanks

Answer 1

Hi,
I don't think it's a problem with the hs or the dblink (but I may be wrong):
UTF-8 is double-bytes as you said. when you declare varchar2(32) it actually means you can insert up to 32 bytes --> 16 characters.
even if you do a simple insert to the table with more than 16 characters - it will fail.
In order to overcome this you should declare the table with varchar2(32 char) which will tell Oracle to allocate enough bytes to hold 32 chars - not bytes. In UTF-8 this means 64 bytes (2*n). If you'd be using AL32UTF-8 this would mean 4*n.
BTW- why are you using UTF-8 and not AL32UTF8?
Hope this helps.