Just for an extra bit of FYI, the error only occurs when there's another
statement prepared right before the update, so DBD::Sybase has to create
another dbh because of the multiple active statement handles.
-- Sent from my Palm Pre
On Aug 9, 2011 6:40 AM, Michael Peppler <mpepp...@peppler.org> wrote:
There was a change in 1.11 (I think) to handle utf8/unicode data. THis
included forcing the charset to utf8 in the client.
You can go back to the old behavior if you edit dbdimp.c and change or
comment out the following:
if (retcode == CS_SUCCEED) {
if ((retcode = cs_locale(context, CS_SET, locale,
CS_SYB_CHARSET,
"utf8", CS_NULLTERM, NULL)) != CS_SUCCEED) {
warn("cs_locale(CS_SYB_CHARSET) failed");
}
}
in the syb_init() call.
I'll need to review that decision to see how to make it work for both
unicode and non-unicode data.
Michael
On Tue, Aug 9, 2011 at 2:58 AM, Douglas Wilson
<douglasg.wil...@gmail.com> wrote:
> I'm using perl 5.8.8 with DBD::Sybase 1.09, and the SQL statement
> below appears to prepare and execute fine, but I've also just compiled
> a perl 5.14.1 with DBD::Sybase 1.12, and with the newer versions I get
> the following error on prepare:
>
> DBD::Sybase::db prepare failed: Server message number=2401 severity=11
> state=2 line=0 server=TESTASE text=Character set conversion is not
> available between client character set 'utf8' and server character set
> 'iso_1'.
> Server message number=2411 severity=10 state=1 line=0 server=TESTASE
> text=No conversions will be done.
>
> If I add ';charset=iso_1' to the dsn string on connect, then
> everything seems to work ok. I'm just wondering what changed the
> behavior (perl? DBD::Sybase?), and if I've handled it correctly or
> done something else wrong...
>
> Thanks...
>
> my $upd_sql = <<SQL;
> UPDATE my_table
> SET
> group_nbr = ?, last_ch_user = user, last_ch_date = getdate()
> WHERE primary_id = ?
> AND source_id = 100
> SQL
>
