next version of DBD::ODBC including available unicode patch?

Hi,

I have bumped into sever issue with DBD::ODBC, the most important one is the
Unicode problem.

I found this patch by Alexander Foken
http://www.alexander-foken.de/downloads.html
that is good so far except that it only works using binded values.
This example I added to the 41Unicode.t is broken.

$dbh->do("INSERT INTO PERL_DBD_TABLE1 (i,nva,nvb,nvc) values (100,
'$data[0]', '$data[1]', '$data[2]')");
my $xsth = $dbh->prepare("SELECT nva, nvb, nvc FROM PERL_DBD_TABLE1
WHERE i=?");
$xsth->execute(100);
my (@row) = $xsth->fetchrow_array;
foreach my $i (0..2) {
utf_eq_ok($row[$i],$data[$i],"value matches col $i");
}
$xsth->finish;


(ok I know we should only use binded values but there are tons of code
working without so it would be nice if that worked as well.


Will someone who understnads this better than I do
release a version to CPAN? Even if that is only an unofficial
development release
(e.g. 1.14_01 )

Has Jeff Urlwin disappeared from the Perl world?


regards
Gabor

--
Gabor Szabo
http://www.szabgab.com/
Perl Training in Israel http://www.pti.co.il/

Re: next version of DBD::ODBC including available unicode patch?

Gabor Szabo wrote:
> Hi,
>
> I have bumped into sever issue with DBD::ODBC, the most important one
> is the
> Unicode problem.
>
> I found this patch by Alexander Foken
(that's me)
> http://www.alexander-foken.de/downloads.html
> that is good so far except that it only works using binded values.
And for good reasons.
> This example I added to the 41Unicode.t is broken.
>
> $dbh->do("INSERT INTO PERL_DBD_TABLE1 (i,nva,nvb,nvc) values (100,
> '$data[0]', '$data[1]', '$data[2]')");
Do you know what SQL injection means? If yes, why do you still use this
code style? If no, please learn what it means, a good starting point is
http://en.wikipedia.org/wiki/SQL_injection

> (ok I know we should only use binded values but there are tons of code
> working without so it would be nice if that worked as well.
Why should I (or someone else) build (probably huge) workarounds only to
*OPEN* security holes?

OK, that's enough ranting for today, back to the facts:

It can't work, because the ODBC API only accepts non-Unicode SQL
statements, or at least I did not find a way to make ODBC work with SQL
strings encoded in UTF-8 or UTF-16 from a non-Unicode application like
perl.exe (and I think there is no way for a Unicode application to use a
non-Unicode SQL string except by converting it to Unicode). The
parameters are a completely different thing, they are passed to the ODBC
database driver without modification, and (at least for the SQL Server
and Oracle driver) from there to the database server, again without
modification, no matter if the application is Unincode or Non-Unicode
(like perl.exe). The same applies to fetched column values.
> Will someone who understnads this better than I do
> release a version to CPAN? Even if that is only an unofficial
> development release
> (e.g. 1.14_01 )
I still hope for someone to do this. I do not have enough insight into
ODBC on Win32 and the inner workings of DBI drivers to declare my patch
as good enough for a release. For that, I would need to be sure that the
code is right and works with all of DBI, not just know that it works
with *one* application that uses only a small part of DBI.
The patched code should at least disable the Win32-specific hack on
non-Win32 platforms, preferably, it would also work on non-Win32
platforms. This is clearly something that was neither tested nor a
target for the patch.
>
> Has Jeff Urlwin disappeared from the Perl world?
That's a *very* good question. Perhaps Tim Bunce knows more? If Jeff has
gone, someone should take over DBD::ODBC development, and if not for
Unicode support, then at least for the new DBI features added during the
past three years.

Alexander

--
Alexander Foken
mailto:alexander@foken.de http://www.foken.de/alexander/

Re: next version of DBD::ODBC including available unicode patch?

I'm impressed how fast things are developing right now - WOW!

Martin Evans wrote:
> On the point of the Alexander's unicode patch I seem to remember
> applying it over a year a go to my copy of DBD::ODBC but it broke
> building of DBD::ODBC on UNIX - perhaps my recollection is wrong.
>
I would expect my patch to break compiling on every platform except
Win2K/WinXP, because I only tested it on those platforms.

I think my changes are quite Window specific, especially the calls to
the Unicode converter routines WideCharToMultiByte() and
MultiByteToWideChar(). wchar.h, wcslen() and wcscpy() are in the Single
UNIX Specification, Version 2, dated 1997. WCHAR should be equivalent to
wchar_t of the Single UNIX Specification, a #define or typedef should be
sufficient, like Microsoft does in wchar.h. See also
.
With a litte bit more knowlegde of the inner workings of Perl's Unicode
support, it should be possible to replace the two converter routines
called by my patch with Perl build-in routines. When that has happened,
the code should work on platforms implementing the Single UNIX
Specification Version 2, assuming the ODBC system wants Unicode in
UTF-16 like Windows does. If the ODBC system expects UTF-8, the calls to
the two converter functions should be called only on Win32.

Hope that helps,
Alexander

--
Alexander Foken
mailto:alexander@foken.de http://www.foken.de/alexander/