Re: AutoCommit and DBI::Proxy driver
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.
Re: Problem with DBI make
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: 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: dbi-users@perl.org
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: AutoCommit and DBI::Proxy driver
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
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]; dbi-users@perl.org
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: dbi-users@perl.org
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
ANNOUNCE: Advanced DBI Tutorial Slides
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: Encoding
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
RE: Encoding
perl -MDBI -e 'print $DBI::VERSION\n;' Less typed: perl -MDBI -le 'print DBI-VERSION' Regards,
Re: code needed
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: code needed
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
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] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Getting DBD::Oracle tests working
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: AutoCommit and DBI::Proxy driver
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: Problem with DBI make
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: Problem with DBI make
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 disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Encoding
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: Encoding
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
execute_array/execute_for_fetch (was: ANNOUNCE: Advanced DBI Tutorial Slides)
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: code needed
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] http://learn.perl.org/ http://learn.perl.org/first-response -- Scott T. Hildreth [EMAIL PROTECTED]
DBI install error
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 -fast +Onolimit
Re: db2 - persistent connection
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: db2 - persistent connection
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?
