[MDEV-5456] ConnectSE: ODBC: set remote connection character set to DATA_CHARSET Created: 2013-12-16  Updated: 2023-11-28

Status: Open
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.10
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Minor
Reporter: Alexander Barkov Assignee: Andrew Hutchings
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When connecting to a remote DSN, the connection character set
should be set according to DATA_CHARSET parameter of the table.

For example, assuming DATA_CHARSET is utf8, it should:

  • For MySQL: send this query:

    SET NAMES utf8;

  • For PostgreSQL: send this query

    SET NAMES 'utf8';

    Note, PostgreSQL character set names slightly differ from MySQL character set names,
    for example win1251 vs cp1251. So there should be some mapping.

  • TODO: learn how to do this with Oracle, SQL Server and some other
    databases.

The connection character set should be set immediately after SQLDriverConnect.
The type of the remote data source can be detected with help of these functions:

SQLGetInfo(SQL_DRIVER_NAME)
SQLGetInfo(SQL_DRIVER_VERION)
SQLGetInfo(SQL_DBMS_NAME)

Additionally, the error message returned from the remote data source
should be properly escaped. Currently the full error message is cut
if the connection character set is not utf8. This query against a
MariaDB server running on a French Windows machine:

CREATE TABLE t1 ENGINE=CONNECT TABNAME='public.t1' TABLE_TYPE=ODBC 
CONNECTION='DSN=ConnectEnginePostgresql;UID=mtr;PWD=mtr';

returns this error message:

MariaDB [test]> select * from t1;
ERROR 1296 (HY000): Got error 174 'ERREUR: le caract' from CONNECT

Notice, it was cut on the first accented character.
The full error message

ERREUR: le caractère dont la séquence d'octets est 0xd1 0x8f dans l'encodage « UTF8 » n'a pas> d'équivalent dans l'encodage «WIN1252»;

was cut because cp1252 was misinterpreted as utf8.
The error returned from SQLError() must be properly converted/escaped using ErrConvString to avoid this.



 Comments   
Comment by Elena Stepanova [ 2014-04-09 ]

I didn't re-check, but assume the problem still exists, thus setting affected version to the current 10.0.10.

Generated at Thu Feb 08 07:04:31 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.