Re: db2 - persistent connection

[Jack Faley ( The Tao of Jack )]

On 9/4/06, Darin McBride <[EMAIL PROTECTED]> wrote:


On Saturday 02 September 2006 00:21, Jack Faley ( The Tao of Jack ) wrote:
> I have several ( 100 - 200 ) small exits c oming from an app that update
> db2 tables. This works fine but the dba's don't like that many open
> connection overheads. This isn't cgi/apache. These are all seperate
> terminating processes. From what I gather there is no way to pass the
dbh
> between processes?

No.

> Is some sort of middle daemon ( I guess non perl ) that
> keeps one persistent connection to db2 and then have perl feed the
daemon
> the only option?

That would be called ... "DB2" ;-)

> I would think others have run into this wall before?

Option 1: stop during this in a bunch of small exits - put them in a
single
exit.  Probably not a real option.

Option 2: can you put this in stored procedures instead?

Option 3: DBD::Proxy may help here.  Or at least the concept - set up a
POE-based pseudo-server which receives messages from apps, and funnels
them
via a single connection to your server, then passes the results
back.  That
sounds like not only a lot of work to write, but also a lot of work for
the
computer.  Oh, and all those connections just moved from going directly to
the server to directly to the proxy/concentrator - I'm not really seeing a
savings there.

To be honest, I suspect that any option (other than a complete
re-architecture
of how you approach the business problem you're dealing with in these
exits)
will actually be a larger load on the system than what you're currently
working with.

If option 1 works (which I doubt from what little info was in your
original
question), I think it's probably the only solution that would satisfy your
DBAs.  But then again, I'm not seeing their problem, nor really what is
causing it, so I'm just taking a wild guess ;-)





Thank you for your reply. If their was any way to mitigate the small exits I
would do it but I'm modifying an app that was never meant to be extensible.
So, you are correct, Im moving the load to a daemon in the middle with a
persistant connection rather than directly talking to DB2 :-) . I havent
benchmarked it. Im no dba but I have a feeling this will actually be slower
overall.

I am holding hope DBD:Proxy connect_cached might do the trick but the docs
seem to indicate its not fully completed. No harm in trying though. Even if
it doesnt, I'll check the dba's quality to see if they can tell if there are
still all those connections after a "middleware" to pool them that actually
doesn't do anything.

How would Stored Procedures help? Just for the performance after connected?

Thanks!

--

Why is this technology an anathema to me?

Re: db2 - persistent connection

[Darin McBride]

On Saturday 02 September 2006 00:21, Jack Faley ( The Tao of Jack ) wrote:
> I have several ( 100 - 200 ) small exits c oming from an app that update
> db2 tables. This works fine but the dba's don't like that many open
> connection overheads. This isn't cgi/apache. These are all seperate
> terminating processes. From what I gather there is no way to pass the dbh
> between processes?

No.

> Is some sort of middle daemon ( I guess non perl ) that 
> keeps one persistent connection to db2 and then have perl feed the daemon
> the only option?

That would be called ... "DB2" ;-)

> I would think others have run into this wall before? 

Option 1: stop during this in a bunch of small exits - put them in a single 
exit.  Probably not a real option.

Option 2: can you put this in stored procedures instead?

Option 3: DBD::Proxy may help here.  Or at least the concept - set up a 
POE-based pseudo-server which receives messages from apps, and funnels them 
via a single connection to your server, then passes the results back.  That 
sounds like not only a lot of work to write, but also a lot of work for the 
computer.  Oh, and all those connections just moved from going directly to 
the server to directly to the proxy/concentrator - I'm not really seeing a 
savings there.

To be honest, I suspect that any option (other than a complete re-architecture 
of how you approach the business problem you're dealing with in these exits) 
will actually be a larger load on the system than what you're currently 
working with.

If option 1 works (which I doubt from what little info was in your original 
question), I think it's probably the only solution that would satisfy your 
DBAs.  But then again, I'm not seeing their problem, nor really what is 
causing it, so I'm just taking a wild guess ;-)

Re: DBI install error

[Jonathan Leffler]

On 9/4/06, Ouyang, Jian <[EMAIL PROTECTED]> wrote:

I try to install the DBI package but it failed. Can you please help?


John Gallagher was having the same problem.  I answered him this morning.



{/home/j/jouyang/dot/DBI-1.50 27}% perl Makefile.PL
[...]
Writing Makefile for DBI


{/home/j/jouyang/dot/DBI-1.50 29}% make
cc -c-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae
-D_HPUX_SOURCE -Wl,+vnocompatwarnings -DNO_HASH_SEED -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fast +Onolimit +Opromote_indirect_calls
+DAportable +DS2.0-DVERSION=\"1.50\"  -DXS_VERSION=\"1.50\" +Z
"-I/opt/perl/lib/5.8.3/PA-RISC1.1-thread-multi/CORE"   Perl.c
(Bundled) cc: warning 480: The -A option is available only with the
C/ANSI C product; ignored.
(Bundled) cc: warning 422: Unknown option "f" ignored.
(Bundled) cc: warning 480: The +Onolimit option is available only with
the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Opromote_indirect_calls option is
available only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Z option is available only with the
C/ANSI C product; ignored.
cpp: "/opt/perl/lib/5.8.3/PA-RISC1.1-thread-multi/CORE/perlio.h", line
108: error 4065: Recursion in macro "PerlIO".
*** Error exit code 1



I wrote:

You're using the bundled C compiler which is not an ANSI C compiler.
Your Perl was built with the HP ANSI C compiler.

Either: get the HP ANSI C compiler
Or: get GCC and build your own Perl with it.


His Perl was version 5.8.7; yours is 5.8.3; the differences are
immaterial to this problem.

--
Jonathan Leffler <[EMAIL PROTECTED]>  #include 
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."

DBI install error

[Ouyang, Jian]

Hi,
 
I try to install the DBI package but it failed. Can you please help?
 
Thanks.
 
Jian
 
 
 
 
 
{/home/j/jouyang/dot/DBI-1.50 27}% perl Makefile.PL
 
*** You are using a perl configured with threading enabled.
*** You should be aware that using multiple threads is
*** not recommended for production environments.
 
*** Note:
The optional PlRPC-modules (RPC::PlServer etc) are not installed.
If you want to use the DBD::Proxy driver and DBI::ProxyServer
modules, then you'll need to install the RPC::PlServer,
RPC::PlClient,
Storable and Net::Daemon modules. The CPAN Bundle::DBI may help you.
You can install them any time after installing the DBI.
You do *not* need these modules for typical DBI usage.
 
Optional modules are available from any CPAN mirror, in particular
http://search.cpan.org/
http://www.perl.com/CPAN/modules/by-module
http://www.perl.org/CPAN/modules/by-module
ftp://ftp.funet.fi/pub/languages/perl/CPAN/modules/by-module
 
Creating DBI::PurePerltest variant: t/zvpp_01basics.t 
Creating DBI::PurePerltest variant: t/zvpp_02dbidrv.t 
Creating DBI::PurePerltest variant: t/zvpp_03handle.t 
Creating DBI::PurePerltest variant: t/zvpp_04mods.t 
Creating DBI::PurePerltest variant: t/zvpp_05thrclone.t (use
threads)
Creating DBI::PurePerltest variant: t/zvpp_06attrs.t 
Creating DBI::PurePerltest variant: t/zvpp_07kids.t 
Creating DBI::PurePerltest variant: t/zvpp_08keeperr.t 
Creating DBI::PurePerltest variant: t/zvpp_09trace.t 
Creating DBI::PurePerltest variant: t/zvpp_10examp.t 
Creating DBI::PurePerltest variant: t/zvpp_11fetch.t 
Creating DBI::PurePerltest variant: t/zvpp_14utf8.t 
Creating DBI::PurePerltest variant: t/zvpp_15array.t 
Creating DBI::PurePerltest variant: t/zvpp_20meta.t 
Creating DBI::PurePerltest variant: t/zvpp_30subclass.t 
Creating DBI::PurePerltest variant: t/zvpp_40profile.t 
Creating DBI::PurePerltest variant: t/zvpp_41prof_dump.t 
Creating DBI::PurePerltest variant: t/zvpp_42prof_data.t 
Creating DBI::PurePerltest variant: t/zvpp_43profenv.t 
Creating DBI::PurePerltest variant: t/zvpp_50dbm.t 
Creating DBI::PurePerltest variant: t/zvpp_60preparse.t 
Creating DBI::PurePerltest variant: t/zvpp_70callbacks.t 
Creating DBI::PurePerltest variant: t/zvpp_72childhandles.t 
Creating DBI::PurePerltest variant: t/zvpp_80proxy.t 
 
I see you're using perl 5.008003 on PA-RISC1.1-thread-multi, okay.
Remember to actually *read* the README file!
Use  'make' to build the software (dmake or nmake on Windows).
Then 'make test' to execute self tests.
Then 'make install' to install the DBI and then delete this working
directory before unpacking and building any DBD::* drivers.
 
Writing Makefile for DBI

 
{/home/j/jouyang/dot/DBI-1.50 29}% make
cc -c-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae
-D_HPUX_SOURCE -Wl,+vnocompatwarnings -DNO_HASH_SEED -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fast +Onolimit +Opromote_indirect_calls
+DAportable +DS2.0-DVERSION=\"1.50\"  -DXS_VERSION=\"1.50\" +Z
"-I/opt/perl/lib/5.8.3/PA-RISC1.1-thread-multi/CORE"   Perl.c
(Bundled) cc: warning 480: The -A option is available only with the
C/ANSI C product; ignored.
(Bundled) cc: warning 422: Unknown option "f" ignored.
(Bundled) cc: warning 480: The +Onolimit option is available only with
the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Opromote_indirect_calls option is
available only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Z option is available only with the
C/ANSI C product; ignored.
cpp: "/opt/perl/lib/5.8.3/PA-RISC1.1-thread-multi/CORE/perlio.h", line
108: error 4065: Recursion in macro "PerlIO".
*** Error exit code 1
 
 
{/home/j/jouyang/dot/DBI-1.50 30}% make test
cc -c-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae
-D_HPUX_SOURCE -Wl,+vnocompatwarnings -DNO_HASH_SEED -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -fast +Onolimit +Opromote_indirect_calls
+DAportable +DS2.0-DVERSION=\"1.50\"  -DXS_VERSION=\"1.50\" +Z
"-I/opt/perl/lib/5.8.3/PA-RISC1.1-thread-multi/CORE"   Perl.c
(Bundled) cc: warning 480: The -A option is available only with the
C/ANSI C product; ignored.
(Bundled) cc: warning 422: Unknown option "f" ignored.
(Bundled) cc: warning 480: The +Onolimit option is available only with
the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Opromote_indirect_calls option is
available only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Z option is available only with the
C/ANSI C product; ignored.
cpp: "/opt/perl/lib/5.8.3/PA-RISC1.1-thread-multi/CORE/perlio.h", line
108: error 4065: Recursion in macro "PerlIO".
*** Error exit code 1
 
 
 
{/home/j/jouyang/dot/DBI-1.50 31}% make test TEST_VERBOSE=1
cc -c-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae
-D_HPUX_SOURCE -Wl,+vnocompatwarnings -DNO_HASH_SEED -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -f

Re: code needed

[Scott T. Hildreth]

Since this is not a dbi problem, can DBI-Users be taken off the cc list.


On Mon, 2006-09-04 at 08:07 -0400, Eric Krause wrote:

> Check out this web page, 
> http://www.developer.com/lang/other/article.php/3454041. It has examples 
> that  return link and tags using WWW::Mechanize, which is a subset of LWP.
> 
> -Eric
> 
> Hal Wigoda wrote:
> > anyone have any code that will return the links and tags from web 
> > document
> > downloaded using LWP?
> >
> > hal
> > chicago
> >
> > --To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >  
> >
> >
> >

-- 
Scott T. Hildreth <[EMAIL PROTECTED]>

execute_array/execute_for_fetch (was: ANNOUNCE: Advanced DBI Tutorial Slides)

[Tim Bunce]

On Mon, Sep 04, 2006 at 05:21:17PM +0100, Martin J. Evans wrote:
> 
> It did raise an issue where I could do with some clarification. The slides 
> say:
> 
>  Execute a statement for multiple values
>$sth = $dbh->prepare("insert into table (foo,bar) values (?,?)");
>$tuples = $sth->execute_array(\%attr, [EMAIL PROTECTED], [EMAIL 
> PROTECTED]);
> 
>  returns count of executions (even ones that failed) and not rows-affected.
> 
> but the latest DBI pod says:
> 
>  The execute_array() method returns the number of tuples executed,
>  or "undef" if an error occured. Like execute(), a successful exe-
>  cute_array() always returns true regardless of the number of tuples
>  executed, even if it's zero.  See the "ArrayTupleStatus" attribute
>  below for how to determine the execution status for each tuple.
> 
> I read that latter as if undef is returned 1 or more of the executes failed 
> but
> now I read in the slides they suggest I may get a true value when an error
> occurs. My experience with execute_array and Oracle shows I get:
> 
> return 0, when none resulted in a change but no errors
>   e.g.
>   drop table mytest
>   create table mytest (a int primary key, b char(20))
>   insert into mytest values (1,'onetwothree')
>   update mytest set b = ? where a = ?
> $sth->bind_param_array(2, [2])
> $sth->bind_param_array(1, ['two'])
>   $sth->execute_array( { ArrayTupleStatus => [EMAIL PROTECTED] } )
> 
>   returns 0
> 
>   No, error, just no update occurred. It does not return 1 as the slide
>   suggests and does seem to be the number of rows changed - none.
> 
> returns undef when there is an error
>   e.g.
>   as per above example but the bind_param_array for p2 is invalid e.g. 'xxx'
> 
>   This seems to also contradict the slide but agrees with the DBI pod.
> 
> lastly I get undef if there are multiple rows but the last one errors.
> e.g. as above except the bind_param_arrays are:
> 
>  $sth->bind_param_array(2, [1, 'xxx']);
>  $sth->bind_param_array(1, ['one', 'two']);
> 
>  returns undef but executes the 1,'one'.
> 
> I am now unclear as to what is correct. Can you clarify?

The pod is right and both the slides and DBD::Oracle are wrong,
though in different ways.

The behaviour should match that of the default execute_for_fetch
method (which execute_array calls) provided by the DBI - shown below.

Thanks! I've fixed my copy of the slide to say "returns count of
executions, not rows-affected, or undef if any failed".

Tim.

p.s. I'd be grateful if you could file a bug at rt.cpan.org for DBD::Oracle.


sub execute_for_fetch {
my ($sth, $fetch_tuple_sub, $tuple_status) = @_;
# start with empty status array
($tuple_status) ? @$tuple_status = () : $tuple_status = [];

my ($err_count, %errstr_cache);
while ( my $tuple = &$fetch_tuple_sub() ) {
if ( my $rc = $sth->execute(@$tuple) ) {
push @$tuple_status, $rc;
}
else {
$err_count++;
my $err = $sth->err;
push @$tuple_status, [ $err, $errstr_cache{$err} ||= 
$sth->errstr, $sth->state ];
}
}
my $tuples = @$tuple_status;
return $sth->set_err(1, "executing $tuples generated $err_count errors")
if $err_count;
return scalar(@$tuple_status) || "0E0";
}

Re: Encoding

[Martin J. Evans]

On Mon, 2006-09-04 at 14:13 -0400, Daniel Zeman wrote:
> Martin J. Evans napsal(a):
>  > On 31-Aug-2006 Daniel Zeman wrote:
>  >> Hi,
>  >> I wonder if anyone can help me.
>  >>
>  >> I am using
>  >> - Debian Linux
>  >> - Perl 5.8.8
>  >> - DBI (I do not know how to figure out its version)
>  >
>  > perl -MDBI -e 'print "$DBI::VERSION\n";'
> 
> 1.51
> 
>  >
>  >> - MySQL 5.0.22-Debian_3-log
>  >
>  > What DBD::mysql version are you using?
>  >
>  > perl -M'DBD::mysql' -e 'print "$DBD::mysql::VERSION\n";'
> 
> 3.0004
> 
>  >
>  >> I want to store and handle data in UTF-8 but so far I have not been 
> able
>  >> to force Perl/DBI to do so.
>  >>
>  >> I have created a table using
>  >>
>  >>  my $sql = "CREATE TABLE $tbl (".join(", ", @columns).") CHARACTER
>  >> SET utf8 COLLATE utf8_czech_ci;";
>  >>  $dbh->do($sql);
>  >>
>  >> I feeded the table with data using
>  >>
>  >>  my $list_of_columns = join(", ", @names);
>  >>  my $list_of_values = join(", ", 
> map{"_utf8'$record->{$_}'"}(@names));
>  >>  my $sql = "INSERT INTO $tbl ($list_of_columns) VALUES
>  >> ($list_of_values);";
>  >>  $dbh->do($sql);
>  >
>  > You would be better using bound parameters as then only the data can 
> be utf-8.
>  >
>  >> I have looked into the database using phpMyAdmin 2.8.2-Debian-0.1 
> and it
>  >> really looked like the data were stored in correct UTF-8.
>  >>
>  >> However, when I retrieve the data from Perl/DBI, something in the chain
>  >> (MySQL? the driver? DBI?) decides that another encoding (probably,
>  >> Latin1) would be better for me. It "converts" the strings from UTF-8 to
>  >> that encoding, which means, at the time the data arrives in my Perl
>  >> code, all the non-Latin1 characters have already been irrecoverably
>  >> converted to question marks. I would be happy to decode the data myself
>  >> but there is nothing I can do with the question marks.
>  >>
>  >> I am using the following code to retrieve the data:
>  >>
>  >>  my $sql = "SELECT kod, hry.nazev FROM hry INNER JOIN prodej ON
>  >> hry.kod = prodej.kod_hry GROUP BY kod, hry.nazev";
>  >>  my $sqlobj = $dbh->prepare($sql);
>  >>  $sqlobj->execute();
>  >>  while(my ($kod, $nazev) = $sqlobj->fetchrow_array())
>  >>  {
>  >>  ...
>  >>  }
>  >>
>  >> So far, the only workaround I have, is not to tell the DBI the data is
>  >> UTF-8 when I am inserting it (i.e., drop the "_utf8" part before the
>  >> single quote), and use Encode; decode("utf8", ...) on anything I fetch
>  >> from the database. This way, the database never knows the data was a
>  >> UTF-8 text, treats the bytes as Latin1 characters and returns them
>  >> undisturbed. However, I cannot access the data using phpMyAdmin (unless
>  >> I en/decode UTF in my brain), the string lengths do not reflect the
>  >> reality etc.
>  >>
>  >> Is there a better way to do it? I think there must be some small stupid
>  >> locale-like setting telling the machine that I am a UTF guy. But the
>  >> settings I was able to come up with did not help and I actually have no
>  >> idea which part of the MySQL-driver-DBI-Perl chain is responsible.
>  >>
>  >> Any hints are welcome.
>  >> Thanks
>  >>
>  >> Dan
>  >
>  > I posted a small patch (in dbi-dev a couple of months ago) to a 
> recent(ish)
>  > DBD::mysql which allows you to retrieve utf-8 data marked as utf-8 in 
> perl. If
>  > is not a complete solution but works for most things.
>  >
>  > See
>  > http://www.nntp.perl.org/group/perl.dbi.dev/4548
>  >
>  > It may have been included in the 3.0006_1 development release of 
> DBD::mysql.
>  >
>  > You also need to look up "set character set utf8" and "set names 
> utf8" in mysql
>  > documentation.
> 
> This is it! Thanks a lot! Just doing
> 
> $dbh->prepare("SET NAMES 'utf8'")->execute();
> 
> after connecting solved my problem. It seems that I am getting the 
> strings with the utf8 flag on so hopefully I can live without your patch 
>   (or someone has already patched the system I am on) - but I am going 
> to store the link for future reference. Thanks!
> 
> Dan
> 
> 
Glad to hear this sorted it. On reflection the patch I supplied was
against DBD::mysql 3.0003_1 so this might explain it.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

Re: Encoding

[Daniel Zeman]

Martin J. Evans napsal(a):
> On 31-Aug-2006 Daniel Zeman wrote:
>> Hi,
>> I wonder if anyone can help me.
>>
>> I am using
>> - Debian Linux
>> - Perl 5.8.8
>> - DBI (I do not know how to figure out its version)
>
> perl -MDBI -e 'print "$DBI::VERSION\n";'

1.51

>
>> - MySQL 5.0.22-Debian_3-log
>
> What DBD::mysql version are you using?
>
> perl -M'DBD::mysql' -e 'print "$DBD::mysql::VERSION\n";'

3.0004

>
>> I want to store and handle data in UTF-8 but so far I have not been 
able

>> to force Perl/DBI to do so.
>>
>> I have created a table using
>>
>>  my $sql = "CREATE TABLE $tbl (".join(", ", @columns).") CHARACTER
>> SET utf8 COLLATE utf8_czech_ci;";
>>  $dbh->do($sql);
>>
>> I feeded the table with data using
>>
>>  my $list_of_columns = join(", ", @names);
>>  my $list_of_values = join(", ", 
map{"_utf8'$record->{$_}'"}(@names));

>>  my $sql = "INSERT INTO $tbl ($list_of_columns) VALUES
>> ($list_of_values);";
>>  $dbh->do($sql);
>
> You would be better using bound parameters as then only the data can 
be utf-8.

>
>> I have looked into the database using phpMyAdmin 2.8.2-Debian-0.1 
and it

>> really looked like the data were stored in correct UTF-8.
>>
>> However, when I retrieve the data from Perl/DBI, something in the chain
>> (MySQL? the driver? DBI?) decides that another encoding (probably,
>> Latin1) would be better for me. It "converts" the strings from UTF-8 to
>> that encoding, which means, at the time the data arrives in my Perl
>> code, all the non-Latin1 characters have already been irrecoverably
>> converted to question marks. I would be happy to decode the data myself
>> but there is nothing I can do with the question marks.
>>
>> I am using the following code to retrieve the data:
>>
>>  my $sql = "SELECT kod, hry.nazev FROM hry INNER JOIN prodej ON
>> hry.kod = prodej.kod_hry GROUP BY kod, hry.nazev";
>>  my $sqlobj = $dbh->prepare($sql);
>>  $sqlobj->execute();
>>  while(my ($kod, $nazev) = $sqlobj->fetchrow_array())
>>  {
>>  ...
>>  }
>>
>> So far, the only workaround I have, is not to tell the DBI the data is
>> UTF-8 when I am inserting it (i.e., drop the "_utf8" part before the
>> single quote), and use Encode; decode("utf8", ...) on anything I fetch
>> from the database. This way, the database never knows the data was a
>> UTF-8 text, treats the bytes as Latin1 characters and returns them
>> undisturbed. However, I cannot access the data using phpMyAdmin (unless
>> I en/decode UTF in my brain), the string lengths do not reflect the
>> reality etc.
>>
>> Is there a better way to do it? I think there must be some small stupid
>> locale-like setting telling the machine that I am a UTF guy. But the
>> settings I was able to come up with did not help and I actually have no
>> idea which part of the MySQL-driver-DBI-Perl chain is responsible.
>>
>> Any hints are welcome.
>> Thanks
>>
>> Dan
>
> I posted a small patch (in dbi-dev a couple of months ago) to a 
recent(ish)
> DBD::mysql which allows you to retrieve utf-8 data marked as utf-8 in 
perl. If

> is not a complete solution but works for most things.
>
> See
> http://www.nntp.perl.org/group/perl.dbi.dev/4548
>
> It may have been included in the 3.0006_1 development release of 
DBD::mysql.

>
> You also need to look up "set character set utf8" and "set names 
utf8" in mysql

> documentation.

This is it! Thanks a lot! Just doing

$dbh->prepare("SET NAMES 'utf8'")->execute();

after connecting solved my problem. It seems that I am getting the 
strings with the utf8 flag on so hopefully I can live without your patch 
 (or someone has already patched the system I am on) - but I am going 
to store the link for future reference. Thanks!


Dan

RE: ANNOUNCE: Advanced DBI Tutorial Slides

[Martin J. Evans]

On 04-Sep-2006 Tim Bunce wrote:
>   file: $CPAN/authors/id/T/TI/TIMB/DBI_AdvancedTalk_200608.pdf
>   size: 486540 bytes
>md5: c305fe9ae393a534f17efc83a4563d28
> 
> Slides for this years version of my Advanced DBI tutorial are available
> online.
> 
> Tim.

Thanks for that - very interesting I certainly noted a couple of things I
wasn't always doing.

It did raise an issue where I could do with some clarification. The slides say:

 Execute a statement for multiple values
   $sth = $dbh->prepare("insert into table (foo,bar) values (?,?)");
   $tuples = $sth->execute_array(\%attr, [EMAIL PROTECTED], [EMAIL PROTECTED]);

 returns count of executions (even ones that failed) and not rows-affected.

but the latest DBI pod says:

 The execute_array() method returns the number of tuples executed,
 or "undef" if an error occured. Like execute(), a successful exe-
 cute_array() always returns true regardless of the number of tuples
 executed, even if it's zero.  See the "ArrayTupleStatus" attribute
 below for how to determine the execution status for each tuple.

I read that latter as if undef is returned 1 or more of the executes failed but
now I read in the slides they suggest I may get a true value when an error
occurs. My experience with execute_array and Oracle shows I get:

return 0, when none resulted in a change but no errors
  e.g.
  drop table mytest
  create table mytest (a int primary key, b char(20))
  insert into mytest values (1,'onetwothree')
  update mytest set b = ? where a = ?
$sth->bind_param_array(2, [2])
$sth->bind_param_array(1, ['two'])
  $sth->execute_array( { ArrayTupleStatus => [EMAIL PROTECTED] } )

  returns 0

  No, error, just no update occurred. It does not return 1 as the slide
  suggests and does seem to be the number of rows changed - none.

returns undef when there is an error
  e.g.
  as per above example but the bind_param_array for p2 is invalid e.g. 'xxx'

  This seems to also contradict the slide but agrees with the DBI pod.


lastly I get undef if there are multiple rows but the last one errors.
e.g. as above except the bind_param_arrays are:

 $sth->bind_param_array(2, [1, 'xxx']);
 $sth->bind_param_array(1, ['one', 'two']);

 returns undef but executes the 1,'one'.

I am now unclear as to what is correct. Can you clarify?

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com

Re: Memory access problem with DBI or DBD-Mysql?

[Patrick Galbraith]

Federico,

That may be the issue. I have encountered this issue in other parts of 
the driver. There is a better way to do this, and I can look at making 
sure what is being passed is the same data object.


Thanks!

Patrick

Federico Giannici wrote:

Since there has been no reply to my previous message, I have done 
further investigations trying to find the problem.


Please note that my knowledge of DBI/DBD is almost null, so the 
followings are only simple suppositions.


I have seen that mysql_st_internal_execute() function is executed by 
both the "do" and "execute" methods. It seems that the problems are 
only with the "do" method and not with the "execute", so I looked for 
the differences between them.


The main difference seems to be that "execute" passes a STATEMENT 
handle as first argument, while "do" passes a DATABASE handle. The 
mysql_st_internal_execute() function uses this handle to obtain the 
sth and then from this one the dbh.


So, my hypothesis is that if the initial handle is a database one, the 
sth (and the derived dbh) obtained from this is not a valid one!


Anybody can confirm (or negate) this wild hypothesis?

Thanks.

P.S.
I want to repeat that the problem manifest itself only under OpenBSD 
because of it's memory management that cause the program to segfault 
if try to access a non allocated memory. In other operating systems, a 
random value is get for "imp_dbh->bind_type_guessing", which is almost 
irrelevant.



Federico Giannici wrote:

It seems to me that there is some kind of memory access problem with 
DBI or DBD-Mysql.


I'm using OpenBSD 3.9-stable amd64. On OpenBSD 3.3 i386 the problem 
didn't appeared. As you may know, recent version of OpenBSD have a 
new kind of memory handling that make the programs segfault when they 
try to access no (longer) allocated memory.


I'm using DBI 1.45 and DBD-Mysql 2.9008. I tried DBI 1.52 and 
DBD-Mysql 3.0006, but the problems were more frequent, so I remained 
to the old versions.


Here is the problem: frequently some "do" commands cause perl to 
crash with signal 11. The crashes seems to depend on a lot of 
factors. For example, loading more libraries could make the program 
to start working. I think it depends on the structure of the memory 
allocated to the program.


Here is the "bt" output of the core dump:

#0  0x5260a736 in mysql_st_internal_execute (h=0x4713b6e0, 
statement=0x479b7140, attribs=0x4aa5fd40, numParams=0, params=0x0,
cdaPtr=0x7f7c8610, svsock=0x43c90498, use_mysql_use_result=0) 
at dbdimp.c:1654
#1  0x52612da3 in XS_DBD__mysql__db_do (cv=0x40970b20) at 
mysql.xs:222
#2  0x50ddf07b in XS_DBI_dispatch () from 
/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DBI/DBI.so
#3  0x4a5a1c47 in Perl_pp_entersub () at 
/usr/src/gnu/usr.bin/perl/pp_hot.c:2890
#4  0x4a60899e in Perl_runops_standard () at 
/usr/src/gnu/usr.bin/perl/run.c:37
#5  0x4a5f744d in S_run_body (oldscope=1) at 
/usr/src/gnu/usr.bin/perl/perl.c:1936
#6  0x4a5f7231 in perl_run (my_perl=0x45356258) at 
/usr/src/gnu/usr.bin/perl/perl.c:1855

#7  0x00401afe in main ()

I have found the problem is caused by accessing 
"imp_dbh->bind_type_guessing" for the call to ParseParam() inside 
mysql_st_internal_execute().


I have verified that "imp_dbh" is NOT null, but trying to access any 
member make the program segfault. So maybe the pointer is a stale one?


I have not enough knowledge of DBI to make more debugging.


Bye.

Re: Memory access problem with DBI or DBD-Mysql?

[Patrick Galbraith]

Federico,

Sorry for the belated reply.

I'll look into this issue and see if indeed the pointer is stale. Do you 
have a test script I could use to reproduce this? Another thing you can 
also do is use server side prepared statements in the latest driver. It 
doesn't use ParseParam (which does the statement parsing). It lets the 
server do this work.


Thanks!

Patrick

Federico Giannici wrote:

It seems to me that there is some kind of memory access problem with 
DBI or DBD-Mysql.


I'm using OpenBSD 3.9-stable amd64. On OpenBSD 3.3 i386 the problem 
didn't appeared. As you may know, recent version of OpenBSD have a new 
kind of memory handling that make the programs segfault when they try 
to access no (longer) allocated memory.


I'm using DBI 1.45 and DBD-Mysql 2.9008. I tried DBI 1.52 and 
DBD-Mysql 3.0006, but the problems were more frequent, so I remained 
to the old versions.


Here is the problem: frequently some "do" commands cause perl to crash 
with signal 11. The crashes seems to depend on a lot of factors. For 
example, loading more libraries could make the program to start 
working. I think it depends on the structure of the memory allocated 
to the program.


Here is the "bt" output of the core dump:

#0  0x5260a736 in mysql_st_internal_execute (h=0x4713b6e0, 
statement=0x479b7140, attribs=0x4aa5fd40, numParams=0, params=0x0,
cdaPtr=0x7f7c8610, svsock=0x43c90498, use_mysql_use_result=0) 
at dbdimp.c:1654
#1  0x52612da3 in XS_DBD__mysql__db_do (cv=0x40970b20) at 
mysql.xs:222
#2  0x50ddf07b in XS_DBI_dispatch () from 
/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DBI/DBI.so
#3  0x4a5a1c47 in Perl_pp_entersub () at 
/usr/src/gnu/usr.bin/perl/pp_hot.c:2890
#4  0x4a60899e in Perl_runops_standard () at 
/usr/src/gnu/usr.bin/perl/run.c:37
#5  0x4a5f744d in S_run_body (oldscope=1) at 
/usr/src/gnu/usr.bin/perl/perl.c:1936
#6  0x4a5f7231 in perl_run (my_perl=0x45356258) at 
/usr/src/gnu/usr.bin/perl/perl.c:1855

#7  0x00401afe in main ()

I have found the problem is caused by accessing 
"imp_dbh->bind_type_guessing" for the call to ParseParam() inside 
mysql_st_internal_execute().


I have verified that "imp_dbh" is NOT null, but trying to access any 
member make the program segfault. So maybe the pointer is a stale one?


I have not enough knowledge of DBI to make more debugging.


Bye.

Re: Problem with DBI make

[Jonathan Leffler]

On 9/4/06, John Gallagher <[EMAIL PROTECTED]> wrote:

I've just run make again and included the output

The system I'm trying to install DBI on is a hp-ux 11.11

And the version of perl installed is 5.8.7



(Bundled) cc: warning 480: The -A option is available only with the
C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Z option is available only with the
C/ANSI C product; ignored.
(Bundled) cc: warning 422: Unknown option "f" ignored.
(Bundled) cc: warning 480: The +Onolimit option is available only with
the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Opromote_indirect_calls option is
available only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Z option is available only with the
C/ANSI C product; ignored.
cpp: "/opt/perl_32/lib/5.8.7/PA-RISC1.1-thread-multi/CORE/perlio.h",
line 108: error 4065: Recursion in macro "PerlIO".
*** Error exit code 1

You're using the bundled C compiler which is not an ANSI C compiler.
Your Perl was built with the HP ANSI C compiler.

Either: get the HP ANSI C compiler
Or: get GCC and build your own Perl with it.



--
Jonathan Leffler <[EMAIL PROTECTED]>  #include 
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."

RE: Problem with DBI make

[John Gallagher]

Title: RE: Problem with DBI make





Hi Tim,


I've just run make again and included the output


The system I'm trying to install DBI on is a hp-ux 11.11


And the version of perl installed is 5.8.7


John


-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]] 
Sent: 01 September 2006 18:33
To: John Gallagher
Cc: 'dbi-users@perl.org'
Subject: Re: Problem with DBI make



On Fri, Sep 01, 2006 at 01:06:54PM +0100, John Gallagher wrote:
> 
> Hi
> 
> I've encountered the below error when running a make for the DBI 
> module;
> 
> Make runs up to a certain point but then just bombs with the below 
> message
> 
> Perl.c: In function `XS_DBD__Perl__st_DESTROY':
> Perl.c:1054: warning: unused parameter `cv'
> Perl.c: In function `boot_DBD__Perl':
> Perl.c:1106: warning: unused parameter `cv'
> make: *** [Perl.o] Error 1
> 
> Thanks for any assistance given


Those are only harmless warnings. Please include more of the log.


Tim.




BT Communications Ireland Limited 
is a wholly owned subsidiary of BT Group plc 
Registered in Ireland, Registration No. 141524 
Grand Canal Plaza, Upper Grand Canal Street, Dublin, Ireland 


This electronic message contains information (and may contain files) from BT Communications Ireland Limited which may be privileged or confidential. The information is intended to be for the sole use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information and or files is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. http://www.btireland.ie

  


 


cc -c-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae -D_HPUX_SOURCE 
-Wl,+vnocompatwarnings +Z -DUSE_SITECUSTOMIZE -DNO_HASH_SEED 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fast +Onolimit 
+Opromote_indirect_calls +DAportable +DS2.0-DVERSION=\"1.52\"  
-DXS_VERSION=\"1.52\" +Z 
"-I/opt/perl_32/lib/5.8.7/PA-RISC1.1-thread-multi/CORE"   Perl.c
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C 
product; ignored.
(Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C 
product; ignored.
(Bundled) cc: warning 422: Unknown option "f" ignored.
(Bundled) cc: warning 480: The +Onolimit option is available only with the 
C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Opromote_indirect_calls option is available 
only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C 
product; ignored.
cpp: "/opt/perl_32/lib/5.8.7/PA-RISC1.1-thread-multi/CORE/perlio.h", line 108: 
error 4065: Recursion in macro "PerlIO".
*** Error exit code 1

Re: AutoCommit and DBI::Proxy driver

[John Escott]

Tim Bunce <[EMAIL PROTECTED]> wrote on 04/09/2006 12:02:53:

> I'd appreciate it, John, if you could file a bug report on rt.cpan.org

Ok, Tim, done. Ticket #21320.

best regards, John.

Re: Getting DBD::Oracle tests working

[Karl Auer]

On Sun, 2006-09-03 at 18:47 -0400, John D Groenveld wrote:
> In message <[EMAIL PROTECTED]>, Karl Auer writes:
> >   export TWO_TASK=T:my_db_host_name:some_id
> 
> $ 
> TWO_TASK="(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=my_db_host_name)(PORT=1521)))(CONNECT_DATA=(SID=some_sid)))"
> $ export TWO_TASK
> $ make test

That did it - almost. I had to use SERVICE_NAME instead of SID, and had
to try several variations on the name I'd been given (grrr) but
eventually I got further.

I'm now getting "bad username or password", so I'm connecting with the
host and instance, which is major progress in itself. I guess
scott/tiger have been removed from the DB I'm trying to install with, so
the current plan is to find an Oracle instance that still has them (or
some usable alternative).

Regards, K.

-- 
~~~
Karl Auer ([EMAIL PROTECTED])   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

Re: code needed

[Eric Krause]

Check out this web page, 
http://www.developer.com/lang/other/article.php/3454041. It has examples 
that  return link and tags using WWW::Mechanize, which is a subset of LWP.


-Eric

Hal Wigoda wrote:
anyone have any code that will return the links and tags from web 
document

downloaded using LWP?

hal
chicago

--To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: code needed

[Tom Phoenix]

On 9/3/06, Hal Wigoda <[EMAIL PROTECTED]> wrote:


HTML-LinkExtractor-0.13
libwww-perl-5.805
linkcheck-1.05
HTML-Parser-3.55
HTML-SimpleLinkExtor-1.13
HTML-Tagset-3.10

have failed me.


In what way have they failed you? Are they somehow insufficient for your task?

Have you tried HTML::LinkExtor?

There are a number of other extensions and subclasses of HTML::Parser
on CPAN; do any of them look promising?

Does any module come close to what you want, so that a little
programming could fill the gap?

Cheers!

--Tom Phoenix
Stonehenge Perl Training

Re: code needed

[Tom Phoenix]

On 9/3/06, Hal Wigoda <[EMAIL PROTECTED]> wrote:


anyone have any code that will return the links and tags from web
document downloaded using LWP?


Have you looked on CPAN yet?

   http://search.cpan.org/

Hope this helps!

--Tom Phoenix
Stonehenge Perl Training

RE: Encoding

[h-taguchi]

> perl -MDBI -e 'print "$DBI::VERSION\n";'

Less typed:

perl -MDBI -le 'print DBI->VERSION'

Regards,

RE: Encoding

[Martin J. Evans]

On 31-Aug-2006 Daniel Zeman wrote:
> Hi,
> I wonder if anyone can help me.
> 
> I am using
> - Debian Linux
> - Perl 5.8.8
> - DBI (I do not know how to figure out its version)

perl -MDBI -e 'print "$DBI::VERSION\n";'

> - MySQL 5.0.22-Debian_3-log

What DBD::mysql version are you using?

perl -M'DBD::mysql' -e 'print "$DBD::mysql::VERSION\n";'

> I want to store and handle data in UTF-8 but so far I have not been able 
> to force Perl/DBI to do so.
> 
> I have created a table using
> 
>  my $sql = "CREATE TABLE $tbl (".join(", ", @columns).") CHARACTER 
> SET utf8 COLLATE utf8_czech_ci;";
>  $dbh->do($sql);
> 
> I feeded the table with data using
> 
>  my $list_of_columns = join(", ", @names);
>  my $list_of_values = join(", ", map{"_utf8'$record->{$_}'"}(@names));
>  my $sql = "INSERT INTO $tbl ($list_of_columns) VALUES 
> ($list_of_values);";
>  $dbh->do($sql);

You would be better using bound parameters as then only the data can be utf-8.

> I have looked into the database using phpMyAdmin 2.8.2-Debian-0.1 and it 
> really looked like the data were stored in correct UTF-8.
> 
> However, when I retrieve the data from Perl/DBI, something in the chain 
> (MySQL? the driver? DBI?) decides that another encoding (probably, 
> Latin1) would be better for me. It "converts" the strings from UTF-8 to 
> that encoding, which means, at the time the data arrives in my Perl 
> code, all the non-Latin1 characters have already been irrecoverably 
> converted to question marks. I would be happy to decode the data myself 
> but there is nothing I can do with the question marks.
> 
> I am using the following code to retrieve the data:
> 
>  my $sql = "SELECT kod, hry.nazev FROM hry INNER JOIN prodej ON 
> hry.kod = prodej.kod_hry GROUP BY kod, hry.nazev";
>  my $sqlobj = $dbh->prepare($sql);
>  $sqlobj->execute();
>  while(my ($kod, $nazev) = $sqlobj->fetchrow_array())
>  {
>  ...
>  }
> 
> So far, the only workaround I have, is not to tell the DBI the data is 
> UTF-8 when I am inserting it (i.e., drop the "_utf8" part before the 
> single quote), and use Encode; decode("utf8", ...) on anything I fetch 
> from the database. This way, the database never knows the data was a 
> UTF-8 text, treats the bytes as Latin1 characters and returns them 
> undisturbed. However, I cannot access the data using phpMyAdmin (unless 
> I en/decode UTF in my brain), the string lengths do not reflect the 
> reality etc.
> 
> Is there a better way to do it? I think there must be some small stupid 
> locale-like setting telling the machine that I am a UTF guy. But the 
> settings I was able to come up with did not help and I actually have no 
> idea which part of the MySQL-driver-DBI-Perl chain is responsible.
> 
> Any hints are welcome.
> Thanks
> 
> Dan

I posted a small patch (in dbi-dev a couple of months ago) to a recent(ish)
DBD::mysql which allows you to retrieve utf-8 data marked as utf-8 in perl. If
is not a complete solution but works for most things.

See
http://www.nntp.perl.org/group/perl.dbi.dev/4548

It may have been included in the 3.0006_1 development release of DBD::mysql.

You also need to look up "set character set utf8" and "set names utf8" in mysql
documentation.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com

ANNOUNCE: Advanced DBI Tutorial Slides

[Tim Bunce]

  file: $CPAN/authors/id/T/TI/TIMB/DBI_AdvancedTalk_200608.pdf
  size: 486540 bytes
   md5: c305fe9ae393a534f17efc83a4563d28

Slides for this years version of my Advanced DBI tutorial are available online.

Tim.

Re: Make test of 1.52 failed on childhandles

[Clive George]

Yup, that worked - now reporting 1 for both t/72 and PurePerl.pm, and passed 
the tests fine.


cheers,
clive

- Original Message - 
From: "Tim Bunce" <[EMAIL PROTECTED]>

To: "Clive George" <[EMAIL PROTECTED]>
Cc: "Tim Bunce" <[EMAIL PROTECTED]>; 
Sent: Monday, September 04, 2006 11:37 AM
Subject: Re: Make test of 1.52 failed on childhandles



Ah. Thanks. Try changing both to use

Scalar::Util::weaken( my $test = [] );

Tim.

On Mon, Sep 04, 2006 at 02:29:53AM +0100, Clive George wrote:

t/72childhandles works fine - the warn $HAS_WEAKEN says "1 at
t/72childhandles.t line 19.".

The zvpp ones give

Use of uninitialized value in warn at
/home/cg5/DBI-1.52/blib/lib/DBI/PurePerl.pm line 49.
Modification of a read-only value attempted at
/home/cg5/DBI-1.52/blib/lib/DBI/PurePerl.pm line 45.
   ...caught at /home/cg5/DBI-1.52/blib/lib/DBI/PurePerl.pm line 49.

when I added the warn $HAS_WEAKEN to line 49. (line 45 is
Scalar::Util::weaken(my $test = \"foo"); ).

Ah - t/72childhandles.t doesn't actually have the same code as 
PurePerl.pm


my $HAS_WEAKEN = eval {
   require Scalar::Util;
   # this will croak() if this Scalar::Util doesn't have a working
weaken().
   Scalar::Util::weaken( \my $test ); # same test as in DBI.pm
   1;
};

vs

# check for weaken support, used by ChildHandles
my $HAS_WEAKEN = eval {
   require Scalar::Util;
   # this will croak() if this Scalar::Util doesn't have a working
weaken().
   Scalar::Util::weaken(my $test = \"foo");
   1;
};

So which one is correct?

(We've got Scalar::Util 1.13 - looking at the change log for this hints
that weaken hasn't changed in the later versions - should I try 1.18
anyway?)

cheers,
clive

- Original Message - 
From: "Tim Bunce" <[EMAIL PROTECTED]>

To: "Clive George" <[EMAIL PROTECTED]>
Cc: 
Sent: Sunday, September 03, 2006 11:16 PM
Subject: Re: Make test of 1.52 failed on childhandles


>Did t/72childhandles also fail, or was it
>only t/zvpp_72childhandles?
>
>Both t/72childhandles.t and lib/DBI/PurePerl.pm use the same code to
>decide if there's a working Scalar::Util::weaken() available:
>
>my $HAS_WEAKEN = eval {
>require Scalar::Util;
># this will croak() if this Scalar::Util doesn't have a working
>weaken().
>Scalar::Util::weaken(my $test = \"foo");
>1;
>};
>
>Could you look into this further for me? Adding a
>warn $HAS_WEAKEN;
>after that code in both t/72childhandles.t and lib/DBI/PurePerl.pm
>would be a good place to start.
>
>Thanks!
>
>Tim.
>
>On Fri, Sep 01, 2006 at 04:30:06PM +0100, Clive George wrote:
>>Hi -
>>
>>I just got DBI 1.52 out, and the make test stage failed on 
>>childhandles.

>>This is on AIX 5.3, perl 5.8.2 built for aix-thread-multi.
>>
>>t/zvpp_72childhandles1..14
>>ok 1
>>ok 2
>>not ok 3
>>not ok 4
>>ok 5 - All handles should be undef now
>>ok 6 - ChildHandles should be an array-ref if wekref is available
>>not ok 7
>>drh  DBI::dr=HASH(0x3018cb8c)
>>not ok 8
>>ok 9
>>not ok 10
>>not ok 11
>>ok 12 - handles should be gone now
>>ok 13
>>ok 14
>>
>>Is this supposed to happen?
>>
>>cheers,
>>clive
>>
>--
>This email has been verified as Virus free
>Virus Protection and more available at http://www.plus.net


--
This email has been verified as Virus free
Virus Protection and more available at http://www.plus.net 

Re: AutoCommit and DBI::Proxy driver

[Tim Bunce]

On Mon, Sep 04, 2006 at 09:36:30AM +0100, John Escott wrote:
> > The problems start when I try to set '$dbh-{AutoCommit} =0'  (or call
> > $dbh->begin_work' ) for the SECOND time (after the first call to
> > '$dbh->commit'). The error says that AutoCommit is not supported by my
> > driver.
> 
> I've been bitten by this in the past too, and understand it's a bug in 
> DBD::Proxy (at least it was in 0.2004; not sure it it's fixed in the 
> latest version).

I don't recall it getting fixed.

I'd appreciate it, John, if you could file a bug report on rt.cpan.org

Even better would be a patch to the t/80proxy.t test script that
demonstrates the problem.

Tim.

> You can work around it by setting $dbh->{AutoCommit} = 1 after your commit 
> or rollback.

Re: Make test of 1.52 failed on childhandles

[Tim Bunce]

Ah. Thanks. Try changing both to use

Scalar::Util::weaken( my $test = [] ); 

Tim.

On Mon, Sep 04, 2006 at 02:29:53AM +0100, Clive George wrote:
> t/72childhandles works fine - the warn $HAS_WEAKEN says "1 at 
> t/72childhandles.t line 19.".
> 
> The zvpp ones give
> 
> Use of uninitialized value in warn at 
> /home/cg5/DBI-1.52/blib/lib/DBI/PurePerl.pm line 49.
> Modification of a read-only value attempted at 
> /home/cg5/DBI-1.52/blib/lib/DBI/PurePerl.pm line 45.
>...caught at /home/cg5/DBI-1.52/blib/lib/DBI/PurePerl.pm line 49.
> 
> when I added the warn $HAS_WEAKEN to line 49. (line 45 is 
> Scalar::Util::weaken(my $test = \"foo"); ).
> 
> Ah - t/72childhandles.t doesn't actually have the same code as PurePerl.pm
> 
> my $HAS_WEAKEN = eval {
>require Scalar::Util;
># this will croak() if this Scalar::Util doesn't have a working 
> weaken().
>Scalar::Util::weaken( \my $test ); # same test as in DBI.pm
>1;
> };
> 
> vs
> 
> # check for weaken support, used by ChildHandles
> my $HAS_WEAKEN = eval {
>require Scalar::Util;
># this will croak() if this Scalar::Util doesn't have a working 
> weaken().
>Scalar::Util::weaken(my $test = \"foo");
>1;
> };
> 
> So which one is correct?
> 
> (We've got Scalar::Util 1.13 - looking at the change log for this hints 
> that weaken hasn't changed in the later versions - should I try 1.18 
> anyway?)
> 
> cheers,
> clive
> 
> - Original Message - 
> From: "Tim Bunce" <[EMAIL PROTECTED]>
> To: "Clive George" <[EMAIL PROTECTED]>
> Cc: 
> Sent: Sunday, September 03, 2006 11:16 PM
> Subject: Re: Make test of 1.52 failed on childhandles
> 
> 
> >Did t/72childhandles also fail, or was it
> >only t/zvpp_72childhandles?
> >
> >Both t/72childhandles.t and lib/DBI/PurePerl.pm use the same code to
> >decide if there's a working Scalar::Util::weaken() available:
> >
> >my $HAS_WEAKEN = eval {
> >require Scalar::Util;
> ># this will croak() if this Scalar::Util doesn't have a working 
> >weaken().
> >Scalar::Util::weaken(my $test = \"foo");
> >1;
> >};
> >
> >Could you look into this further for me? Adding a
> >warn $HAS_WEAKEN;
> >after that code in both t/72childhandles.t and lib/DBI/PurePerl.pm
> >would be a good place to start.
> >
> >Thanks!
> >
> >Tim.
> >
> >On Fri, Sep 01, 2006 at 04:30:06PM +0100, Clive George wrote:
> >>Hi -
> >>
> >>I just got DBI 1.52 out, and the make test stage failed on childhandles.
> >>This is on AIX 5.3, perl 5.8.2 built for aix-thread-multi.
> >>
> >>t/zvpp_72childhandles1..14
> >>ok 1
> >>ok 2
> >>not ok 3
> >>not ok 4
> >>ok 5 - All handles should be undef now
> >>ok 6 - ChildHandles should be an array-ref if wekref is available
> >>not ok 7
> >>drh  DBI::dr=HASH(0x3018cb8c)
> >>not ok 8
> >>ok 9
> >>not ok 10
> >>not ok 11
> >>ok 12 - handles should be gone now
> >>ok 13
> >>ok 14
> >>
> >>Is this supposed to happen?
> >>
> >>cheers,
> >>clive
> >>
> >--
> >This email has been verified as Virus free
> >Virus Protection and more available at http://www.plus.net 
> 

Re: Problem with DBI make

[Tim Bunce]

On Mon, Sep 04, 2006 at 09:43:11AM +0100, John Gallagher wrote:
>Hi Tim,
> 
>I've just run make again and included the output
>The system I'm trying to install DBI on is a hp-ux 11.11
>And the version of perl installed is 5.8.7

> cc -c-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae -D_HPUX_SOURCE 
> -Wl,+vnocompatwarnings +Z -DUSE_SITECUSTOMIZE -DNO_HASH_SEED 
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fast +Onolimit 
> +Opromote_indirect_calls +DAportable +DS2.0-DVERSION=\"1.52\"  
> -DXS_VERSION=\"1.52\" +Z 
> "-I/opt/perl_32/lib/5.8.7/PA-RISC1.1-thread-multi/CORE"   Perl.c
> cpp: "/opt/perl_32/lib/5.8.7/PA-RISC1.1-thread-multi/CORE/perlio.h", line 
> 108: error 4065: Recursion in macro "PerlIO".

I'd guess that the perl you're using wasn't built with that compiler.
Try building a perl with that compiler then building DBI with that new perl.

Tim.

Re: AutoCommit and DBI::Proxy driver

[John Escott]

> The problems start when I try to set '$dbh-{AutoCommit} =0'  (or call
> $dbh->begin_work' ) for the SECOND time (after the first call to
> '$dbh->commit'). The error says that AutoCommit is not supported by my
> driver.

I've been bitten by this in the past too, and understand it's a bug in 
DBD::Proxy (at least it was in 0.2004; not sure it it's fixed in the 
latest version).

You can work around it by setting $dbh->{AutoCommit} = 1 after your commit 
or rollback.

best regards, John.