Re: $DBI::neat_maxlen and execute() and debugging
Hi Tim, On Fri, May 08, 2009 at 12:59:03AM +0100, Tim Bunce wrote: > > It might be more efficient/effective to use callbacks to enable tracing > in just the calls you're interested in. Callbacks are (still) > undocumented, but the test file is pretty clear: > http://cpansearch.perl.org/src/TIMB/DBI-1.608/t/70callbacks.t I was looking at the callbacks a few days ago. I wasn't clear what all was available, but more importantly I couldn't see if it was possible to also get the execute parameters. I assume it's not possible with the callbacks. Is that correct? Thanks, -- Bill Moseley. mose...@hank.org Sent from my iMutt
Re: $DBI::neat_maxlen and execute() and debugging
On Thu, May 07, 2009 at 10:08:52AM -0700, Bill Moseley wrote: > I can set $DBI::neat_maxlen to have DBI trace output show the complete > statements, but execute still is truncated. > > execute(1, 2, ...)= '0E0' at dbi_neat.pl line 91 > > Is there an equivalent "neat" setting to show all the bind variables? I'd guess you're using trace level 1, so you're only seeing the returns from method calls. Trace level 2 will show the entry to the methods and include all the arguments. (Note that $DBI::neat_maxlen only affects the length of individual strings, not the number of arguments output.) > Also, I want to hook into the trace to be able to selectively trace > some statements based on inspecting what caller() returns. Does DBI > have any existing hooks for doing this? What I want to see is > everything passed to the database. I can see this in the database > logs but I want to filter and add extra info based on caller(). The trace is written directly to a filehandle. The docs include an example of using PerlIO layers to gain more control: http://search.cpan.org/~timb/DBI/DBI.pm#Tracing_to_Layered_Filehandles It might be more efficient/effective to use callbacks to enable tracing in just the calls you're interested in. Callbacks are (still) undocumented, but the test file is pretty clear: http://cpansearch.perl.org/src/TIMB/DBI-1.608/t/70callbacks.t Tim.
$DBI::neat_maxlen and execute() and debugging
I can set $DBI::neat_maxlen to have DBI trace output show the complete statements, but execute still is truncated. execute(1, 2, ...)= '0E0' at dbi_neat.pl line 91 Is there an equivalent "neat" setting to show all the bind variables? Also, I want to hook into the trace to be able to selectively trace some statements based on inspecting what caller() returns. Does DBI have any existing hooks for doing this? What I want to see is everything passed to the database. I can see this in the database logs but I want to filter and add extra info based on caller(). Thanks, -- Bill Moseley mose...@hank.org Sent from my iMutt
Re: DBD::Oracle - forcing a number to look like a string in a placeholder
Yes I think you can
Give this a try
ORA_STRING, ORA_LONG, ORA_RAW, ORA_LONGRAW,
use DBD::Oracle qw(:ora_types);
.. connect as normal
$sth=$dbh->prepare("SELECT * FROM PRODUCTS WHERE VENDOR = :p_vendor");
$sth->bind_param(":p_vendor",'7553', { ora_type =>ORA_CHAR });
if ORA_CHAR dose not work give ORA_STRING or ORA_VARCHAR2 a try
E R wrote:
Hi,
I have a situation where I need a number to be represented as a string
in a place holder:
my $x = 7553;
$dbh->do("SELECT * FROM PRODUCTS WHERE VENDOR = ?", {}, $x);
I'd like the above to be the same as: SELECT * FROM PRODUCTS WHERE
VENDOR = '7553'
The VENDOR column is a VARCHAR2, and Oracle won't use the index on
that column unless it is specified as a string.
However, it doesn't complain if VENDOR = 7553 is used.
See this link for more background info:
http://forums.oracle.com/forums/thread.jspa?messageID=3451942
Is there a way to ensure that the parameter is passed to Oracle as a string?
Thanks,
ER
DBD::Oracle - forcing a number to look like a string in a placeholder
Hi,
I have a situation where I need a number to be represented as a string
in a place holder:
my $x = 7553;
$dbh->do("SELECT * FROM PRODUCTS WHERE VENDOR = ?", {}, $x);
I'd like the above to be the same as: SELECT * FROM PRODUCTS WHERE
VENDOR = '7553'
The VENDOR column is a VARCHAR2, and Oracle won't use the index on
that column unless it is specified as a string.
However, it doesn't complain if VENDOR = 7553 is used.
See this link for more background info:
http://forums.oracle.com/forums/thread.jspa?messageID=3451942
Is there a way to ensure that the parameter is passed to Oracle as a string?
Thanks,
ER
Can selectrow_array() et al detect non-select statements?
Question on StackOverflow:
http://stackoverflow.com/questions/834712/perl-dbi-and-dbdinformix-error/834856
--
$db_handle=DBI->connect("$dbstr", "", "",
{RaiseError => 0, AutoCommit => 0, PrintError => 1})
|| die "Connect error: $DBI::errstr" ;
$result=$db_handle->selectrow_array("set isolation to dirty read");
--
Note:$dbstr is a valid database name.
I am not a Database programmer.
What am I doing wrong which is causing the perl script fail saying:
*DBD::Informix::db selectrow_array failed: SQL: -400: Fetch attempted on
unopen cursor.*
Verrsion information not given - but not dreadfully material.
Can/should the selectrow_array() method provided by DBI detect that the
statement is not one that returns values and generate a more meaningful
error, rather than just letting/making the driver fabricate an error?
I'm thinking that it should check NUM_OF_FIELDS for a non-zero value after
the successful execute. In one sense, the damage may already be done
(suppose it was a DELETE statement?).
--
Jonathan Leffler #include
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
RE: ezmlm warning
On Wed, 6 May 2009, Will Rutherdale (rutherw) wrote: Well I got this one. That's the problem with using an ancient piece of crap like ezmlm, it has horrid management period, especially since ezmlm lists (thank god theres only 2 of them left that I'm on) send bounce probe message 3 weeks or so later after the block message, and 9/10 times its always because of an RBL entry, the list needs upgrading to either Ecartis or Mailman, one of the two, but I suspect it'll remain in teh dark ages for some time to come. -- Res -Beware of programmers who carry screwdrivers
Re: Incorrect required version in readme for DBI 1.5 and 1.6
On 2009-05-06 10:18:05 -0400, Tom Sorensen wrote: > The readme files for versions 1.51 and up state that Perl 5.6 and up > is required. The Makefile.PL says otherwise. > > For versions 1.606 and up it simply will not compile: > > chloe DBI-1.606 0> perl Makefile.PL > Perl v5.8.10 required--this is only v5.6.1, stopped at Makefile.PL line 10. 5.8.10 isn't even out yet (5.8.9 is the latest release in the 5.8.x series according to http://www.cpan.org/src/README.html), so I think this must be a typo. Maybe that should read 5.8.1? hp -- _ | Peter J. Holzer| Auf jedem Computer sollte der Satz Ludwigs II |_|_) | Sysadmin WSR | eingeprägt stehen: "Ein ewig Rätsel will ich | | | h...@wsr.ac.at | bleiben, mir und andern." __/ | http://www.hjp.at/ |-- Wolfram Heinrich in desd pgpGoLt96Tt76.pgp Description: PGP signature
RE: ezmlm warning
Well I got this one. -Will -Original Message- From: dbi-users-h...@perl.org [mailto:dbi-users-h...@perl.org] Sent: 6 May 2009 07:41 To: will.rutherd...@sciatl.com Subject: ezmlm warning Hi! This is the ezmlm program. I'm managing the dbi-users@perl.org mailing list. I'm working for my owner, who can be reached at dbi-users-ow...@perl.org. Messages to you from the dbi-users mailing list seem to have been bouncing. I've attached a copy of the first bounce message I received. If this message bounces too, I will send you a probe. If the probe bounces, I will remove your address from the dbi-users mailing list, without further notice. I've kept a list of which messages from the dbi-users mailing list have bounced from your address. Copies of these messages may be in the archive. To retrieve a set of messages 123-145 (a maximum of 100 per request), send an empty message to: To receive a subject and author list for the last 100 or so messages, send an empty message to: Here are the message numbers: 33900
Incorrect required version in readme for DBI 1.5 and 1.6
The readme files for versions 1.51 and up state that Perl 5.6 and up is required. The Makefile.PL says otherwise. For versions 1.606 and up it simply will not compile: chloe DBI-1.606 0> perl Makefile.PL Perl v5.8.10 required--this is only v5.6.1, stopped at Makefile.PL line 10. BEGIN failed--compilation aborted at Makefile.PL line 12. For versions 1.51 through 1.605 it says it's not supported: chloe DBI-1.51 0> perl Makefile.PL ** Perl versions below 5.6.1 are no longer supported by the DBI. Perl versions 5.6.x may fail during installation with a complaint about the use of =head3 in the pod documentation. ** Please update the readmes to indicate that a newer version of Perl is required. I was attempting to compile on a stock Solaris 9 system: chloe DBI-1.51 130> perl -v This is perl, v5.6.1 built for sun4-solaris-64int (with 48 registered patches, see perl -V for more detail) Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page.
