On Thu, 3 Jun 2010, Michael Peppler wrote:
Which version of Sybase, which version of Sybase OpenClient, and which version
of DBD::Sybase?
Ah, I was using the old libs (11.0), which may have been the problem. I
was also using DBD::Sybase 1.07.
I switch to Sybase 15.0 (OCS 15.0 if that makes sense), OpenClient 15.0
libs, and DBD::Sybase 1.10.
Now it's closer to working. If I set "charset=utf8" in the dsn, I get
2010/06/03 14:08:11 unicode CRITICAL: FATAL: DBD::Sybase::db do failed: Server
message number=2402 severity=16 state=1 line=1 server=HDATADEV1 text=Error
converting characters into server's character set. Some character(s) could not
be converted.
I'm not sure what that means.
If I _don't_ set that, the data goes in and comes out as bytes, rather
than the bizarro hex string. However, the data does have the utf8 flag set
when it comes back from Sybase, so I have to run it through
Encode::decode.
I really don't think I can realistically tell the bazillion developers
here "just run all the data through Encode".
I'd really like see an end-to-end solution.
Also, it's not clear to me that the data is actually being stored as
characters at the Sybase level. I'm not even sure how I'd figure this out.
When I do a select from sqsh, I see the wacky hex string, but I can't tell
if that's Sybase trying to present data to me in a format it thinks my
environment can handle.
I did try setting LC_ALL=us_english.utf8 when running sqsh, but that
didn't make a difference.
Basically, what I need is to be able to take Perl native unicode strings,
store them in Sybase in Sybase's native format (utf16, I believe), and
then retrieve them as Perl native unicode strings again.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
