On Nov 9, 2007 4:47 AM, Charles Jardine <[EMAIL PROTECTED]> wrote:
> On 07/11/07 17:38, E R wrote:
> > Hi,
> >
> > I just posted this question on Perl Monks:
> >
> > http://perlmonks.com/?node_id=649489
> >
> > Am I correct in my analysis of what's going?
>
> You might be interested in a thread which I started just over
> two years ago. See
>
> http://www.nntp.perl.org/group/perl.dbi.users/2005/08/msg27335.html
This is exactly the issue I am trying to raise. The only solution
seems to be to explicitly
encode all the strings in the encoding you want before passing them to
DBD::Oracle.
For example, instead of:
$sth = $dbi->prepare($sql);
$sth->execute(@values);
one would have to write something like:
$sth = $dbi->prepare(Encode::encode('iso-8859-1', $sql));
$sth->execute(map { Encode::encode('iso-8859-1', $_) } @values);
(Of course, there are more efficient ways to do this.)
Consequently, for those of us who are using only iso-8859-1 in our SQL
and in our database, it would be very useful to have an interface to
DBD::Oracle which performed this encoding automatically. An exception
could be thrown if a string containing a character > 255 were passed.
I could write such an interface in Perl, but I was wondering if the
same thing could be effected within DBD::Oracle through some
configuration settings.
> As you will see, the thread never reached a satisfactory conclusion.
I haven't read through the entire thread, but it seems that
DBD::Oracle has to be treated as what I call an "octet sequence
interface". That is, the caller is responsible for properly encoding
and decoding the results. At least this is what I have to do. Someday
it would be nice to have a true "text" interface that would
automatically negotiate all the character encoding issues along the
pipeline from Perl to the database.
> Sadly, I have not been able to find the time to work on anything
> DBI related since that posting.
Thanks for bringing this thread up - it's been very helpful!
