ODBC Driver 7.02.0001 (Win32) (Unicode mode): CRLF->LF works, LF->CRLF doesn't
Hi all!
Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
(beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
encoded database stored in a PostgreSQL 7.2.1 database running on a
Linux system.
I noticed that when the "LF<->CRLF Conversion" option is *enabled* in
the driver's settings dialog, only a CRLF->LF conversion (while writing
to the database) is performed, but no LF->CRLF conversion (while reading
from the database)!
I thought that this might be a bug, and thus downloaded a local copy of
the ODBC driver sources from CVS. I searched a bit and AFAICT found the
reason for the ill behavior, so I made a patch.
Julian.
==================8<==================snip==================
--- convert.c Fri Jun 21 15:48:43 2002
+++ convert.c.new Fri Jun 21 16:50:01 2002
@@ -699,12 +699,20 @@
if (pbic->data_left < 0)
{
BOOL lf_conv =
SC_get_conn(stmt)->connInfo.lf_conversion;
+ int lf_converted_len;
#ifdef UNICODE_SUPPORT
if (fCType == SQL_C_WCHAR)
{
- len =
utf8_to_ucs2(neut_str, -1, NULL, 0);
+ char* temp_str;
+
+ /* convert linefeeds to
carriage-return/linefeed */
+ lf_converted_len =
convert_linefeeds(neut_str, NULL, 0, lf_conv, &changed);
+ temp_str =
malloc(lf_converted_len + 1);
+ convert_linefeeds(neut_str,
temp_str, lf_converted_len + 1, lf_conv, &changed);
+ len =
utf8_to_ucs2(temp_str, -1, NULL, 0);
len *= 2;
wchanged = changed = TRUE;
+ free(temp_str);
}
else
#endif /* UNICODE_SUPPORT */
@@ -728,7 +736,12 @@
#ifdef UNICODE_SUPPORT
if (fCType == SQL_C_WCHAR)
{
-
utf8_to_ucs2(neut_str, -1, (SQLWCHAR *) pbic->ttlbuf, len / 2);
+ char* temp_str;
+
+ temp_str =
malloc(lf_converted_len + 1);
+
convert_linefeeds(neut_str, temp_str, lf_converted_len + 1, lf_conv,
&changed);
+
utf8_to_ucs2(temp_str, -1, (SQLWCHAR *) pbic->ttlbuf, len / 2);
+ free(temp_str);
}
else
#endif /* UNICODE_SUPPORT */==================snip==================>8==================
--
Linksystem Muenchen GmbH info@link-m.de
Schloerstrasse 10 http://www.link-m.de
80634 Muenchen Tel. 089 / 890 518-0
We make the Net work. Fax 089 / 890 518-77
Julian Mehnle wrote:
[...] I made a patch.
==================8<==================snip==================
[word-wrapped patch]
==================snip==================>8==================
Doh!
I swear I told my news reader not to word-wrap exactly this message,
but it wrapped it anyway... Alright, here's the patch as a file:
http://files.mehnle.net/software/postgresql/pgsql-odbc.unicode-crlf-lf-conversion.diff
Julian.
--
Linksystem Muenchen GmbH info@link-m.de
Schloerstrasse 10 http://www.link-m.de
80634 Muenchen Tel. 089 / 890 518-0
We make the Net work. Fax 089 / 890 518-77
"Julian Mehnle, Linksystem Muenchen" wrote:
Hi all!
Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
(beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
encoded database stored in a PostgreSQL 7.2.1 database running on a
Linux system.I noticed that when the "LF<->CRLF Conversion" option is *enabled* in
the driver's settings dialog, only a CRLF->LF conversion (while writing
to the database) is performed, but no LF->CRLF conversion (while reading
from the database)!
Could you try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/ ?
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
Hiroshi Inoue <Inoue@tpf.co.jp> wrote:
Julian Mehnle <j.mehnle@buero.link-m.de> wrote:
Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
(beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
encoded database stored in a PostgreSQL 7.2.1 database running on a
Linux system.I noticed that when the "LF<->CRLF Conversion" option is *enabled* in
the driver's settings dialog, only a CRLF->LF conversion (while writing
to the database) is performed, but no LF->CRLF conversion (while reading
from the database)!Could you try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/ ?
There are several versions and I don't know which one you mean:
- psqlodbc.dll (version 7.02.0001),
- psqlodbc.dll (the multibyte version),
- psqlodbc30.dll (7.02.0001 ODBC3.0 trial driver),
- psqlodbc30.dll (the multibyte version),
- another trial driver(7.02.0001 + ODBC3.0 + Unicode)?
Please give me a hint! :-)
Julian Mehnle.
Julian Mehnle wrote:
Hiroshi Inoue <Inoue@tpf.co.jp> wrote:
Julian Mehnle <j.mehnle@buero.link-m.de> wrote:
Recently I tried to use the new 7.02.0001 Win32 ODBC driver
in the new (beta) Unicode mode in conjunction with MS Access
2000 and a "UNICODE" encoded database stored in a PostgreSQL
7.2.1 database running on a Linux system.I noticed that when the "LF<->CRLF Conversion" option is
*enabled* in the driver's settings dialog, only a CRLF->LF
conversion (while writing to the database) is performed,
but no LF->CRLF conversion (while reading from the database)!Could you try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/ ?
There are several versions and I don't know which one you mean:
- psqlodbc.dll (version 7.02.0001),
- psqlodbc.dll (the multibyte version),
- psqlodbc30.dll (7.02.0001 ODBC3.0 trial driver),
- psqlodbc30.dll (the multibyte version),
- another trial driver(7.02.0001 + ODBC3.0 + Unicode)?
The last one because you seem to be using Unicode driver.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/
Hiroshi Inoue <Inoue@tpf.co.jp> wrote:
Julian Mehnle <j.mehnle@buero.link-m.de> wrote:
Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
(beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
encoded database stored in a PostgreSQL 7.2.1 database running on a
Linux system.I noticed that when the "LF<->CRLF Conversion" option is *enabled* in
the driver's settings dialog, only a CRLF->LF conversion (while writing
to the database) is performed, but no LF->CRLF conversion (while reading
from the database)!Could you try the snapshot dll at http://w2422.nsk.ne.jp/~inoue/ ?
Yeah, it does *not* exhibit the faulty CRLF<->LF conversion behavior. Is
this a custom build of the ODBC driver done by you? Will the official driver
be fixed soon?
Regards,
Julian Mehnle.
Julian Mehnle wrote:
Yeah, it does *not* exhibit the faulty CRLF<->LF conversion behavior.
Is this a custom build of the ODBC driver done by you? Will the
official driver be fixed soon?
I would commit the fix to cvs this week.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/