You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I work with a database that runs with NLS_LANG set to AMERICAN_AMERICA.CL8MSWIN1251 and have no write access to it. On my side NLS_LANG is set to AMERICAN_AMERICA.UTF8. When I execute a select statement, the result contains truncated data for cyrillic VARCHAR2 fields. It looks like the buffer for the incoming data uses its length in bytes in cp1251, not in utf8.
You can perform the following request to test this behaviour:
SELECT 'ААБББВВВ' AS "col1", RAWTOHEX('ААБББВВВ') AS "col2" FROM DUAL
I get this as a result:
[ { col1: 'ААББ', col2: 'C0C0C1C1C1C2C2C2' } ]
tcpdump shows that the server's response is correct cp1251 data with no truncation.
The text was updated successfully, but these errors were encountered:
@paulish thanks. The problem is indeed likely due to buffer sizing but we need to analyze where so we fix all potential issues and don't unnecessarily inflate memory use. The general rule of thumb is to multiply by the client/server character expansion ratio, which could be less than the '4' you have chosen.
I work with a database that runs with NLS_LANG set to AMERICAN_AMERICA.CL8MSWIN1251 and have no write access to it. On my side NLS_LANG is set to AMERICAN_AMERICA.UTF8. When I execute a select statement, the result contains truncated data for cyrillic VARCHAR2 fields. It looks like the buffer for the incoming data uses its length in bytes in cp1251, not in utf8.
You can perform the following request to test this behaviour:
I get this as a result:
tcpdump shows that the server's response is correct cp1251 data with no truncation.
The text was updated successfully, but these errors were encountered: