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]

diff --git a/convert.c b/convert.c
index 6c720042120c9252ccf579dd8df04bb1db268cfb..4a2a059b8d82effa37a9fa7fb5173e390aabc65d 100644 (file)
--- 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