Re: Toubles Storing ASCII character greater than 127
From: George K. <karabot_at_gmail.com>
Date: Fri, 23 Apr 2010 08:04:05 -0700 (PDT)
Message-ID: <3af152e0-61cd-4f72-af34-4911a85e84ad_at_s22g2000vbb.googlegroups.com>
On Apr 21, 9:40 am, joel garry <joel-ga..._at_home.com> wrote:
> On Apr 21, 6:31 am, "George K." <kara..._at_gmail.com> wrote:
>
>
>
> > Thank you guys, I meant to write a response yesterday once I found the
> > solution but I was too tired :).
>
> > I found reading material about oracle's charsets and I run into all
> > the different NLS options. Armed with that I was able to determine
> > the connection options I have to setup in Perl in order to match the
> > client with the server.
>
> > Here are a few more details on the problem:
> > 1) I am reading from an Informix table containing zlib compressed data
> > stored in a lvarchar.
> > 2) I need to store them in a mirror image table without losing
> > integrity of the data because I can no longer un-compress them.
>
> > The solution was finding an appropriate charset that will not messup
> > the compressed data, I was only able to achive this with the
> > WE8ISO8859P9 charset and here's how I used it:
>
> > my $dbhOracle = DBI->connect('dbi:Oracle:'.$dbname,$user,$password,
> > {
> > 'RaiseError' => 0,
> > 'AutoCommit' => 0,
> > 'PrintError' => 0,
> > 'ora_charset'=> 'WE8ISO8859P9',
> > })
> > || Carp::croak(DBI->errstr);
>
> > Thank you again for your help, much appreciated.
>
> > George
>
> I'm not sure if this is an issue for you, but there's a possibility
> any time Oracle has to make a character conversion it may do so. I
> don't recall if there is a P9 to AL32UTF8 issue, but something is
> tickling the back of my brain that there are some obscure issues -
> maybe having to do with the Euro sign? I know I've seen docs about
> it, just can't remember the details. If you are relying on no
> translation or strict supersets to do what you want (ie, nothing) with
> binary data, you might have obscure intermittent problems. See the
> docs or google about the csscan utility, you can use it to see if your
> existing data is susceptible. But perhaps it isn't existing data you
> have to worry about. Maybe you can make a quick test of storing all
> characters and using the utility to see. If you are converting, you
> have to be careful that all tools do the same conversion - this is a
> classic issue with imp/exp.
>
> As far as why Informix can do something Oracle can't... my search for
> lvarchar at ansi.org yielded no results :-)
>
> jg
> --
> _at_home.com is bogus.http://www.twominutenews.com/2010/technology/apple-earnings-have-incr...
Date: Fri, 23 Apr 2010 08:04:05 -0700 (PDT)
Message-ID: <3af152e0-61cd-4f72-af34-4911a85e84ad_at_s22g2000vbb.googlegroups.com>
On Apr 21, 9:40 am, joel garry <joel-ga..._at_home.com> wrote:
> On Apr 21, 6:31 am, "George K." <kara..._at_gmail.com> wrote:
>
>
>
> > Thank you guys, I meant to write a response yesterday once I found the
> > solution but I was too tired :).
>
> > I found reading material about oracle's charsets and I run into all
> > the different NLS options. Armed with that I was able to determine
> > the connection options I have to setup in Perl in order to match the
> > client with the server.
>
> > Here are a few more details on the problem:
> > 1) I am reading from an Informix table containing zlib compressed data
> > stored in a lvarchar.
> > 2) I need to store them in a mirror image table without losing
> > integrity of the data because I can no longer un-compress them.
>
> > The solution was finding an appropriate charset that will not messup
> > the compressed data, I was only able to achive this with the
> > WE8ISO8859P9 charset and here's how I used it:
>
> > my $dbhOracle = DBI->connect('dbi:Oracle:'.$dbname,$user,$password,
> > {
> > 'RaiseError' => 0,
> > 'AutoCommit' => 0,
> > 'PrintError' => 0,
> > 'ora_charset'=> 'WE8ISO8859P9',
> > })
> > || Carp::croak(DBI->errstr);
>
> > Thank you again for your help, much appreciated.
>
> > George
>
> I'm not sure if this is an issue for you, but there's a possibility
> any time Oracle has to make a character conversion it may do so. I
> don't recall if there is a P9 to AL32UTF8 issue, but something is
> tickling the back of my brain that there are some obscure issues -
> maybe having to do with the Euro sign? I know I've seen docs about
> it, just can't remember the details. If you are relying on no
> translation or strict supersets to do what you want (ie, nothing) with
> binary data, you might have obscure intermittent problems. See the
> docs or google about the csscan utility, you can use it to see if your
> existing data is susceptible. But perhaps it isn't existing data you
> have to worry about. Maybe you can make a quick test of storing all
> characters and using the utility to see. If you are converting, you
> have to be careful that all tools do the same conversion - this is a
> classic issue with imp/exp.
>
> As far as why Informix can do something Oracle can't... my search for
> lvarchar at ansi.org yielded no results :-)
>
> jg
> --
> _at_home.com is bogus.http://www.twominutenews.com/2010/technology/apple-earnings-have-incr...
Thanks for the insights and the warning :).
I have actually created such a program, write all characters 0-256 and
retrieve them with no loss of information.
Many thanks again for the responses :).
George
Received on Fri Apr 23 2010 - 10:04:05 CDT