Re: DBD-Oracle on AIX
On 9/14/2010 12:41 AM, John R Pierce wrote: On 05/18/10 9:41 AM, Charles Jardine wrote: On 17/05/10 23:05, John R Pierce wrote: I've built DBD-Oracle-1.24 along with Perl 5.12.0 and DBI-1.611 for IBM AIX 6.1 TL05 (oslevel = 6100-05-01), with Oracle 10.2.0.4, using IBM XL C v11.1 + the latest PTF. to build DBD-Oracle, i had to hack the makefile slightly to remove a bogus -q32 from the LD commands, this per the README.aix.txt notes, otherwise my build is pretty much bog stock. Since I used cc_r to compile perl (per the Perl readmes for AIX) I also used this variant of the compiler for DBD-Oracle... Its failing just one test t/58object.t ... make test output is below... I don't know how to resolve this. The description of ORA-24334 is darn cryptic. There are problems with the support for objects on big endian platforms. http://www.mail-archive.com/dbi-users@perl.org/msg32902.html is a previous report for Sparc Solaris. The patches in the mail archive are mangled, much like your test output. I have attached two patches from that thread. I expect that sparc_patch will fix your immediate problem, allowing t/58object.t to get further, and report another test failure. sparc_patch2 may fix this second problem. I would like to know either way. I have no big endian hardware on which to test these patches. Did this ever get tested and entered into the DBD-Oracle release ? This issue has surfaced at work, so I can probably try testing your patches some time in the next week or so, possibly on both sparc and aix/power platforms, but if someone else has already done this and I missed it, I'd as soon not duplicate the effort To which issue are you referring the hack to the make file or the problem with t/58object.t? cheers John
Re: DBD-Oracle on AIX
On 09/14/10 5:35 AM, John Scoles wrote: Did this ever get tested and entered into the DBD-Oracle release ? This issue has surfaced at work, so I can probably try testing your patches some time in the next week or so, possibly on both sparc and aix/power platforms, but if someone else has already done this and I missed it, I'd as soon not duplicate the effort To which issue are you referring the hack to the make file or the problem with t/58object.t? Sorry, I meant, the make test problems with t/58object on big endian machines like Sparc, IBM Power
Re: DBD-Oracle on AIX
On 9/14/2010 9:17 AM, John R Pierce wrote: On 09/14/10 5:35 AM, John Scoles wrote: Did this ever get tested and entered into the DBD-Oracle release ? This issue has surfaced at work, so I can probably try testing your patches some time in the next week or so, possibly on both sparc and aix/power platforms, but if someone else has already done this and I missed it, I'd as soon not duplicate the effort To which issue are you referring the hack to the make file or the problem with t/58object.t? Sorry, I meant, the make test problems with t/58object on big endian machines like Sparc, IBM Power Ok that clears it up a little. I am not sure if it was fixed yet. Give the latest trunk version a try and see what happens. Just a side note if you are not using VARRY, TABLE or OBJECT in your tables you can ignore this failure as you will never hit it. Cheers John Scoles
Re: DBD-Oracle on AIX
On 09/14/10 6:58 AM, John Scoles wrote: On 9/14/2010 9:17 AM, John R Pierce wrote: Sorry, I meant, the make test problems with t/58object on big endian machines like Sparc, IBM Power Ok that clears it up a little. I am not sure if it was fixed yet. Give the latest trunk version a try and see what happens. Just a side note if you are not using VARRY, TABLE or OBJECT in your tables you can ignore this failure as you will never hit it. yup, aware thats the case, and yes, we've been ignoring the failure as the perl programs in question are truly ancient and wouldn't know what these things are if they bit them :) I'll try and find the time to get around to building this again from trunk and seeing whether or not it recurs.
DBD::OCBC support for XML datatype in SQL Server 2005
I'm facing encoding issues in trying to make use of the XML datatype in
SQL Server 2005, which I'm accessing using DBD::ODBC 1.23 and Perl 5.12.
CREATE TABLE T2 (a VARCHAR(99), u NVARCHAR(99), x XML);
Three columns here, a for single-byte characters, u for Unicode, and
x for XML.
The following statements works correctly in SSMS (SS Management Studio):
INSERT INTO T2 VALUES ('Käse', N'Käse', CAST( 'dKäse/d' AS XML));
KäseKäsedKäse/d
Now German wasn't too difficult, so let's try some Russian.
INSERT INTO T2 VALUES
('Москва', N'Москва', CAST('rМосква/r' AS XML));
INSERT INTO T2 VALUES
('Москва', N'Москва', CAST(N'rМосква/r' AS XML));
?? Москва r??/r
?? Москва rМосква/r
We need the N introducer for Unicode literals and a column type capable
of receiving Unicode data. Failing any of those two, we're getting just
a series of substitution characters (?).
How can we handle this situation from Perl? Here's a script.
\,,,/
(o o)
--oOOo-(_)-oOOo--
use strict;
use warnings; no warnings 'uninitialized';
use utf8;
use DBI;
my $txt_de = 'Käse';
my $txt_ru = 'Москва';
binmode STDOUT, ':utf8';
my @dsn = qw/DBI:ODBC:MY_DB my_username my_password/;
my %opt = (PrintError = 0, RaiseError = 1, AutoCommit = 1);
my $dbh = DBI-connect( @dsn, \%opt );
$dbh-{LongReadLen} = 4000;
$dbh-{LongTruncOk} = 1; # Dies muß, ob logisch oder nicht.
my $sth_ins = $dbh-prepare(
'INSERT INTO T2 (a, u, x) VALUES (?, ?, CAST( ? AS XML) )' );
$sth_ins-execute( $txt_de, $txt_de, d$txt_de/d );
$sth_ins-execute( $txt_ru, $txt_ru, r$txt_ru/r );
my $sth_sel = $dbh-prepare( 'SELECT u, x FROM T2' );
$sth_sel-execute;
$sth_sel-bind_columns( \my( $txt, $xml ) );
my $i = 0;
while ( $sth_sel-fetch ) {
printf %3u %3u [%s] [%s]\n, ++$i, length($txt), $txt, $xml;
}
$dbh-disconnect;
-
The problem is the INSERT statement, more specifically, in the XML part.
I can't seem to get it to accept my Unicode strings as Unicode for that
column. Instead, they're treated as octets, resulting in garbage.
Käse KäsedKäse/d
МоÑква Москва rМоÑква/r
I've tried to use an N introducer with the XML column, but that leads to
errors.
CAST( N? AS XML) - Invalid column name 'n...@p3'. (SQL-42S22)
CAST( N ? AS XML) - Incorrect syntax near '@P3'. (SQL-42000)
I'd appreciate your advice.
--
Michael Ludwig
Re: Strange Error
Jerry, Hi there - I'm the maintainer of DBD::mysql The verbiage going to your log looks like what you would see if you set the DBI trace level to 2 or greater. I've double-checked my code and any debug I print is indeed only occurring in a block where if trace is set to 2 or greater it would show up. I wonder if CGI::Application might set trace? Or what about any sort of Apache/mod_perl startup scripts that might set it - have you checked those? --Patrick Jerry Kaidor wrote: Hello, My name is Jerry Kaidor. I am seeing some cryptic errors in a web application that I'm writing. Driving me nuts. My code runs under CGI::Application, and uses DBI with the mysql driver. Here is the error message, which appears in /var/log/httpd/error_log: - snip [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] SV = RV(0x8c6212c) at 0x8c62120 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] REFCNT = 1 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] FLAGS = (ROK,READONLY) [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] RV = 0x8c61ef0 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] SV = [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] PVHV(0x8c57b84) at 0x8c61ef0 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] REFCNT = 1 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] FLAGS = (OBJECT,OOK,SHAREKEYS) [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] STASH = 0x8700430 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] \tDBI::db [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] ARRAY = 0x8c66878 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] KEYS = 0 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] FILL = 0 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] MAX = 7 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] RITER = -1 [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] [Fri Sep 03 07:11:35 2010] [error] [client 10.120.102.6] EITER = 0x0 endsnip The Linux system is based on Slackware 13.0. I have upgraded to the latest DBI and DBD::mysql via CPAN. The Linux kernel is 2.6.29.6-smp. Perl is v5.10.0 built for i486-linux-thread-multi. The mysql server is 5.0.84. The webserver is Apache 2.2.13. I have done a fair amount of googling on this, no joy, except that the error messages seem to be about some kind of Perl internals distress. I also asked the CGI::Application mailing list - they know nothing. One person suspected the DBD driver because it uses C code interfaced to Perl via XS. Anybody have a clue? BTW, the application seems to work fine. I'm just seeing this error in the httpd error log. Thanks in advance, - Jerry Kaidor ( je...@tr2.com )
