From 4ca4dce2fb14cfdd0e1be01a375768f2db07e615 Mon Sep 17 00:00:00 2001 From: Dave Page Date: Wed, 18 Jun 2003 12:49:21 +0000 Subject: [PATCH] when a column SQL_C_CHAR is handled in ResolveOneParam, the conversion is coded dependent on param_sqltype. If a SQL_CHAR variable is bound to it, no conversion takes place, which is incorrect. ODBC architecture assumes sqltype to be the server_encoding, but this is irrelevant for pgsql. Instead, everything is done with client_encoding (anything but UNICODE doesn't make sense here), so we need a conversion to UTF-8 in any case. [Andreas Pflug] --- convert.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/convert.c b/convert.c index 6c72004..4a2a059 100644 --- a/convert.c +++ b/convert.c @@ -2558,6 +2558,11 @@ ResolveOneParam(QueryBuild *qb) case SQL_C_BINARY: buf = buffer; break; +/********************* + * it's not correct to convert depending on param_sqltype, + * because the client_encoding is always unicode. + * We need conversion in any case. + case SQL_C_CHAR: #ifdef WIN_UNICODE_SUPPORT switch (param_sqltype) @@ -2575,6 +2580,18 @@ ResolveOneParam(QueryBuild *qb) allocbuf = buf; break; default: + +*/ + + if (SQL_NTS == used) + used = strlen(buffer); + allocbuf = malloc(2 * (used + 1)); + used = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, + used, (LPWSTR) allocbuf, used + 1); + buf = ucs2_to_utf8((SQLWCHAR *) allocbuf, used, &used); + free(allocbuf); + allocbuf = buf; + buf = buffer; } #else -- 2.39.5