Re: selectrow_hashref in DBI 1.32 doesn't always return a hashref
Can you post an example script that calls selectrow_hashref and
demonstrates the problem?
Tim.
On Fri, Feb 14, 2003 at 01:18:56PM +1100, Craig Sanders wrote:
> this seems to have changed since i installed DBI 1.32 (i upgraded from 1.30),
> and is breaking some scripts which assume that it will always return a hash.
>
> sometimes (when the query returns no rows), it returns the scalar "1" -
> attempting to use that as a hashref causes the script to die (with "strict
> refs" set - would cause strange errors without it)
>
> the problem seems to be in _do_selectrow() in DBI.pm, which is also used
> by selectrow_arrayref.
>
> as a temporary workaround fix, i hacked _do_selectrow() so that it
> always returns the appropriate reference.
>
> like so:
>
> sub _do_selectrow {
> my ($method, $dbh, $stmt, $attr, @bind) = @_;
> my $sth = ((ref $stmt) ? $stmt : $dbh->prepare($stmt, $attr))
> or return;
> $sth->execute(@bind)
> or return;
> my $row = $sth->$method()
> and $sth->finish;
> # temporary workaround fix. CAS 2003-02-14
> if ($method =~ /ref/ && ! ref($row)) {
> warn "* _do_selectrow workaround";
> $row = [] if ($method =~ /array/);
> $row = {} if ($method =~ /hash/);
> } ;
> return $row;
> }
>
>
> i don't know the DBI code well enough to know whether this will have
> other undesirable consequences, but it stops my scripts from dying until
> a real fix is available.
>
>
> craig
>
> --
> craig sanders <[EMAIL PROTECTED]>
>
> Fabricati Diem, PVNC.
> -- motto of the Ankh-Morpork City Watch
Re: selectrow_hashref in DBI 1.32 doesn't always return a hashref
On Sat, Feb 15, 2003 at 11:23:13AM +1100, Craig Sanders wrote: > On Sat, Feb 15, 2003 at 10:51:14AM +1100, Craig Sanders wrote: > > On Fri, Feb 14, 2003 at 11:05:19AM +0000, Tim Bunce wrote: > > > Can you post an example script that calls selectrow_hashref and > > > demonstrates the problem? > > > > the application is written in HTML::Mason, so all the stuff for opening > > the standalone version works OK (in that it doesn't die). for > non-existent record id 100 (which causes the HTML::Mason version to > die), the output is: > so, it looks like in plain perl selectrow_hashref returns undef when the > record doesn't exist, but in HTML::Mason it returns the scalar '1'. Thanks. Dig deeper. I'd bet the code is doing something like $row = $dbh->selectrow_hashref(...) || ...something... where the ...something... is returning '1'. Tim.
Re: Given a dbh, is it possible to find out if there are uncommited transactions?
On Fri, Feb 14, 2003 at 06:10:11PM +0100, Roger Perttu wrote: > > I assume the functionality I'm looking for doesn't exist. You're right. The DBI can't effectively keep track of whether a driver's session with it's database server is in a transaction of not. And many database API's don't provide a way to find out. Tim.
Re: dbiproxy Problem on Win2K...
On Tue, Feb 18, 2003 at 10:59:35AM +, oliver wrote: > > On Mon, 17 Feb 2003 09:56:02 -0800, Tim Howell wrote: > > >I'm having a problem with dbiproxy on Win2K. I'm connecting to the > >proxy server from perl 5.8 on a linux box in order to access a MS SQL > >database on the Win2K box. Everything works fine for one request. > >After a single query has been executed dbiproxy will no longer accept > >requests until it is restarted. > > > >I haven't seen any info on this from a google search. I've tried a > >couple of different versions of Storable, etc. > > > >Any ideas? > > We had some fun connecting to SQL Server from linux via DBD::Proxy a > while back... > > Initially, we had problems with the PlRPC package; under Win32 "\n" > gets written as 0x0a,0x0d to the socket. Fixing this to write a single > 0x0a instead resolved this. > > We also carried out modifications to Net::Daemon. Specifically, using > ithreads and "pre-forking" a number of child threads (producing a kind > of hybrid threads/fork setup on the DBD::ProxyServer side). (Note: This > change replaced the pre-forking code.) > A copy of the changes we made are available on request. *Please* give back to the community that gave the modules to you, by sending the patches to the maintainers of the modules. Thanks! Tim.
Re: dbiproxy Problem on Win2K...
On Thu, Feb 20, 2003 at 04:45:44PM +, oliver wrote: > On Tue, 18 Feb 2003 11:10:52 +0000, Tim Bunce wrote: > > >*Please* give back to the community that gave the modules to you, > >by sending the patches to the maintainers of the modules. > > We would have fedback earlier, but have just been too busy. > > I'll be dropping an email to the relevant maintainers as soon as it's > tidied up a bit... Thanks Oliver! Tim.
DBD::mysql - column_info() ?
Does enyone have a reasonably working implementation of column_info() for mysql? Tim.
Re: case sensitivity when creating a table. (corrected)
On Thu, Feb 20, 2003 at 02:36:04PM -0800, Jeff Zucker wrote: > Jeff Zucker wrote: > > > There is no database independent way to match a delimited identifier > >to an undelimited identifier. > > That part of my previous post is correct, but my examples were bad. > Here is a better explanation with examples from two differing > implementations: > > In the ANSI standard, a delimited identifier is equal to an undelimited > identifier if it matches *case-sensitively* to the *upper-cased* > undelimited identifier. Because undelimited identifiers are stored in the catalogs uppercased. > In PostgreSQL, a delimited identifier is equal to an undelimited > identifier if it matches *case-sensitively* to the *lower-cased* > undelimited identifier. Because undelimited identifiers are stored in the catalogs lowercased. > In ODBC, a delimited identifier is equal to an undelimited identifiers > if it matches *case-insenitively*. By "ODBC" I presume you mean windows ODBC using windows database like Access or MSSQL", because on windows case-insenitivity is the norm. I don't think it's part of the ODBC standard - but I've not checked (please correct me if I'm wrong). Using ODBC to talk to Oracle or PostgreSQL etc I think you'll find the other behaviours described above. Tim.
Re: DBD::mysql - column_info() ?
On Thu, Feb 20, 2003 at 06:57:37PM +, Tim Bunce wrote:
> Does anyone have a reasonably working implementation of column_info() for mysql?
I guess not, so I've written my own basic one and appended it below for feedback.
Tim.
sub DBD::mysql::db::column_info {
my ($dbh, $catalog, $schema, $table, $column) = @_;
return $dbh->set_err(1, "column_info doesn't support catalog or schema")
if defined $catalog or defined $schema;
return $dbh->set_err(1, "column_info doesn't support table wildcard")
if $table !~ /^\w+$/;
return $dbh->set_err(1, "column_info doesn't support column selection")
if $column ne "%";
my @names = qw(
TABLE_CAT TABLE_SCHEM TABLE_NAME COLUMN_NAME
DATA_TYPE TYPE_NAME COLUMN_SIZE BUFFER_LENGTH DECIMAL_DIGITS
NUM_PREC_RADIX NULLABLE REMARKS COLUMN_DEF
SQL_DATA_TYPE SQL_DATETIME_SUB CHAR_OCTET_LENGTH
ORDINAL_POSITION IS_NULLABLE CHAR_SET_CAT
CHAR_SET_SCHEM CHAR_SET_NAME COLLATION_CAT COLLATION_SCHEM COLLATION_NAME
UDT_CAT UDT_SCHEM UDT_NAME DOMAIN_CAT DOMAIN_SCHEM DOMAIN_NAME
SCOPE_CAT SCOPE_SCHEM SCOPE_NAME MAX_CARDINALITY
DTD_IDENTIFIER IS_SELF_REF
);
my %col_info;
my $desc = $dbh->selectall_arrayref("DESCRIBE $table", { Columns=>{} });
my $ordinal_pos = 0;
foreach my $row (@$desc) {
my $info = $col_info{ $row->{field} } = {
TABLE_NAME => $table,
COLUMN_NAME => $row->{field},
ORDINAL_POSITION => ++$ordinal_pos,
NULLABLE=> ($row->{null} eq 'YES') ? 1 : 0,
IS_NULLABLE => ($row->{null} eq 'YES') ? "YES" : "NO",
TYPE_NAME => $row->{type},
COLUMN_DEF => $row->{default},
mysql_is_pri_key => ($row->{key} eq 'PRI'),
};
my $type = $row->{type};
$type =~ m/^(\w+)(?:\((.*?)\))?\s*(.*)/;
my $basetype = $1;
my @type_params = map { s/^'(.*)'$/$1/; $_ } split /,/, $2||'';
my @type_attr = split / /, $3||'';
#warn "$type: $basetype [@type_params] [@type_attr]\n";
$info->{DATA_TYPE} = SQL_VARCHAR();
if ($basetype =~ /char|text|long/) {
$info->{DATA_TYPE} = SQL_CHAR() if $basetype eq 'char';
$info->{COLUMN_SIZE} = $type_params[0];
}
elsif ($basetype =~ /enum|set/) {
$info->{COLUMN_SIZE} = ($basetype eq 'set') ? length(join
",",@type_params) : 255; # XXX fix
$info->{"mysql_${basetype}_values"} = \@type_params;
}
elsif ($basetype =~ /int/) {
$info->{DATA_TYPE} = SQL_INTEGER();
$info->{NUM_PREC_RADIX} = 10;
$info->{COLUMN_SIZE} = $type_params[0];
}
elsif ($basetype =~ /decimal/) {
$info->{DATA_TYPE} = SQL_DECIMAL();
$info->{NUM_PREC_RADIX} = 10;
$info->{COLUMN_SIZE}= $type_params[0];
$info->{DECIMAL_DIGITS} = $type_params[1];
}
elsif ($basetype =~ /float|double/) {
$info->{DATA_TYPE} = ($basetype eq 'float') ? SQL_FLOAT() : SQL_DOUBLE();
$info->{NUM_PREC_RADIX} = 2;
$info->{COLUMN_SIZE} = ($basetype eq 'float') ? 32 : 64;
}
elsif ($basetype =~ /date|time/) { # date/datetime/time/timestamp
if ($basetype eq 'time' or $basetype eq 'date') {
$info->{DATA_TYPE} = ($basetype eq 'time') ? SQL_TYPE_TIME() :
SQL_TYPE_DATE();
$info->{COLUMN_SIZE} = ($basetype eq 'time') ? 8 : 10;
}
else { # datetime/timestamp
$info->{DATA_TYPE} = SQL_TYPE_TIMESTAMP();
$info->{SQL_DATA_TYPE} = SQL_DATETIME();
$info->{SQL_DATETIME_SUB} = $info->{DATA_TYPE} -
($info->{SQL_DATA_TYPE} * 10);
$info->{COLUMN_SIZE} = ($basetype eq 'datetime') ? 19 :
$type_params[0] || 14;
}
$info->{DECIMAL_DIGITS} = 0; # no fractional seconds
}
else {
warn "unsupported column '$row->{field}' type '$basetype' treated as
varchar";
}
$info->{SQL_DATA_TYPE} ||= $info->{DATA_TYPE};
#warn Dumper($info);
}
my $sponge = DBI->connect("DBI:Sponge:", '','')
or return $dbh->DBI::set_err($DBI::err, "DBI::Sponge: $DBI::errstr");
my $sth = $sponge->prepare("column_info $table", {
rows => [ map { [ @{$_}{@names} ] } values %col_info ],
NUM_OF_FIELDS => scalar @names,
NAME => \@names,
}) or return $dbh->DBI::set_err($sponge->err(), $sponge->errstr());
}
1;
__END__
Re: DBD::mysql - column_info() ?
On Sun, Feb 23, 2003 at 11:05:33AM +1100, Ron Savage wrote:
>
> 4) Starting at what is now line 295, we see:
> my $desc = $dbh->selectall_arrayref("DESCRIBE $table", {
> Columns=>{} });
> my $ordinal_pos = 0;
> foreach my $row (@$desc) {
>
> Inside this for loop, I changed all references from $row->{field} to
> $row->{Field}. This applies to all, repeat all, keys of %$row, not
> just Field. I can't image why you assume lower case keys here.
Because I was using:
$dbh->{FetchHashKeyName} = 'NAME_lc';
To make it general the code needs to be
my $desc_sth = $dbh->prepare("DESCRIBE $table");
$sth->{FetchHashKeyName} = 'NAME_lc';
my $desc = $dbh->selectall_arrayref($desc_sth, { Columns=>{} });
> 5) At the end of this sub, I added code to return something :-):
> \%col_info;
That's not right. It was returning the $sth (see the definition of column_info).
An explicit
return $sth;
would be better.
I'll make those changes to my version.
Thanks.
Tim.
DBD::ODBC for MySQL using MyODBC
I'd be very grateful if someone could send me the results from $dbh->column_info (using a recent DBD::ODBC with a recent MyODBC v3 driver) for a table containing just about every valid mysql data type (including an unsigned int). A csv file with column headings would be great. Please send just to me. I'll summarize to the list if anyone asks. Thanks! Tim.
Re: DBD::mysql - column_info() ?
On Tue, Feb 25, 2003 at 09:10:18AM +1100, Ron Savage wrote: > On Mon, 24 Feb 2003 09:22:09 +0000, Tim Bunce wrote: > >On Sun, Feb 23, 2003 at 11:05:33AM +1100, Ron Savage wrote: > > >>5) At the end of this sub, I added code to return something :-): > >>\%col_info; > > > >That's not right. It was returning the $sth (see the definition of > >column_info). > >An explicit > >return $sth; > >would be better. > > I expected it (Perl) to return the last expression, here $sth, but > that simply doesn't work, in the sense that the caller does not > reveive any information. Hence my brute force fix. Odd. I cut-n-pasted the code from a working system. Tim.
Using perl 5.8.0?
Anyone using perl 5.8.0? Jarkko and I would be interested in any feedback you may have. Obviously my main interest is with DBI and drivers but Jarkko's is wider. Please reply to Jarkko (CC'd) and then also CC me if your reply includes any feedback related to the DBI and/or the new signal handling in perl 5.8.0. Thanks. Tim. p.s. Jarkko, for those who don't know, maintains perl 5.8.0.
Re: Using perl 5.8.0?
On Tue, Feb 25, 2003 at 02:16:12PM +0100, Guillaume Rousse wrote: > Le Mardi 25 Février 2003 13:50, Tim Bunce a écrit : > > Anyone using perl 5.8.0? > Yes. > > > Jarkko and I would be interested in any feedback you may have. > > Obviously my main interest is with DBI and drivers but Jarkko's > > is wider. > > > > Please reply to Jarkko (CC'd) and then also CC me if your reply > > includes any feedback related to the DBI and/or the new signal > > handling in perl 5.8.0. > > You should be more explicit about what kind of feedback you expect. Anything you think might be of interest/value to us (the perl 5.8.0 and DBI maintainers) to help us make life better by fixing problems. > Apart one > problem of preivous version of Pg driver segfaulting when activating trace in > DB, everything else is fine. Tim.
Re: Using perl 5.8.0?
On Tue, Feb 25, 2003 at 01:26:03PM -, Steve Haslam wrote:
> Tim, Jarkko; my main problem with using perl 5.8 for our
> DBD::Oracle/DBD::Sybase apps is the inability to use signals to "time out"
> an operation. We have constructs like:
>
> eval {
> alarm(60);
> local $SIG{ALRM} = sub { $sth->cancel(); die "timeout" };
> $sth->execute();
> alarm(0);
> };
> if ($@ =~ /timeout/) {
> # ...
> }
>
> This works in 5.6.1, but not 5.8.0-- presumably because in 5.8.0, the signal
> handling just never runs the Perl handler until the execute() method returns
> to a safe point.
Funny you should mention that, as it's one of the issues that
prompted me to ask for feedback. Jarkko has been working on a way
to reenable the old signal handling:
See related threads here
http://archive.develooper.com/perl5-porters%40perl.org/
and the most recent patch here
http://archive.develooper.com/perl5-porters%40perl.org/msg92471.html
Tim.
Re: Using perl 5.8.0?
On Tue, Feb 25, 2003 at 09:13:47AM -0500, Thomas Good wrote: > On Tue, 25 Feb 2003, Tim Bunce wrote: > > > Anyone using perl 5.8.0? > > > > Jarkko and I would be interested in any feedback you may have. > > Obviously my main interest is with DBI and drivers but Jarkko's > > is wider. > > > > Please reply to Jarkko (CC'd) and then also CC me if your reply > > includes any feedback related to the DBI and/or the new signal > > handling in perl 5.8.0. > > > > Thanks. > > > > Tim. > > > > p.s. Jarkko, for those who don't know, maintains perl 5.8.0. > > While I was using 5.8 large data transfers via DBI failed consistently. > I have compared notes with others (including Lincoln Stein) and this > problem is easily reproduced. In fact, I can't stop reproducing it. ;-) > > I posted this on the DBI list awhile back and got no takers I must have missed it. Please send all the details to me ASAP. Thanks. A self-contained test case would be ideal! > so opted to > return to 5.6.1 until 5.8.0 is more stable or a patch repairs this > problem. I did no investigation as to why data transfer fails so > miserably (hangs until killed with an interrupt) as I simply don't have > the time or resources for experimentation - especially as I have found > 5.6.1 to be very solid. You might speak to Dr. Stein (regarding > causality) as he made me aware that this is a known problem. He related > to me that he also has returned to 5.6.1 on production equipment. I've CC'd Lincoln incase he can shed any extra light on the problem. Tim.
Re: DBI error handling
On Tue, Feb 25, 2003 at 03:14:24PM -0500, Michael Houghton wrote: > Howdy! > > I'm trying to write a WARN handler for an Informix application. > I want to be able to get to stuff in the SQLCA, which, if I read > things correctly, means I need the statement handle for the offending > action. > > I have not figured out how to get that without resorting to a global- > like variable. > > Is there some secret handshake that will let me obtain the last statement > handle that was invoked? $DBI::lasth will give you the last handle used to make a DBI call. But if that was a statement handle that's now been destroyed it'll return the parent dbh instead. Tim.
Re: Using perl 5.8.0?
On Tue, Feb 25, 2003 at 05:30:31PM -0500, Thomas Good wrote:
> On Tue, 25 Feb 2003, Tim Bunce wrote:
>
> > > While I was using 5.8 large data transfers via DBI failed consistently.
> > > I have compared notes with others (including Lincoln Stein) and this
> > > problem is easily reproduced. In fact, I can't stop reproducing it. ;-)
> > >
> > A self-contained test case would be ideal!
>
> Hi, I will try to put this together, meanwhile here is a summary:
>
> I have a postgres table with 220 individual patient skills -
> these skills become questions on a long form. Another table
> holding live patient records is queried and the returned values
> serve as popup_menu() defaults
>
> Tr ( td ( "$skill[0]" ) <-- Here is the string/question
> td ( popup_menu( ...
>-values=>['1 - Excellent', '2 - Adequate', '3 - Needs Attention',
> '4 - Needs Immediate Attention', '5 - Not Applicable'],
>-default=>"$row->{item_01}" <-- Here is the returned value
> ...
>
> On wellworn test equipment (all ide, 64M RAM, clock speed of 300MHz) running
> Slackware 8.1, perl 5.6.1, DBI 1.25, Apache 1.3.26, DBD-Pg 1.21, Postgres 7.3.1
> this script runs.
>
> On a brand new IBM eServer (LSI SCSI, 512M RAM, 2 GHz clock) running Redhat 8.0,
> perl 5.8.0, DBI 1.28, Apache 2.0.40, DBD-Pg 1.21 the script hangs.
> I tried commenting out the defaults, etc. Only removing both queries allowed
> the script to run. The CGI form was not a problem, even when I doubled the
> length as a test.
Enable tracing to a log file (eg set DBI_TRACE env var to something
like "6=/tmp/dbi.log") and then run the script using truss
(or similar tool that shows operating system calls).
As a (better) alternative to using truss you could do a kill -QUIT
on the process once it has hung and then get a stack trace from the
core file.
That would be useful, but to be *really* helpful the DBI and DBD::Pg
would need to be compiled and linked with debugging enabled (ie -g
option to the compiler/linker).
For the DBI you can do that by simply rebuilding it starting with
"perl Makefile.PL -g".
For DBD::Pg you may need to run "perl Makefile.PL" and then hack the
generated Makefile: Add -g as an option on the "CCCMD = $(CC) ..."
line and also to the "OTHERLDFLAGS =" line.
Once you've got the core file you can get a stack dump using a debugger
like gdb ("gdb /path/to/the/perl/you/used /path/to/core" then "bt".)
Tim.
Re: Using perl 5.8.0?
Ah, mentioning PerlIO and DBD::Oracle points the finger at the fact that DBD::Oracle hasn't been updated to use PerlIO for warnings/trace (at least not in the release on CPAN). That may be a factor. If DBD::Oracle needs to 'say' anything (which is very rare in normal operation) it'll be passing a PerlIO pointer to stdio functions. Any kind of damage could result. Tim. p.s. I'm about to release DBI 1.33 and I now have a new Sun box I can setup Oracle on so there's hope I can get back to DBD::Oracle development after an uncomfortable long period of, er, stability :) On Wed, Feb 26, 2003 at 11:10:43AM -0600, Neibarger Scott H wrote: > I'm afraid I can't offer any feedback that would be useful, other than the > fact that Lincoln is most likely correct that this problem is manifested due > to changes in PerlIO. I have several daemons running on Tivoli TMR servers, > many of which use DBI and DBD::Oracle; one of which is experiencing some > serious issues with memory leaks and internal corruption. I've scanned the > perlpod documentation for 5.8.0 only to find that there're several entries > mentioning memory leaks (in lexicals and anonymous subs) and internal > corruption (unsafe handling of signals). I'm in the process of preparing to > upgrade Perl from 5.005_03 to 5.8.0, which I'm hoping will solve the core > dumps and internal corruption I'm seeing in one of the daemons that performs > significantly more I/O operations than the others. > > I would like to take this moment to thank Lincoln Stein for his wonderful > book "Network Programming with Perl"; it's been a wonderful resource for me > on this current project. If you've not purchased it, support Dr. Stein and > buy his book! > > Scott H. Neibarger > SRA International, Inc. > IRS ESM project > 512-460-8717
(Fwd) DBI - the book
- Forwarded message from Fernando Luna <[EMAIL PROTECTED]> - Delivered-To: [EMAIL PROTECTED] Subject: DBI - the book Date: Wed, 26 Feb 2003 13:56:21 -0800 From: "Fernando Luna" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> There is the need at my organization to process DDL statements contained in a group of SQL files. I would like to know what the known limitations are concerning this, specifically: I am running perl version 5.005_03 built for AIX Unix. I have Oracle version 8.1.7 installed and running. I have AIX version 4.3.3.0 I have installed the DBI and DBD::Oracle modules... I am able to execute queries and PL/SQL blocks using these modules with no problems. What I'd like to do is read a file that contains DDL statements and execute them through these modules. These files contain specifically CREATE TABLE statements CREATE INDEX statements CREATE PACKAGE/PACKAGE BODY statements CREATE trigger statements CREATE VIEW statements In some cases, these files have more than one statement in them. (example, creating several indexes on a table)... These are taken from PVCS Version manager and I would like to be able to run them in one session and show the output (that is, if compilation or creation fails). I've searched the DBI and DBD documentation and I've not found anything that specifically addresses this. I tried running one CREATE TABLE statement and it appears to choke on some keywords that Oracle has no trouble with, but I suspect has to do with the fact that they are not necessarily ANSI-SQL compliant. Is this something that might be covered in this book or can you tell me if this just cannot be done with these modules? Thanks Fernando Luna - Seattle, WA - End forwarded message -
Re: Bug: DBI issues wrong (ie previous) SQL upon error
I believe this is due to DBD::mysql implementing its own do() method
that does not creat a statement handle.
I've worked around it by marking do (and prepare) as methods
that should trigger the $h->{Statement} to be cleared on entry.
That way if they don't set it before an error occurs then at least
the wrong statement won't be shown.
Thanks for the helpful test case.
Tim.
On Tue, Jan 07, 2003 at 07:54:16PM +1100, Ron Savage wrote:
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use DBI;
> my($dbh) = DBI->connect ( 'dbi:mysql:test', 'user', 'pass', {
> AutoCommit => 1,
> PrintError => 0,
> RaiseError => 1,
> ShowErrorStatement => 1,
> }
> );
> my($table_name) = 't';
> my($sql) = "drop table if exists $table_name";
> print "SQL: $sql. \n";
> $dbh->do($sql);
>
> $sql = "create table $table_name (t_id int)";
> print "SQL: $sql. \n";
> $dbh->do($sql);
>
> $sql = "insert into $table_name (t_id) values (?)";
> print "SQL: $sql. \n";
> my($sth) = $dbh->prepare($sql);
> $sth->execute(99);
> $sth->finish();
>
> $sql = "drop table if exists $table_name";
> print "SQL: $sql. \n";
> $dbh->do($sql);
>
> # Warning: The following SQL is invalid.
> # It should be "create table $table_name (t_id int)".
> $sql = "create $table_name (t_id int)";
> print "SQL: $sql. \n";
> # The following fails, but displays the SQL
> # "insert into $table_name (t_id) values (?)".
> # The DBI docs explicitly state (allege!) that
> # ShowErrorStatement applies to do().
> $dbh->do($sql);
Re: ANNOUNCE: DBI 1.33 (clarification of minimum perl version)
On Thu, Feb 27, 2003 at 11:32:43AM -, Clark, Ralph wrote: > Tim Bunce wrote: > > NOTE: Future versions of the DBI *will not* support perl 5.6.0 or earlier. > > : Perl 5.6.1 will be the minimum supported version. > > It sounds like "future versions" doesn't include the present 1.33 > release, i.e. 1.33 should still work with older versions. Tim can > you confirm that this new version is *expected* to work with eg. 5.6.0. It will. Anthing less than 5.6.1 will generate a warning when you run "perl Makefile.PL", but will still work on any perl >= 5.5.3. Tim.
Re: [Fwd: Re: ParamValues & Bind]
On Thu, Feb 27, 2003 at 05:37:40AM -0800, Jonathan Leffler wrote:
>
> Date: Thu, 27 Feb 2003 05:37:00 -0800
> From: Jonathan Leffler <[EMAIL PROTECTED]>
> Organization: Chaotic Sputterings
> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021120
> Netscape/7.01
> X-Accept-Language: en-us, en
> To: Rudy Lippan <[EMAIL PROTECTED]>
> Subject: Re: ParamValues & Bind
>
> Rudy Lippan wrote:
> >On Wed, 26 Feb 2003, Tim Bunce wrote:
> >>Rudy Lippan wrote:
> >>>I know there is a {NUM_OF_PARAMS} attribute and a {ParamValues}
> >>>attribute,
> >>>but is there a way to get the names of :foo style params before they are
> >>>bound?
> >>
> >>Umm, not officially currently but there's a good chance that keys
> >>%{$sth->{ParamValues}} would work on many drivers that support it.
> >>
> >>I'll add a note to that effect in the docs so that'll become the
> >>standard way.
>
> Please don't. Some drivers are completely unable to support named
> placeholders. Specifically, DBD::Informix cannot. The notations :xxx
> and :23 can both appear outside quoted strings in contexts that do not
> have anything to do with placeholders. DBD::Informix uses its own
> pre-parser code for the same reason -- only question mark placeholders
> can work reliably. And I am 99% sure that only question marks are
> sanctioned by ODBC...
That's actually not the issue at all.
As I understand it Rudy just wanted to be able to find out what
placeholders exist in a prepared statement:
$sth = $dbh->prepare("select * from table where id = ?");
print "Has placeholder $_\n" for keys %{$sth->{ParamValues}}
would print "Has placeholder 1".
The previous specification did not make clear at what point
$sth->{ParamValues} would contain anything useful. It now says:
=item C (hash ref, read-only)
Returns a reference to a hash containing the values currently bound
to placeholders. The keys of the hash are the 'names' of the
placeholders, typically integers starting at 1. Returns undef if
not supported by the driver.
See L for an example of how this is used.
-> If the driver supports C but no values have been bound
-> yet then the driver should return a hash with placeholders names
-> in the keys but all the values undef, but some drivers may return
-> a ref to an empty hash.
It is possible that the values in the hash returned by C
are not exactly the same as those passed to bind_param() or execute().
The driver may have modified the values in some way based on the
TYPE the value was bound with. For example a floating point value
bound as an SQL_INTEGER type may be returned as an integer.
It is also possible that the keys in the hash returned by C
are not exactly the same as those implied by the prepared statement.
For example, DBD::Oracle translates 'C' placeholders into 'C<:pN>'
where N is a sequence number starting at 1.
> SELECT * FROM [EMAIL PROTECTED]:owner.table WHERE somecolumn BETWEEN
> DATETIME(1970:01:01 00:00:00) YEAR TO SECOND AND
> DATETIME(1999:12:31 23:59:29) YEAR TO SECOND
>
> There are no placeholders in that - but there's a :owner and eight :NN
> values in it.
If DBD::Informix parses no placeholders then DBD::Informix
simply won't put any information into $sth->{ParamValues}.
I see no problem here.
> >>A slight downside is that it won't be possible to tell the difference
> >>between a placeholder that's not been bound and one that has but
> >>was bound to undef. But I don't think that'll be a big issue.
> >>Anyone disagree?
>
> If the system will automatically bind undef for any placeholders that
> have not had an explicit value bound to them, then it should be OK.
I don't think the DBI mandates a behaviour other than execute(...)
must have no values or all values. But I don't think execute() with
no values and bind_param() calls not made for all placeholders is
explicitly defined as an error. I know that DBD::Oracle will fail
due to an error at the Oracle OCI API level.
> Otherwise, it could be problematic - people do have to explicitly bind
> NULL/undef on occasion.
Sure. The issue is only whether people *need* to be able to use
$sth->{ParamValues} to tell if a values has been bound or not.
I don't think so. If that's needed then the app can track it itself.
Tim.
Re: DBI 1.33 fail on Windows, ActiveState Perl 804 (5.8.0)
On Thu, Feb 27, 2003 at 11:10:22AM -0500, Jeff Urlwin wrote:
> Tim,
>
> There's probably a deeper timing issue on these that's causing the
> issues, but I thought I'd let you know:
> 1) The following fails on my machine:
> t/40profile.t line 93
>
> ok($total > $longest);
>
> In this case, $total == $longest .. Not sure what the test is
> really trying to do or show or where it really is...but >= will "fix" it
> here...(or hide it)
>
> Here's the output from Data::Dumper that leads to the problem. If I
> read this correctly, the total time is also the same as the longest
> time...
>
> bless( {
> 'Path' => [
> '-210001'
> ],
> 'Data' => {
> '' => [
> 5,
> '0',
> '0',
> '0',
> '0',
> '1046361110.89142',
> '1046361110.90143'
> ],
> 'select mode,size,name from ?' => [
> 40,
> '0.0100140571594238',
> '0',
> '0',
> '0.0100140571594238',
> '1046361110.89142',
> '1046361110.90143' (took 0.01001 seconds)
> ]
> }
> }, 'DBI::Profile' )
Seems that either your 'high resolution time' isn't very high
resolution, or your machine is very fast :) I suspect the former.
What's your operating system? (and perl -V output?)
And, out of interest, what's the spec of your machine? (cpu/memory etc)
What does this say:
$ perl -MDBI=dbi_time -e '$a=dbi_time; 1 while (dbi_time eq $a); $a=dbi_time;++$c
while (dbi_time eq $a); warn "$a\n$c\n".dbi_time'
1046365974.8218
1
1046365974.82187
The 1 in the middle line is often missing, meaning that dbi_time
produces a different value faster than the loop loops.
If I change the "eq"'s to "==" then I can't even get a 1 to appear.
Also, try changing
! while ( my $hash = $sth->fetchrow_hashref ) {}
to
! for my $loop (1..100) {
! $sth->execute(".");
! while ( my $hash = $sth->fetchrow_hashref ) {}
! }
and see if it helps.
> 2) t/42prof_data.t test 6 ok($nodes->[0][4] < $longest);
> Fails. Both values are 0.00 here...until I change the test and add
> Data::Dumper prints between sorts and tests.
Uh. Why should Data::Dumper prints make a difference?
> Let me know if you want any more details/analysis. This is a quick
> check
You could add a loop around the
$sth->execute(".");
$sth->fetchrow_hashref;
$sth->finish;
so it does more work, and see if that helps.
Thanks.
Tim.
Re: DBI 1.33 fail on Windows, ActiveState Perl 804 (5.8.0)
On Thu, Feb 27, 2003 at 12:52:24PM -0500, Jeff Urlwin wrote:
> Too many questions :)
:)
> > What's your operating system? (and perl -V output?)
> > And, out of interest, what's the spec of your machine?
> > (cpu/memory etc)
>
> Windows XP service pack 1.
> Pentium 4 (mobile), 2.2 Ghz
> 1 GB RAM
>
> > What does this say:
> > $ perl -MDBI=dbi_time -e '$a=dbi_time; 1 while (dbi_time eq
> > $a); $a=dbi_time;++$c while (dbi_time eq $a); warn
> > "$a\n$c\n".dbi_time' 1046365974.8218 1
> > 1046365974.82187
>
> I changed it to a separate script since I'm under windows and the
> command shell is a pain, but I don't think I changed semantics on it:
>
> use DBI qw(dbi_time);
> my $a=dbi_time;
> 1 while (dbi_time == $a);
> $a=dbi_time;
> ++$c while (dbi_time == $a);
> warn "$a\n$c\n".dbi_time;
>
> With eq
>
> 1046367427.69059
> 1058
> 1046367427.7006
>
> > The 1 in the middle line is often missing, meaning that
> > dbi_time produces a different value faster than the loop
> > loops. If I change the "eq"'s to "==" then I can't even get a
> > 1 to appear.
> >
>
> With ==
>
> 1046367479.27631
> 5547
> 1046367479.28632 at t.pl line 7.
Seems the problem is that Windows has a lower 'hi res' time resolution.
My machine only gets round the loop once between 'ticks' of the time
but your can do thousands of loops.
[...later...] Ah, I could have saved us the bother if I'd looked
at the code...
static double
dbi_time() {
# ifdef HAS_GETTIMEOFDAY
struct timeval when;
gettimeofday(&when, (struct timezone *) 0);
return when.tv_sec + (when.tv_usec / 100.0);
# else /* per-second is almost useless */
# ifdef _WIN32 /* use _ftime() on Win32 (MS Visual C++ 6.0) */
struct _timeb when;
_ftime( &when );
return when.time + (when.millitm / 1000.0);
# else
return time(NULL);
# endif
# endif
}
So windows _ftime only has millisecond resolution (whereas unix
gettimeofday has nanosecond resolution, at least in theory).
Okay, I'll add the loops to the tests and document the lower resolution on
Windows.
Could you do some experimentation for me to determine the smallest
numer of loops that avoid the problem on your system? I'll then use
some multiple of that as a safety margin. (Just email me direct and
include a copy of your edited test files. Thanks.)
Tim.
Re: bind_param "success" when it should fail
On Thu, Feb 27, 2003 at 04:01:40PM -0500, Roels, Steven wrote:
>
> Tim,
>
> Did the following get fixed in 1.33? I didn't see it in the release
> notes, but its such a minor thing I wouldn't really expect to have seen
> it there.
It's a DBD::Oracle issue, not DBI.
Tim.
> >> Specifically, I had accidentally given bind_param an array reference
> >> rather than a scalar. I would expect (and this was the case with an
> >> earlier version of the DBI), to get an exception. Instead, although DBI
> >> seems to still consider it a mistake (you get the warning message about
> >> "Can't bind array reference..."), bind_param itself "succeeds" (returns
> >> true with raiseerror off, or does not throw an exception with raiseerror
> >> on).
> >>
> >> Thanks in advance,
> >>
> >> -Steve
> >>
> >> #!/usr/bin/perl -W
> >>
> >> use strict;
> >>
> >> use DBI;
> >>
> >> my $dbh = DBI->connect( "dbi:Oracle:#","##","",
> >> {AutoCommit => 0,RaiseError => 1,PrintError => 0,LongReadLen =>
> >> 500,LongTruncOk => 0});
> >>
> >> my $sql = "SELECT blah blah blah where mykey = ?";
> >>
> >> my $sth = $dbh->prepare($sql);
> >>
> >> $sth->bind_param(1,[1,2,3,4]);
> >>
> >> print "possible err: ",$sth->errstr(),"\n";
> >>
> >> print "I guess bind param went OK...\n";
> >>
> >> $sth->execute();
> >>
> >> $sth->finish();
> >>
> >> $dbh->disconnect();
Re: DBI-1.33 & DBD::Oracle 1.12
On Thu, Feb 27, 2003 at 05:01:56PM -0500, Jeff Urlwin wrote: > Tim, > > I hate to say this, but, DBD::Oracle (here) doesn't work with DBI 1.33... > Dbd_discon_all needs to be defined. Thanks. What's the exact error message? Tim.
Re: Trying to build a new perl with DBI statically linked to it
Fix your perl. Reconfigure and rebuild it so it does support dynamic loading (Otherwise you're just heading into a whole world of pain and frustration.) Tim. On Fri, Feb 28, 2003 at 02:53:35PM -, Chris Bucchere wrote: > Hi Frans, > > When I wrote and ran the simple script with only "use DBI" in > it, I got the same error: > > Can't load module DBI, dynamic loading not available in this perl. > (You may need to build a new perl executable which either supports > dynamic loading or has the DBI module statically linked into it.) > at /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/DBI.pm line 256 > BEGIN failed--compilation aborted at > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/DBI.pm line 256. > Compilation failed in require at test.pl line 1. > BEGIN failed--compilation aborted at test.pl line 1. > > You wrote: > > > if you want to build something staticly you have to use a different > > 'make' command after having run 'perl Makefile.PL'. > > Do you know exactly what make command I need to use. I've given up on > dynamic loading -- sorry! > > BTW, I'm using Solaris with MySQL. > > Thanks! > > Chris Bucchere > Bucchere Development Group > [EMAIL PROTECTED] > 415.516.3941 > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, February 28, 2003 2:45 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Trying to build a new perl with DBI statically linked to it > > Hmm, > > I would first try to check if perl itself does load DBI at all. > > i.e. a small script with only 'use DBI;' in it. > > I'm not too trusting of the install/check script there telling you perl > can't load dynamic. For starters, I would think MakeMaker would tell you > that when trying to install DBI/DBD dynamicly. > > Building 'staticly' means you really include the DBI/DBD modules INTO > your > perl binary. Makes for difficult upgrades and other troubles, you really > should try to get dynamic to work, spend some time on it if nessecary. > > I never use CPAN-Shell (company network) but if you want to build > something > staticly you have to use a different 'make' command after having run > 'perl > Makefile.PL'. I think you can force CPAN-Shell to re-install a module, > that > would include testing which would be nice to confirm if perl itself > works > with DBI at least. (you need to specify a username/password for most DBD > tests) > > What OS and database are you using ? > > --- > Frans Postma, (050-58) 81 852 > ATOS Origin, Unix Support > "If at first you don't succeed, skydiving isn't for you" > > > > > > -Oorspronkelijk bericht- > > Van: Chris Bucchere [mailto:[EMAIL PROTECTED] > > Verzonden: vrijdag 28 februari 2003 15:32 > > Aan: [EMAIL PROTECTED] > > CC: [EMAIL PROTECTED] > > Onderwerp: RE: Trying to build a new perl with DBI statically > > linked to > > it > > > > > > Hi Frans, > > > > I've done this using CPAN's automatic installation. Check this > > out: > > > > %> perl -MCPAN -e'install "DBD::mysql"' > > CPAN: Storable loaded ok > > Going to read /.cpan/Metadata > > Database was generated on Thu, 27 Feb 2003 16:40:43 GMT > > DBD::mysql is up to date. > > > > %>perl -MCPAN -e'install "DBI"' > > CPAN: Storable loaded ok > > Going to read /.cpan/Metadata > > Database was generated on Thu, 27 Feb 2003 16:40:43 GMT > > DBI is up to date. > > > > I think there's more to it than just installing because I'm > > still getting this error message: > > > > [Fri Feb 28 14:27:08 2003] checksetup.pl: [Fri Feb 28 14:27:08 2003] > > checksetup.pl: Can't load module DBI, dynamic loading not available in > > this perl. > > [Fri Feb 28 14:27:08 2003] checksetup.pl: [Fri Feb 28 14:27:08 2003] > > checksetup.pl: (You may need to build a new perl executable which > > either supports > > [Fri Feb 28 14:27:08 2003] checksetup.pl: [Fri Feb 28 14:27:08 2003] > > checksetup.pl: dynamic loading or has the DBI module > > statically linked > > into it.) > > [Fri Feb 28 14:27:08 2003] checksetup.pl: [Fri Feb 28 14:27:08 2003] > > checksetup.pl: at > > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/DBI.pm line 256 > > [Fri Feb 28 14:27:08 2003] checksetup.pl: [Fri Feb 28 14:27:08 2003] > > checksetup.pl: BEGIN failed--compilation aborted at > > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/DBI.pm line 256. > > [Fri Feb 28 14:27:08 2003] checksetup.pl: [Fri Feb 28 14:27:08 2003] > > checksetup.pl: Compilation failed in require at globals.pl line 76. > > [Fri Feb 28 14:27:08 2003] checksetup.pl: [Fri Feb 28 14:27:08 2003] > > checksetup.pl: BEGIN failed--compilation aborted at > > globals.pl line 76. > > [Fri Feb 28 14:27:08 2003] checksetup.pl: Compilation failed > > in require > > at checksetup.pl line 617. > > > > Keep in mind that I've already tried compiling perl with dynamic > > loading and Bugzilla did not recognize the DBD::mysql or DBI > >
Re: Cannot make DBI on perl 5.8.0
Built with 5.8.0 (thread-multi) for me. The message looks like a compiler bug. You could try DBI 1.34 which is winging it way to CPAN, announcement to follow... Tim. On Fri, Feb 28, 2003 at 02:25:06PM -0600, Bobby Garza wrote: > Tim, > > Here is my error message: > > ---snip--- > [EMAIL PROTECTED] DBI-1.33]# make > gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 > -march=i386 -mcpu=i686 -DVERSION=\"1.33\" -DXS_VERSION=\"1.33\" -fpic > "-I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" -Wall > -Wno-comment DBI.c > -bash: [EMAIL PROTECTED]: command not found > DBI.xs: In function `dbi_profile': > DBI.xs:1981: internal error: Floating point exception > Please submit a full bug report, > with preprocessed source if appropriate. > See http://bugzilla.redhat.com/bugzilla/> for instructions. > make: *** [DBI.o] Error 1 > ---snip--- > > Here is my perl version info: > > ---snip--- > [EMAIL PROTECTED] DBI-1.33]# perl -V > Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: > Platform: > osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi > uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 > 06:41:59 edt 2002 i686 i686 i386 gnulinux ' > config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 > -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red > Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux > -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads > -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db > -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio > -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less > -isr' > hint=recommended, useposix=true, d_sigaction=define > usethreads=define use5005threads=undef useithreads=define > usemultiplicity=define > useperlio=define d_sfio=undef uselargefiles=define usesocks=undef > use64bitint=undef use64bitall=undef uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', > optimize='-O2 -march=i386 -mcpu=i686', > cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing > -I/usr/include/gdbm' > ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide > 3.2-5)', gccosandvers='' > intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=4, prototype=define > Linker and Libraries: > ld='gcc', ldflags =' -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib > libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil > perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil > libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so > gnulibc_version='2.2.92' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic > -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' > cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' > > > Characteristics of this binary (from libperl): > Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES > PERL_IMPLICIT_CONTEXT > Built under linux > Compiled at Sep 1 2002 23:56:49 > @INC: > /usr/lib/perl5/5.8.0/i386-linux-thread-multi > /usr/lib/perl5/5.8.0 > /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi > /usr/lib/perl5/site_perl/5.8.0 > /usr/lib/perl5/site_perl > /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.8.0 > /usr/lib/perl5/vendor_perl > > ---snip--- > > > I'm sure I've done something dumb but I haven't spent too much time > debugging yet... > > Much thanks in advance... > > Bobby Garza >
Re: FAIL DBI-1.32_90 i586-linux 2.2.16c32_iii
Thanks.
I've included it as a known problem (for people who have installed
Tom Lowery's DBI::Shell) in the release notes for DBI 1.33, which
is now on cpan.
Tim.
On Wed, Feb 26, 2003 at 09:29:26PM +0100, Jeroen Latour wrote:
> This distribution has been tested as part of the cpan-testers
> effort to test as many new uploads to CPAN as possible. See
> http://testers.cpan.org/
>
> Please cc any replies to [EMAIL PROTECTED] to keep other
> test volunteers informed and to prevent any duplicate effort.
>
> --
> This is an error report generated automatically by CPANPLUS,
> version 0.042.
>
> Below is the error stack during 'make test':
>
> PERL_DL_NONLAZY=1 /home/local/bin/perl5.8.0 "-MExtUtils::Command::MM" "-e"
> "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
> t/01basics.Argument "1.32_90" isn't numeric in numeric gt (>) at
> t/01basics.t line 55.
> ok
> t/02dbidrv.ok
> t/03hleak..ok
> t/04mods...ok
> t/05thrclone...skipped
> all skipped: this perl 5.008 not configured to support iThreads
> t/06attrs..ok
> t/07kids...ok
> t/08keeperrok
> t/10examp..ok
> t/15array..ok
> t/20meta...ok
> t/30subclass...ok
> t/40profileok
> t/41prof_dump..ok
> t/42prof_data..ok
> t/60preparse...ok
> t/70shell..Argument "1.32_90" isn't numeric in subroutine entry at
> /home/spool/cpanplus/5.8.0/build/DBI-1.32_90/blib/lib/DBI/Shell.pm line 76.
> Can't locate object method "install_options" via package "DBI::Shell::Std" at
> /usr/local/lib/perl5/site_perl/5.8.0/DBI/Shell/Timing.pm line 16.
> dubious
> Test returned status 255 (wstat 65280, 0xff00)
> DIED. FAILED test 3
> Failed 1/3 tests, 66.67% okay
> t/80proxy..skipped
> all skipped: modules required for proxy are probably not installed
> t/zz_01basics_pp... Using DBI::PurePerl (DBI_PUREPERL=2)
> Argument "1.32_90" isn't numeric in numeric gt (>) at t/01basics.t line 55.
> ok
> t/zz_02dbidrv_pp...ok
> t/zz_03hleak_ppok
> t/zz_04mods_pp.ok
> t/zz_05thrclone_pp.skipped
> all skipped: this perl 5.008 not configured to support iThreads
> t/zz_06attrs_ppok
> t/zz_07kids_pp.skipped
> all skipped: $h->{Kids} attribute not supported for DBI::PurePerl
> t/zz_08keeperr_pp..ok
> t/zz_10examp_pp Taint mode switching tests skipped
> Taint attribute tests skipped
> ok
> t/zz_15array_ppok
> t/zz_20meta_pp.ok
> t/zz_30subclass_pp.ok
> t/zz_40profile_pp..skipped
> all skipped: profiling not supported for DBI::PurePerl
> t/zz_41prof_dump_ppskipped
> all skipped: profiling not supported for DBI::PurePerl
> t/zz_42prof_data_ppskipped
> all skipped: profiling not supported for DBI::PurePerl
> t/zz_60preparse_pp.skipped
> all skipped: preparse not supported for DBI::PurePerl
> t/zz_70shell_ppArgument "1.32_90" isn't numeric in subroutine entry at
> /home/spool/cpanplus/5.8.0/build/DBI-1.32_90/blib/lib/DBI/Shell.pm line 76.
> Can't locate object method "install_options" via package "DBI::Shell::Std" at
> /usr/local/lib/perl5/site_perl/5.8.0/DBI/Shell/Timing.pm line 16.
> ...caught at t/zz_70shell_pp.t line 3.
> Can't locate object method "install_options" via package "DBI::Shell::Std" at
> /usr/local/lib/perl5/site_perl/5.8.0/DBI/Shell/Timing.pm line 16.
> ...caught ...propagated at t/zz_70shell_pp.t line 4.
> dubious
> Test returned status 255 (wstat 65280, 0xff00)
> DIED. FAILED test 3
> Failed 1/3 tests, 66.67% okay
> t/zz_80proxy_ppskipped
> all skipped: modules required for proxy are probably not installed
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
> t/70shell.t255 65280 31 33.33% 3
> t/zz_70shell_pp.t 255 65280 31 33.33% 3
> 9 tests skipped.
> Failed 2/36 test scripts, 94.44% okay. 2/1140 subtests failed, 99.82% okay.
> make: *** [test_dynamic] Error 29
>
>
> Additional comments:
>
> --
>
> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
> Platform:
> osname=linux, osvers=2.2.16c32_iii, archname=i586-linux
> uname='linux www.arens.nl 2.2.16c32_iii #1 fri nov 9 21:54:54 pst 2001 i586
> unknown '
> config_args='-Uinstallusrbinperl -ds'
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
> useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=undef uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
> Compiler:
> cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -I/usr/includ
Re: CPAN Upload: T/TI/TIMB/DBI-1.33.tar.gz -- test problem on MacOS X and Perl 5.8.0
On Wed, Feb 26, 2003 at 10:18:34PM -0800, Jonathan Leffler wrote: > PAUSE wrote: > >The uploaded file > > > >DBI-1.33.tar.gz > > > >has entered CPAN as > > > > file: $CPAN/authors/id/T/TI/TIMB/DBI-1.33.tar.gz > > > t/70shell..Can't locate object method "init" via package > "DBI::Shell::FindSqlFile" at /Users/jleffler/tmp/DBI-1.33/blib/ > lib/DBI/Shell.pm line 141. That's probably because you got the new DBI shell from Tom Lower installed and some of it's plugins are not compatible. I'll probably just drop DBI::Shell from the distribution (but list it in the bundle file) for now since Tom's newer version is much better and we're bound to keep running into problems. Thanks for the report. Tim.
ANNOUNCE: DBI 1.34
file: $CPAN/authors/id/T/TI/TIMB/DBI-1.34.tar.gz
size: 290116 bytes
md5: f0056760bea3d5697c21d64358617895
NOTE: Future versions of the DBI *will not* support perl 5.6.0 or earlier.
: Perl 5.6.1 will be the minimum supported version.
NOTE: The "old-style" connect: DBI->connect($database, $user, $pass, $driver);
: has been deprecated for several years and will now generate a warning.
: It will be removed in a later release. Please change any old connect() calls.
=head2 Changes in DBI 1.34,28th February 2003
Fixed DBI::DBD docs to refer to DBI::DBD::Metadata thanks to Jonathan Leffler.
Fixed dbi_time() compile using BorlandC on Windows thanks to Steffen Goeldner.
Fixed profile tests to do enough work to measure on Windows.
Fixed disconnect_all() to not be required by drivers.
Added $okay = $h->can($method_name) to check if a method exists.
Added DBD::*::*->install_method($method_name, \%attr) so driver private
methods can be 'installed' into the DBI dispatcher and no longer
need to be called using $h->func(..., $method_name).
Enhanced $dbh->clone() and documentation.
Enhanced docs to note that dbi_time(), and thus profiling, is limited
to only millisecond (seconds/1000) resolution on Windows.
Removed old DBI::Shell from distribution and added Tom Lowery's improved
version to the Bundle::DBI file.
Updated minimum version numbers for modules in Bundle::DBI.
=head2 Changes in DBI 1.33,27th February 2003
Added $dbh2 = $dbh1->clone to make a new connection to the database
that is identical to the original one. clone() can be called even after
the original handle has been disconnected. See the docs for more details.
Fixed merging of profile data to not sum DBIprof_FIRST_TIME values.
Fixed unescaping of newlines in DBI::ProfileData thanks to Sam Tregar.
Fixed Taint bug with fetchrow_hashref with help from Bradley Baetz.
Fixed $dbh->{Active} for DBD::Proxy, reported by Bob Showalter.
Fixed STORE to not clear error during nested DBI call,
thanks to Tony Bowden for the report and helpful test case.
Fixed DBI::PurePerl error clearing behaviour.
Fixed dbi_time() and thus DBI::Profile on Windows thanks to Smejkal Petr.
Fixed problem that meant ShowErrorStatement could show wrong statement,
thanks to Ron Savage for the report and test case.
Changed Apache::DBI hook to check for $ENV{MOD_PERL} instead of
$ENV{GATEWAY_INTERFACE} thanks to Ask Bjoern Hansen.
No longer tries to dup trace logfp when an interpreter is being cloned.
Database handles no longer inherit shared $h->err/errstr/state storage
from their drivers, so each $dbh has it's own $h->err etc. values
and is no longer affected by calls made on other dbh's.
Now when a dbh is destroyed it's err/errstr/state values are copied
up to the driver so checking $DBI::errstr still works as expected.
Build / portability fixes:
Fixed t/40profile.t to not use Time::HiRes.
Fixed t/06attrs.t to not be locale sensitive, reported by Christian Hammers.
Fixed sgi compiler warnings, reported by Paul Blake.
Fixed build using make -j4, reported by Jonathan Leffler.
Fixed build and tests under VMS thanks to Craig A. Berry.
Documentation changes:
Documented $high_resolution_time = dbi_time() function.
Documented that bind_col() can take an atribute hash.
Clarified documentation for ParamValues attribute hash keys.
Many good DBI documentation tweaks from Jonathan Leffler,
including a major update to the DBI::DBD driver author guide.
Clarified that execute() should itself call finish() if it's
called on a statement handle that's still active.
Clarified $sth->{ParamValues}. Driver authors please note.
Removed "NEW" markers on some methods and attributes and
added text to each giving the DBI version it was added in,
if it was added after DBI 1.21 (Feb 2002).
Changes of note for authors of all drivers:
Added SQL_DATA_TYPE, SQL_DATETIME_SUB, NUM_PREC_RADIX, and
INTERVAL_PRECISION fields to docs for type_info_all. There were
already in type_info(), but type_info_all() didn't specify the
index values. Please check and update your type_info_all() code.
Added DBI::DBD::Metadata module that auto-generates your drivers
get_info and type_info_all data and code, thanks mainly to
Jonathan Leffler and Steffen Goeldner. If you've not implemented
get_info and type_info_all methods and your database has an ODBC
driver available then this will do all the hard work for you!
Drivers should no longer pass Err, Errstr, or State to _new_drh
or _new_dbh functions.
Please check that you support the slightly modified behaviour of
$sth->{ParamValues}, e.g., always return hash with keys if possible.
Changes of note for authors of compiled drivers:
Added dbd_db_login6 & dbd_st_finish3 prototypes thanks to Jonathan Leffler.
All db
ANNOUNCE: DBI 1.33
file: $CPAN/authors/id/T/TI/TIMB/DBI-1.33.tar.gz
size: 299066 bytes
md5: c6a737c990bc59f95c34657ec72ac68a
=head2 Changes in DBI 1.33,27th February 2003
NOTE: Future versions of the DBI *will not* support perl 5.6.0 or earlier.
: Perl 5.6.1 will be the minimum supported version.
NOTE: The "old-style" connect: DBI->connect($database, $user, $pass, $driver);
: has been deprecated for several years and will now generate a warning.
: It will be removed in a later release. Please change any old connect() calls.
Added $dbh2 = $dbh1->clone to make a new connection to the database
that is identical to the original one. clone() can be called even after
the original handle has been disconnected. See the docs for more details.
Fixed STORE to not clear error during nested DBI call,
thanks to Tony Bowden for the report and helpful test case.
Fixed problem that meant ShowErrorStatement could show wrong statement,
on some drivers thanks to Ron Savage for the report and test case.
Fixed merging of profile data to not sum DBIprof_FIRST_TIME values.
Fixed unescaping of newlines in DBI::ProfileData thanks to Sam Tregar.
Fixed Taint bug with fetchrow_hashref with help from Bradley Baetz.
Fixed $dbh->{Active} for DBD::Proxy, reported by Bob Showalter.
Fixed DBI::PurePerl error clearing behaviour.
Fixed dbi_time() and thus DBI::Profile on Windows thanks to Smejkal Petr.
Changed Apache::DBI hook to check for $ENV{MOD_PERL} instead of
$ENV{GATEWAY_INTERFACE} thanks to Ask Bjoern Hansen.
No longer tries to dup trace logfp when interpreter thread is cloned.
Database handles no longer inherit shared $h->err/errstr/state storage
from their drivers, so each $dbh has it's own $h->err etc. values
and is no longer affected by calls made on other dbh's.
Now when a dbh is destroyed it's err/errstr/state values are copied
up to the driver so checking $DBI::errstr still works as expected.
Build / portability fixes:
Fixed t/40profile.t to not use Time::HiRes.
Fixed t/06attrs.t to not be locale sensitive, reported by Christian Hammers.
Fixed sgi compiler warnings, reported by Paul Blake.
Fixed build using make -j4, reported by Jonathan Leffler.
Fixed build and tests under VMS thanks to Craig A. Berry.
Documentation changes:
Documented $high_resolution_time = dbi_time() function.
Documented that bind_col() can take an atribute hash.
Clarified documentation for ParamValues attribute hash keys.
Many good DBI documentation tweaks from Jonathan Leffler,
including a major update to the DBI::DBD driver author guide.
Clarified that execute() should itself call finish() if it's
called on a statement handle that's still active.
Clarified $sth->{ParamValues}. Driver authors please note.
Removed "NEW" markers on some methods and attributes and
added text to each giving the DBI version it was added in,
if it was added after DBI 1.21 (Feb 2002).
Changes of note for authors of all drivers:
Added SQL_DATA_TYPE, SQL_DATETIME_SUB, NUM_PREC_RADIX, and
INTERVAL_PRECISION fields to docs for type_info_all. There were
already in type_info(), but type_info_all() didn't specify the
index values. Please check and update your type_info_all() code.
Added DBI::DBD::Metadata module that auto-generates your drivers
get_info and type_info_all data and code, thanks mainly to
Jonathan Leffler and Steffen Goeldner. If you've not implemented
get_info and type_info_all methods and your database has an ODBC
driver available then this will do all the hard work for you!
Drivers should no longer pass Err, Errstr, or State to _new_drh
or _new_dbh functions.
Please check that you support the slightly modified behaviour of
$sth->{ParamValues}, e.g., always return hash with keys if possible.
Changes of note for authors of compiled drivers:
Added dbd_db_login6 & dbd_st_finish3 prototypes thanks to Jonathan Leffler.
All dbd_*_*() functions implemented by drivers must have a
corresponding #define dbd_*_* _*_* otherwise
the driver may not work with a future release of the DBI.
Changes of note for authors of drivers which use Driver.xst:
Some new method hooks have been added are are enabled by
defining corresponding macros:
$drh->data_sources() - dbd_dr_data_sources
$dbh->do()- dbd_db_do4
The following methods won't be compiled into the driver unless
the corresponding macro has been #defined:
$drh->disconnect_all()- dbd_discon_all
Known issues with this release:
If you have installed Tom Lowery's improved version of DBI::Shell
there's a chance that the t/70shell.t tests will fail.
That can be ignored. Future releases of the DBI will not include
the old DBI::Shell anymore. Meanwhile you should reinstall
Tom's DBI::Shell after installing this DBI relea
Re: FAIL DBI-1.33 MSWin32-x86-multi-thread 4.0
Thanks. Known problem (due to windows time having less resolution). Will be fixed in the next release (in a day or so). Tim. On Fri, Feb 28, 2003 at 12:10:09AM -0800, DH wrote: > This distribution has been tested as part of the cpan-testers > effort to test as many new uploads to CPAN as possible. See > http://testers.cpan.org/ > > Please cc any replies to [EMAIL PROTECTED] to keep other > test volunteers informed and to prevent any duplicate effort. > > -- > > E:\new\DBI-1.33>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://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 extra DBI::PurePerl test: t/zz_01basics_pp.t > Creating extra DBI::PurePerl test: t/zz_02dbidrv_pp.t > Creating extra DBI::PurePerl test: t/zz_03hleak_pp.t > Creating extra DBI::PurePerl test: t/zz_04mods_pp.t > Creating extra DBI::PurePerl test: t/zz_05thrclone_pp.t > Creating extra DBI::PurePerl test: t/zz_06attrs_pp.t > Creating extra DBI::PurePerl test: t/zz_07kids_pp.t > Creating extra DBI::PurePerl test: t/zz_08keeperr_pp.t > Creating extra DBI::PurePerl test: t/zz_10examp_pp.t > Creating extra DBI::PurePerl test: t/zz_15array_pp.t > Creating extra DBI::PurePerl test: t/zz_20meta_pp.t > Creating extra DBI::PurePerl test: t/zz_30subclass_pp.t > Creating extra DBI::PurePerl test: t/zz_40profile_pp.t > Creating extra DBI::PurePerl test: t/zz_41prof_dump_pp.t > Creating extra DBI::PurePerl test: t/zz_42prof_data_pp.t > Creating extra DBI::PurePerl test: t/zz_60preparse_pp.t > Creating extra DBI::PurePerl test: t/zz_70shell_pp.t > Creating extra DBI::PurePerl test: t/zz_80proxy_pp.t > Checking if your kit is complete... > Looks good > Writing Makefile for DBI > > 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. > > Windows users need to use the correct make command. > That may be nmake or dmake depending on which Perl you are using. > If using the Win32 ActiveState build then it is recommended that you > use the ppm utility to fetch and install a prebuilt DBI instead. > > E:\new\DBI-1.33>nmake test TEST_VERBOSE=1 > > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > C:\Perl\bin\perl.exe -MExtUtils::Command -e mkpath blib\lib\DBI > C:\Perl\bin\perl.exe -MExtUtils::Command -e rm_f blib\lib\DBI\Changes.pm > C:\Perl\bin\perl.exe -MExtUtils::Command -e cp Changes > blib\lib\DBI\Changes.pm > cp Driver_xst.h blib\arch\auto\DBI\Driver_xst.h > cp lib/DBI/ProfileDumper.pm blib\lib\DBI/ProfileDumper.pm > cp DBIXS.h blib\arch\auto\DBI\DBIXS.h > cp lib/DBI/DBD/Metadata.pm blib\lib\DBI/DBD/Metadata.pm > cp lib/DBD/NullP.pm blib\lib\DBD/NullP.pm > cp dbipport.h blib\arch\auto\DBI\dbipport.h > cp lib/DBI/Format.pm blib\lib\DBI/Format.pm > cp lib/DBI/Const/GetInfoReturn.pm blib\lib\DBI/Const/GetInfoReturn.pm > cp dbd_xsh.h blib\arch\auto\DBI\dbd_xsh.h > cp lib/DBI/Const/GetInfo/ANSI.pm blib\lib\DBI/Const/GetInfo/ANSI.pm > cp lib/DBI/Profile.pm blib\lib\DBI/Profile.pm > cp lib/DBI/PurePerl.pm blib\lib\DBI/PurePerl.pm > cp lib/DBI/Shell.pm blib\lib\DBI/Shell.pm > cp lib/DBI/FAQ.pm blib\lib\DBI/FAQ.pm > cp DBI.pm blib\lib\DBI.pm > cp lib/DBD/ExampleP.pm blib\lib\DBD/ExampleP.pm > cp lib/Bundle/DBI.pm blib\lib\Bundle/DBI.pm > cp lib/Win32/DBIODBC.pm blib\lib\Win32/DBIODBC.pm > cp lib/DBI/W32ODBC.pm blib\lib\DBI/W32ODBC.pm > cp lib/DBI/DBD.pm blib\lib\DBI/DBD.pm > cp lib/DBI/ProfileData.pm blib\lib\DBI/ProfileData.pm > cp lib/DBI/Const/GetInfoType.pm blib\lib\DBI/Const/GetInfoType.pm > cp lib/DBI/ProxyServer.pm blib\lib\DBI/ProxyServer.pm > cp lib/DBD/Proxy.pm blib\lib\DBD/Proxy.pm > cp dbi_sql.h blib\arch\auto\DBI\dbi_sql.h > cp lib/DBI/ProfileDumper/Apache.pm blib\lib\DBI/ProfileDumper/Apache.pm > cp Driver.xst blib\arch\auto\DBI\Driver.xst > cp lib/DBI/Const/GetInfo/ODBC.pm blib\lib\DBI/Const/GetInfo/ODBC.pm > cp lib/DBD/Sponge.pm blib\lib\DBD/Sponge.pm > C:\Perl\bin\perl.exe -p -e "s/~DRIVER~/Perl/g" < >
Re: ANNOUNCE: DBI 1.34 - OK on MacOS X 10.2.4 with Perl 5.8.0
On Sat, Mar 01, 2003 at 04:24:33PM -0800, Jonathan Leffler wrote:
> Tim Bunce wrote:
> > file: $CPAN/authors/id/T/TI/TIMB/DBI-1.34.tar.gz
>
> I got a clean compile and install on MacOS X 10.2.4 (yes, I got that
> upgraded too), over a forced install of DBI 1.33. Looks good to me.
Great, thanks.
> You show the 'install_method' working on
> DBD::Driver::db->install_method(...). That appears to make it
> available on a $dbh - correct? Is there an equivalent for the
> statement handle? DBD::Driver::st->install_method()?
Yes, and drivers via DBD::Driver::dr. (Doc patches welcome.)
But remember that using install_method, like func, makes applications
non-portable. If the method does something similar to a DBI method
then it's better to add an attribute to the DBI method rather than
create a new driver-private one.
> After invoking DBD::Informix::db->install_method('ix_funky', undef),
> I believe I'd be able to run $dbh->ix_funky(...) without further ado
> (assuming $dbh was a DBD::Informix database handle). Is that correct?
Yes.
> I rather like the possibilities that this opens up, I have to say.
Me too. (There's actually a _lot_ of interesting flexibility available
through \%attr but I didn't have time to create and document a clean
interfece for it. Volunteers welcome over on dbi-dev.)
It's been in my plans for ages, but taking a look at the
DBD::AnyData documentation again finally made me do it!
Take a look and you'll see what I mean:
http://search.cpan.org/author/JZUCKER/DBD-AnyData-0.05/AnyData.pm#SYNOPSIS
Tim.
Re: ANNOUNCE: DBI 1.34 - OK on MacOS X 10.2.4 with Perl 5.8.0
On Sat, Mar 01, 2003 at 07:43:14PM -0800, Dean Arnold wrote:
> "Jonathan Leffler" <[EMAIL PROTECTED]> wrote:
> >
> > You show the 'install_method' working on
> > DBD::Driver::db->install_method(...). That appears to make it
> > available on a $dbh - correct? Is there an equivalent for the
> > statement handle? DBD::Driver::st->install_method()?
> >
> > After invoking DBD::Informix::db->install_method('ix_funky', undef),
> > I believe I'd be able to run $dbh->ix_funky(...) without further ado
> > (assuming $dbh was a DBD::Informix database handle). Is that correct?
> >
> > I rather like the possibilities that this opens up, I have to say.
>
> Megadittos (to coin an overused phrase). Certainly is much more
> aesthetically acceptable and easier to explain to users when
> driver-specific functions are supplied.
>
> One little question (not entirely due to being too lazy to test it):
> does this all work with subclassed DBI drivers ? E.g., will it
> work as is in DBIx::Chart wo/ any changes to DBIx::Chart ?
Yeap.
> Hmmm, actually, I suppose I should make the same inquiry
> about all the changes that have been made since 1.32...at which
> point I'm certain the answer is
> "give it a shot and see what shakes out"...wish I had more cycles..
"give it a shot and see what shakes out" :)
> ...wish I had more cycles..
Ditto.
Tim.
Re: DBI::Format in DBI-1.34 vs. DBI-Shell-11.91
On Sat, Mar 01, 2003 at 11:10:34AM -0800, David Dyck wrote: > > There seem to be conflicting versions of DBI::Format in > DBI-1.34 and DBI-Shell-11.91. > > After upgrading to the recent DBI-1.34 I again get > a warning from the CPAN "r" command which reports that > there is a more recent version of DBI::Format to > be found in DBI-Shell-11.91.tar. > > When I read that the new DBI-1.34 removed the > old DBI::Shell from distribution, I was surporised > that it kept DBI::Format. So was I :) I'd meant to remove it and will do for the next release. Tim.
Re: DBD::CSV
On Mon, Mar 03, 2003 at 10:07:29AM -0800, Jeff Zucker wrote: > Peter Schuberth wrote: > > >On the same hardware system > >the same select for the same table > > > Please check your version of SQL::Statement which is the module that > determines the speed and capabilities of DBD::CSV. Put these two lines > at the top of the scripts: > >use SQL::Statement; >print $SQL::Statement::VERSION; Or run this command perl -MSQL::Statement= and it'll say something like SQL::Statement required--this is only version X.YY Tim.
Re: DBI 1.34 error?
On Mon, Mar 03, 2003 at 04:25:13PM -0500, Bob X wrote:
> I have this script:
>
> use strict;
> use warnings;
>
> use DBI;
>
> my %attr = (
> PrintError => 0,
> RaiseError => 1
> );
>
> my @drivers = DBI->available_drivers();
>
> foreach my $driver(@drivers) {
> print "Driver: $driver\n";
> my @dataSources = DBI->data_sources($driver);
>
> foreach my $dataSource(@dataSources) {
> print "\t$dataSource\n";
> }
> print "\n";
> }
>
> It simply gives me a list of DBD drivers installed. Ran fine until I upgrade
> to 1.34 at which point I get the following error now:
>
> install_driver(Proxy) failed: Global symbol "$this" requires explicit
> package name at C:/Perl/site/lib/DBD/Proxy.pm line 272.
> BEGIN not safe after errors--compilation aborted at
> C:/Perl/site/lib/DBD/Proxy.pm line 414.
> Compilation failed in require at (eval 3) line 3.
>
> Nothing ground breaking...just thought you should know.
Thanks. I believe the appended patch fixes it.
Tim.
*** lib/DBD/Proxy.pm2003/02/28 17:50:06 11.12
--- lib/DBD/Proxy.pm2003/03/03 22:37:14
***
*** 269,275
# to let people trade safety for speed if they need to.
undef $dbh->{'proxy_dbh'};# Bug in Perl 5.004; would prefer delete
undef $dbh->{'proxy_client'};
! $this->SUPER::STORE('Active' => 0);
1;
}
--- 269,275
# to let people trade safety for speed if they need to.
undef $dbh->{'proxy_dbh'};# Bug in Perl 5.004; would prefer delete
undef $dbh->{'proxy_client'};
! $dbh->SUPER::STORE('Active' => 0);
1;
}
Anyone have DBI code that depends on $sth->{NAME} containing "tablename.fieldname"?
I've discovered that DBD::mysql will return "tablefoo.fieldbar" as
the NAME of the field in a select like:
SELECT tablefoo.fieldbar FROM tablefoo
It does that simply because that's what the underlying mysql client
API tell it is the name of the field.
I believe this is very rare (I know of no others drivers that do that)
and I'm considering changing the DBI specification to clarify that NAME
should only contain the fieldname.
I appreciate that there's a loss of information here and that
statements like this:
SELECT table1.field, table2.field FROM table1, table2 WHERE ...
will return the same NAME value for both fields.
However, I'm currently of the opinion that removing the table name
to make NAME be consistent with the behaviour of other drivers is
of greater benefit than retaining the table name.
I'd welcome any examples of code that *relies* in the table name
being present in the NAME attribute and can't easily be changed.
Note that in the specific case of DBD::mysql, the table name of
each field is also availble in the $sth->{mysql_table} attribute,
so any application that needs the table name for each field can
still get it.
Tim.
Re: DBI 1.34 error?
On Mon, Mar 03, 2003 at 09:43:45PM -0800, Jonathan Leffler wrote:
> Tim Bunce wrote:
> >>package name at C:/Perl/site/lib/DBD/Proxy.pm line 272.
> >>BEGIN not safe after errors--compilation aborted at
> >>C:/Perl/site/lib/DBD/Proxy.pm line 414.
> >>Compilation failed in require at (eval 3) line 3.
> >*** lib/DBD/Proxy.pm2003/02/28 17:50:06 11.12
> >--- lib/DBD/Proxy.pm2003/03/03 22:37:14
> >***
> >*** 269,275
> > # to let people trade safety for speed if they need to.
> > undef $dbh->{'proxy_dbh'};# Bug in Perl 5.004; would prefer
> > delete
> > undef $dbh->{'proxy_client'};
> >! $this->SUPER::STORE('Active' => 0);
> > 1;
> > }
> >
> >--- 269,275
> > # to let people trade safety for speed if they need to.
> > undef $dbh->{'proxy_dbh'};# Bug in Perl 5.004; would prefer
> > delete
> > undef $dbh->{'proxy_client'};
> >! $dbh->SUPER::STORE('Active' => 0);
> > 1;
> > }
>
>
> Silly question time, Tim; does the fact that we don't support Perl
> 5.004 allow you to change line 270 now?
Maybe. Tested patches welcome :)
Tim.
Re: Anyone have DBI code that depends on $sth->{NAME} containing "tablename.fieldname"?
It looks like a false alarm. I can't reproduce it outside Class::DBI
(using mysql client, or DBD::mysql, using v3 or v4) so I need to
dig deeper into Class::DBI to see what's happening there.
Tim.
On Mon, Mar 03, 2003 at 06:39:01PM -0600, Paul DuBois wrote:
> At 0:18 +0000 3/4/03, Tim Bunce wrote:
> >I've discovered that DBD::mysql will return "tablefoo.fieldbar" as
> >the NAME of the field in a select like:
> >
> >SELECT tablefoo.fieldbar FROM tablefoo
>
> That's not what I observe. Is this a recent change in the MySQL C client
> library? The library has not returned a table name before, because
> the table name is in a separate member of the MYSQL_FIELD structure.
>
> >
> >It does that simply because that's what the underlying mysql client
> >API tell it is the name of the field.
> >
> >I believe this is very rare (I know of no others drivers that do that)
> >and I'm considering changing the DBI specification to clarify that NAME
> >should only contain the fieldname.
> >
> >I appreciate that there's a loss of information here and that
> >statements like this:
> >
> >SELECT table1.field, table2.field FROM table1, table2 WHERE ...
> >
> >will return the same NAME value for both fields.
> >
> >However, I'm currently of the opinion that removing the table name
> >to make NAME be consistent with the behaviour of other drivers is
> >of greater benefit than retaining the table name.
> >
> >I'd welcome any examples of code that *relies* in the table name
> >being present in the NAME attribute and can't easily be changed.
> >
> >Note that in the specific case of DBD::mysql, the table name of
> >each field is also availble in the $sth->{mysql_table} attribute,
> >so any application that needs the table name for each field can
> >still get it.
> >
> >Tim.
>
(Fwd) DBD::Oracle and AIX 5.1 64 bit
- Forwarded message from [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] Subject: DBD::Oracle and AIX 5.1 64 bit To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Date: Tue, 4 Mar 2003 11:40:32 +0100 Hallo, do you have experience with AIX 5.1 64 bit mode and DBD::Oracle? I have a strange error message and I don't know where to start looking for problems. Oracle 8.1.7, perl 5.6.0 (standard AIX included version). [some linebreaks inserted] Can't load '/usr/opt/perl5/lib/site_perl/5.005/aix//auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: dlopen: /usr/opt/perl5/lib/site_perl/5.005/aix//auto/DBD/Oracle/Oracle.so: 30 /appl/oracle/product/8.1.6/lib/libclntsh.a shr.o36 pw_post 256 /unix36 pw_wait 257 /unix36 pw_config 258 /unix36 aix_ora_pw_version3_required 259 /unix at /usr/opt/perl5/lib/5.6.0/aix/DynaLoader.pm line 200. -- Tschau...Thomas "Do you wanna be a legend or a passing footprint on the sands of time?" Senior Consultant, Tivoli Certified Enterprise Consultant + Instructor santix AG,Max-Planck-Str. 7,D-85716 Unterschleissheim, Germany +49-89-321506-0, Fax -99, [EMAIL PROTECTED], http://www.santix.de/ - End forwarded message -
Re: DBI 1.34 error?
On Mon, Mar 03, 2003 at 08:20:34PM -0500, Bob X wrote:
> "Tim Bunce" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > On Mon, Mar 03, 2003 at 04:25:13PM -0500, Bob X wrote:
>
> > Thanks. I believe the appended patch fixes it.
> >
> > Tim.
> >
> > *** lib/DBD/Proxy.pm2003/02/28 17:50:06 11.12
> > --- lib/DBD/Proxy.pm2003/03/03 22:37:14
> > ***
> > *** 269,275
> > # to let people trade safety for speed if they need to.
> > undef $dbh->{'proxy_dbh'};# Bug in Perl 5.004; would prefer delete
> > undef $dbh->{'proxy_client'};
> > ! $this->SUPER::STORE('Active' => 0);
> > 1;
> > }
> >
> > --- 269,275
> > # to let people trade safety for speed if they need to.
> > undef $dbh->{'proxy_dbh'};# Bug in Perl 5.004; would prefer delete
> > undef $dbh->{'proxy_client'};
> > ! $dbh->SUPER::STORE('Active' => 0);
> > 1;
> > }
>
> err...do I do this? I am just a beginner.
Ah, okay. Sorry. Edit the lib/DBD/Proxy.pm file and change the $this in the
line that's causing the error, to be $dbh.
Tim.
Re: Problems installing DBD1.12 on DBI1.34 and Perl 5.8
On Tue, Mar 04, 2003 at 04:33:59PM +0100, Andreas Koch wrote: > After successful installation of Perl and DBI, i get some errors installing > the DBD 1.12. What can i do to fix it? There are no errors, only warnings. The short story is that DBD::Oracle has not yet been updated for recent perl versions. The effect of this is (I believe) only that trace() is broken and fatal to use. A new release of DBD::Oracle is currently being worked on (with kind help from Jeff Urlwin) and may be released within a week or so. Tim. > The make process give me following output > > --->>> > > Oracle.xs : In function 'XS_DBD__Oracle__st_ora_fetch': > Oracle.xs : 69 : warning: passing arg1 of 'fprintf' from incompatible pointer type > > ---<<< > The complete set of errors is attached in file output.txt. > > > Thank you for help. > > Andreas > > Content-Description: output.txt > Oracle.xs: In function `XS_DBD__Oracle__st_ora_fetch': > Oracle.xs:69: warning: passing arg 1 of `fprintf' from incompatible pointer type > Oracle.xs:79: warning: passing arg 1 of `fprintf' from incompatible pointer type > Oracle.xs:83: warning: passing arg 1 of `fprintf' from incompatible pointer type > Oracle.xs:87: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `dbd_fbh_dump': > dbdimp.c:85: warning: initialization from incompatible pointer type > dbdimp.c: In function `ora_db_login6': > dbdimp.c:206: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:212: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:220: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:221: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:222: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:224: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:227: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:228: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:229: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:234: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:236: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:244: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:248: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:249: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:250: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:251: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:252: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:258: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `ora_db_commit': > dbdimp.c:348: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `ora_db_rollback': > dbdimp.c:394: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `ora_db_disconnect': > dbdimp.c:425: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:427: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `ora_db_destroy': > dbdimp.c:454: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:455: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:456: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:457: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `dbd_preparse': > dbdimp.c:668: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `dbd_rebind_ph_char': > dbdimp.c:783: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:785: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:787: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:790: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:855: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `pp_rebind_ph_rset_in': > dbdimp.c:877: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:889: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:895: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c: In function `pp_exec_rset': > dbdimp.c:911: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:917: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdimp.c:921: warning: passing arg 1 of `fprintf' from incompatible pointer type > dbdim
Re: DBD::CSV
On Tue, Mar 04, 2003 at 09:32:27AM -0800, Jeff Zucker wrote: > Tim Bunce wrote: > > >On Mon, Mar 03, 2003 at 10:07:29AM -0800, Jeff Zucker wrote: > > > >>use SQL::Statement; > >> print $SQL::Statement::VERSION; > >> > > > >Or run this command > > > > perl -MSQL::Statement= > > > > Hmm, what am I missing? That doesn't work for me with SQL::Statement. > It also doesn't work for me with DBD::ODBC, DBD::ADO, DBD::CSV although > it does work with DBI and with DBD::Pg. What do I need to do in the > module to get this to work? >From memory... it needs a non-lexical $VERSION and (I think) to be a subclass of Exporter. Tim.
Re: Problems installing DBD1.12 on DBI1.34 and Perl 5.8
On Tue, Mar 04, 2003 at 10:45:45PM -, Simon Taylor wrote: > Will this include support for Oracle 8 objects? Is your cheque in the mail? ;-) Let's get the ball rolling bfore we try to steer it shall we? Tim. > -Original Message----- > From: Tim Bunce [mailto:[EMAIL PROTECTED] > Sent: 04 March 2003 22:25 > To: Andreas Koch > Cc: [EMAIL PROTECTED] > Subject: Re: Problems installing DBD1.12 on DBI1.34 and Perl 5.8 > > > On Tue, Mar 04, 2003 at 04:33:59PM +0100, Andreas Koch wrote: > > After successful installation of Perl and DBI, i get some errors > > installing the DBD 1.12. What can i do to fix it? > > There are no errors, only warnings. The short story is that DBD::Oracle has > not yet been updated for recent perl versions. The effect of this is (I > believe) only that trace() is broken and fatal to use. > > A new release of DBD::Oracle is currently being worked on (with kind help > from Jeff Urlwin) and may be released within a week or so. > > Tim. > > > The make process give me following output > > > > --->>> > > > > Oracle.xs : In function 'XS_DBD__Oracle__st_ora_fetch': Oracle.xs : 69 > > : warning: passing arg1 of 'fprintf' from incompatible pointer type > > > > ---<<< > > The complete set of errors is attached in file output.txt. > > > > > > Thank you for help. > > > > Andreas > > > > > > Content-Description: output.txt > > Oracle.xs: In function `XS_DBD__Oracle__st_ora_fetch': > > Oracle.xs:69: warning: passing arg 1 of `fprintf' from incompatible > > pointer type > > Oracle.xs:79: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > Oracle.xs:83: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > Oracle.xs:87: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c: In function `dbd_fbh_dump': > > dbdimp.c:85: warning: initialization from incompatible pointer type > > dbdimp.c: In function `ora_db_login6': > > dbdimp.c:206: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:212: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:220: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:221: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:222: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:224: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:227: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:228: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:229: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:234: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:236: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:244: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:248: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:249: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:250: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:251: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:252: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:258: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c: In function `ora_db_commit': > > dbdimp.c:348: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c: In function `ora_db_rollback': > > dbdimp.c:394: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c: In function `ora_db_disconnect': > > dbdimp.c:425: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:427: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c: In function `ora_db_destroy': > > dbdimp.c:454: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp.c:455: warning: passing arg 1 of `fprintf' from incompatible > pointer type > > dbdimp
Re: fork() issues w/ Win32, Perl 5.6.1, and DBI 1.32
On Tue, Mar 04, 2003 at 02:31:37PM -0800, Dean Arnold wrote:
> While trying to test some multiprocessing on Win2K (ActiveState 633), I ran
> into
> an issue I'm hoping you can shed some light on. If I open a $dbh before
> forking
> off some kids that also open some $dbh's, I get the following error in the
> kids:
>
> "DBD::Teradata::dr connect failed: handle 1 is owned by thread 1abf360 not
> current thread 3adf034 (ha
> ndles can't be shared between threads and your driver may need a CLONE
> method added) at D:/Perl/site
> /lib/DBI.pm line 513."
>
> However, if I enable PurePerl, everything works fine. My assumption is that
> I need a
> CLONE { } of some sort within DBD::Teradata::dr, correct ? And this is all
> due
> to Win32's pseudo-fork, yes ? Are there any working examples of pure perl
> DBD CLONE { }
> I can cheat from ? I'm not entirely certain what I need to do within
> it...and I assume
> adding it now will be a head start on whatever is needed for 5.8 ?
Add
sub CLONE {
undef $drh;
}
to the DBI::Teradata package, such that when an interpreter is cloned
the new one doesn't have the driver handle cached.
Tim.
Re: fork() issues w/ Win32, Perl 5.6.1, and DBI 1.32
On Tue, Mar 04, 2003 at 04:21:10PM -0800, Dean Arnold wrote:
> > On Tue, Mar 04, 2003 at 02:31:37PM -0800, Dean Arnold wrote:
> > > While trying to test some multiprocessing on Win2K (ActiveState 633), I
> ran
> > > into
> > > an issue I'm hoping you can shed some light on. If I open a $dbh before
> > > forking
> > > off some kids that also open some $dbh's, I get the following error in
> the
> > > kids:
> > >
> > > "DBD::Teradata::dr connect failed: handle 1 is owned by thread 1abf360
> not
> > > current thread 3adf034 (ha
> > > ndles can't be shared between threads and your driver may need a CLONE
> > > method added) at D:/Perl/site
> > > /lib/DBI.pm line 513."
> >
> > Add
> > sub CLONE {
> > undef $drh;
> > }
> >
> > to the DBI::Teradata package, such that when an interpreter is cloned
> > the new one doesn't have the driver handle cached.
>
> Tried it, but still fails. Tried various version of same, still no go. So I
> hacked
> same into DBD::Chart to see if it misbehaves...and indeed it does. Tried
> putting a print into the CLONE, it never prints...does DBI explicitly invoke
> this, or just Perl itself ?
Perl.
> Haven't tried DBI 1.33/1.34 , but
> my hunch is this is a Perl issue; do I need a newer version of 5.6.1 ? (I
> see AS has more current builds available).
Worth trying before digging deeper.
Tim.
Re: funny fields and "
On Tue, Mar 04, 2003 at 10:58:22PM -0500, Jeff Thies wrote: > I have an Access database with funny field names like: REPORT # > > I forgot the advice to use square brackets [] and used double quotes > instead : "REPORT #". > > Now, that works fine. But is that going to cause me trouble > somewhere/sometime? Should I replace that with the square brackets, or > let it ride. Square brackets are a Microsoft specific feature, double quotes are an international standard. Take your pick. Tim.
Re: date time in Access
On Wed, Mar 05, 2003 at 02:36:50PM +, Volker I. Lipper wrote: > Hi Jeff, > > the correct syntax in access itself would be: > > >#9/30/1999# > > the writing of the data (mm.dd or dd.mm or mm/dd) belongs to the > system variables set on the system acess is installed on. But in > every case you have to use the # sign. Doesn't using standard quotes work? Tim.
Re: date time in Access
On Wed, Mar 05, 2003 at 01:38:58PM -0500, Jeff Thies wrote:
>
>
> Tim Bunce wrote:
> >
> > On Wed, Mar 05, 2003 at 02:36:50PM +, Volker I. Lipper wrote:
> > > Hi Jeff,
> > >
> > > the correct syntax in access itself would be:
> > >
> > > >#9/30/1999#
> > >
> > > the writing of the data (mm.dd or dd.mm or mm/dd) belongs to the
> > > system variables set on the system acess is installed on. But in
> > > every case you have to use the # sign.
> >
> > Doesn't using standard quotes work?
>
> Nope, But the # does work.
>
> I'm sure I should have known that, but I normally save dates as unix
> times in a varchar.
Did you try both sibgle and double quotes?
And maybe ... = {d '1999-9-30'} ?
Tim [who knows almost nothing about Access]
Re: DBI-1.3[34] memory leak?
On Wed, Mar 05, 2003 at 08:13:00AM -0600, Philip Molter wrote:
> I have a very long running Perl process. I recently upgraded the
> DBI from 1.32 to 1.33 (and then 1.34) and now, the process is leaking
> memory. Given the complexity of the project, it's not possible to
> reduce it to a simple test case at this time, but it's definitely
> related to the DBI -- if I downgrade to 1.32, the problem goes away.
Try commenting out line 631:
$dbh->{dbi_connnect_closure} = $connect_closure if $dbh;
Please let me know if that helps.
Tim.
Re: help for install DBI on linux for Oracle
Upgrade your DBI. Try 1.34 Tim. On Thu, Mar 06, 2003 at 10:50:34AM -0500, Yang Li wrote: > Hi There; > > I got following error during installing DBI-1.32 on Linux 6.2 with Perl > perl-5.00503-12. > > Could you give any help? Thanks. > > Regards, > > Yang > > PERL_DL_NONLAZY=1 > /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/perl5/5.00503/i386-linux -I/ > usr/lib/perl5/5.00503 -e 'use Test::Harness qw(&runtests $verbose); > $verbose=0; runtests @ARGV;' t/*.t > t/01basics..ok > t/02dbidrv..ok > t/03hleak...ok > t/04modsok > t/05thrcloneskipping test on this platform > t/06attrs...ok > t/07kidsok > t/10examp...Insecure dependency in parameter 1 of > DBI::st=HASH(0x82598d4)->FETCH method call while running with -T switch at > t/10examp.t line 320. > DBI handle cleared whilst still active. > dbih_clearcom (sth 0x825a6d0 0x817f760, com 0x825c598, imp > DBD::ExampleP::st): >FLAGS 0x60011: COMSET Warn TaintIn TaintOut >PARENT DBI::db=HASH(0x8256734) >KIDS 0 (0 Active) >IMP_DATA ARRAY(0x825a874) >NUM_OF_FIELDS 3 >NUM_OF_PARAMS 1 > dubious > Test returned status 20 (wstat 5120, 0x1400) > Undefined subroutine &Test::Harness::WCOREDUMP called at > /usr/lib/perl5/5.00503/Test/Harness.pm line 288. > make: *** [test_dynamic] Error 20
Re: DBI-1.3[34] memory leak?
On Wed, Mar 05, 2003 at 08:13:00AM -0600, Philip Molter wrote:
> I have a very long running Perl process. I recently upgraded the
> DBI from 1.32 to 1.33 (and then 1.34) and now, the process is leaking
> memory. Given the complexity of the project, it's not possible to
> reduce it to a simple test case at this time, but it's definitely
> related to the DBI -- if I downgrade to 1.32, the problem goes away.
The leak is in fetchrow_hashref, after the change to workaround
a Taint problem in some versions of perl.
Here's a patch (probably offset by a few lines, but close enough).
I'll make a new release soonish.
Thanks for spotting this. (If I have time I'll try to integrate a
leak test into the test suite.)
Tim.
***
*** 3562,3568
}
RETVAL = newRV((SV*)hv);
SvREFCNT_dec(hv); /* since newRV incremented it */
- SvREFCNT_dec(ka_rv);/* since we created it */
}
else {
RETVAL = &sv_undef;
--- 3564,3569
***
*** 3570,3575
--- 3571,3577
RETVAL = newSV(0); /* mutable undef for 5.004_04 */
#endif
}
+ SvREFCNT_dec(ka_rv); /* since we created it */
OUTPUT:
RETVAL
Re: DBD::Proxy problems
On Fri, Mar 07, 2003 at 09:24:51AM -0500, Cory Rau wrote: > Hmmm...I did that. And now I get a different error: > > > Argument " " isn't numeric in repeat (x) at /Library/Perl/darwin/DBD/Proxy.pm line > 63. Change the 5 x ' ' to ' ' x 5 on the line with the error. It's fixed in the next release. But that's just a minor issue shown up by the other error: > DBD::Proxy::db STORE failed: Can't store CODE items at > blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_freeze.al) > line 282, at /Library/Perl/RPC/PlServer/Comm.pm line 57 That's a more subtle issue. Try adding dbi_connect_closure => 'local', to %ATTR around line 222 of DBD/Proxy.pm Tim.
(Fwd) RE: perl DBI question: fetchrow_array
- Forwarded message from gmei <[EMAIL PROTECTED]> -
Delivered-To: [EMAIL PROTECTED]
From: "gmei" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: perl DBI question: fetchrow_array
Date: Fri, 7 Mar 2003 13:39:14 -0500
In-Reply-To: <[EMAIL PROTECTED]>
Hi, Tim:
Thanks for your reply. I have a couple of more-or-less baic questions of dbi
syntax.
I just checked the version of DBI on my machine:
atlas$ ls -d /usr/local/src/perl_modules/DBI*[0-9]
/usr/local/src/perl_modules/DBI-1.13
Right now we could not upgrade DBI on this production system, but I will ask
the sysadmin to consider.
With the DBI version we have, I did find that
$dat->bind_columns(undef,\($row));
while($dat->fetch) {
print DATA "$row\n";
}
is a bit faster than
while(($row) = $dat->fetchrow_array) {
print DATA "$row\n";
}
close(DATA);
when we have $dat = $dbh->prepare("select " . join('||chr(9)||', @select) .
" from $table");
We don't need to process the data in the result set, I just want to dump
them into a file, So I guess I don't need to use "shift" in your example? Is
"fetchall_arrayref" still the fastest? What is the syntax of it? could you
use my code above as example of how to use "fetchall_arrayref"?
Also,is $dat->fetch the same as $dat->fetchrow_arrayref?
Thanks.
Guang
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Bunce
> Sent: Friday, March 07, 2003 10:09 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: perl DBI question: fetchrow_array
>
>
> On Thu, Mar 06, 2003 at 02:54:19PM -0800,
> [EMAIL PROTECTED] wrote:
> > 1) fetchrow_arrayref is faster than fetchrow_array, as Alex
> has noted.
> >
> > 2) I see you've already set RowCacheSize. Anecdotal
> evidence ( not just mine)
> > suggests that the diminished returns obtained by setting
> this >100 aren't
> > worth it.
> >
> > 3) try selectall_arrayref if you're data is not really
> large. 'really
> > large' depends on your environment.
> >
> > 4) join DBI users list, found at lists.perl.org.
>
> That's all true.
>
> I'd just add that recent DBI versions let you specify a
> max_rows parameter
> to the fetchall_arrayref method. You can then call it in a loop to get
> rows on batches.
>
> This is now the fastest way to fetch rows in a loop using the DBI:
>
> my $rows = []; # cache for batches of rows
> while( my $row = ( shift(@$rows) || # get row from cache,
> or reload cache:
>
> shift(@{$rows=$sth->fetchall_arrayref(undef,10_000)||[]) )
> ) {
> ...
> }
>
> The code that implements fetchall_arrayref is written in C and,
> although there's a default implementation in the DBI, a faster one
> gets embedded into drivers like DBD::Oracle when it's (re)built
> (after you've upgraded the DBI).
>
> Several parts of the DBI have been optimized with this code-embedding
> technique so if you've not upgraded your DBI to >= 1.29, or not
> rebuilt your DBD::Oracle since then it may be worth doing so.
>
> (FYI, if this prompts you to upgrade your DBI installation, please
> note DBI 1.32 was a good release, but that 1.33 and 1.34 have
> problems,
> including a memory leak. I hope to release a 1.35 before Monday.)
>
> Tim.
>
- End forwarded message -
Re: DBI newbie asks ODBC query question
http://www.google.com/search?q=sql+null+three+value
Tim.
On Fri, Mar 07, 2003 at 04:36:41PM -0500, Rick Nakroshis wrote:
> I just installed DBI v1.34 and DBD-ODBC v1.04 on my AS build 633, and
> have a question about a query that I tried to test the ODBC connection
> to our SQL Server database:
>
> my $sth = $dbh->prepare("SELECT a, b, c FROM table WHERE (c <> 'XYZZY')
> ORDER BY a");
>
> will return 109,000 rows in four seconds. All three fields are
> populated in all records.
>
> my $sth = $dbh->prepare("SELECT a, b, c FROM table ORDER BY a");
>
> Omitting the WHERE statement returns 1.5 million rows in 839 seconds;
> the additional rows are where field 'c' is null. The value 'XYZZY' will
> never occur in the data.
>
> Why wouldn't those rows be returned in the first query? Why does it
> take so much longer to return these records?
>
> Thanks for enlightening a DBI newbie,
>
> Rick
>
ANNOUNCE: DBI 1.35
file: $CPAN/authors/id/T/TI/TIMB/DBI-1.35.tar.gz
size: 288058 bytes
md5: 8ede0b8817ac8b0db6cc5db36109060c
NOTE: Future versions of the DBI *will not* support perl 5.6.0 or earlier.
: Perl 5.6.1 will be the minimum supported version.
NOTE: The "old-style" connect: DBI->connect($database, $user, $pass, $driver);
: has been deprecated for several years and will now generate a warning.
: It will be removed in a later release. Please change any old connect() calls.
=head2 Changes in DBI 1.35,7th March 2003
Fixed memory leak in fetchrow_hashref introduced in DBI 1.33.
Fixed various DBD::Proxy errors introduced in DBI 1.33.
Fixed to ANSI C in dbd_dr_data_sources thanks to Jonathan Leffler.
Fixed $h->can($method_name) to return correct (outer) code ref.
Removed DBI::Format from distribution as it's now part of the
separate DBI::Shell distribution by Tom Lowery.
Updated DBI::DBD docs with a note about the CLONE method.
Updated DBI::DBD docs thanks to Jonathan Leffler.
Updated DBI::DBD::Metadata for perl 5.5.3 thanks to Jonathan Leffler.
Added note to install_method docs about setup_driver() method.
=head2 Changes in DBI 1.34,28th February 2003
Fixed DBI::DBD docs to refer to DBI::DBD::Metadata thanks to Jonathan Leffler.
Fixed dbi_time() compile using BorlandC on Windows thanks to Steffen Goeldner.
Fixed profile tests to do enough work to measure on Windows.
Fixed disconnect_all() to not be required by drivers.
Added $okay = $h->can($method_name) to check if a method exists.
Added DBD::*::*->install_method($method_name, \%attr) so driver private
methods can be 'installed' into the DBI dispatcher and no longer
need to be called using $h->func(..., $method_name).
Enhanced $dbh->clone() and documentation.
Enhanced docs to note that dbi_time(), and thus profiling, is limited
to only millisecond (seconds/1000) resolution on Windows.
Removed old DBI::Shell from distribution and added Tom Lowery's improved
version to the Bundle::DBI file.
Updated minimum version numbers for modules in Bundle::DBI.
=head2 Changes in DBI 1.33,27th February 2003
Added $dbh2 = $dbh1->clone to make a new connection to the database
that is identical to the original one. clone() can be called even after
the original handle has been disconnected. See the docs for more details.
Fixed merging of profile data to not sum DBIprof_FIRST_TIME values.
Fixed unescaping of newlines in DBI::ProfileData thanks to Sam Tregar.
Fixed Taint bug with fetchrow_hashref with help from Bradley Baetz.
Fixed $dbh->{Active} for DBD::Proxy, reported by Bob Showalter.
Fixed STORE to not clear error during nested DBI call,
thanks to Tony Bowden for the report and helpful test case.
Fixed DBI::PurePerl error clearing behaviour.
Fixed dbi_time() and thus DBI::Profile on Windows thanks to Smejkal Petr.
Fixed problem that meant ShowErrorStatement could show wrong statement,
thanks to Ron Savage for the report and test case.
Changed Apache::DBI hook to check for $ENV{MOD_PERL} instead of
$ENV{GATEWAY_INTERFACE} thanks to Ask Bjoern Hansen.
No longer tries to dup trace logfp when an interpreter is being cloned.
Database handles no longer inherit shared $h->err/errstr/state storage
from their drivers, so each $dbh has it's own $h->err etc. values
and is no longer affected by calls made on other dbh's.
Now when a dbh is destroyed it's err/errstr/state values are copied
up to the driver so checking $DBI::errstr still works as expected.
Build / portability fixes:
Fixed t/40profile.t to not use Time::HiRes.
Fixed t/06attrs.t to not be locale sensitive, reported by Christian Hammers.
Fixed sgi compiler warnings, reported by Paul Blake.
Fixed build using make -j4, reported by Jonathan Leffler.
Fixed build and tests under VMS thanks to Craig A. Berry.
Documentation changes:
Documented $high_resolution_time = dbi_time() function.
Documented that bind_col() can take an atribute hash.
Clarified documentation for ParamValues attribute hash keys.
Many good DBI documentation tweaks from Jonathan Leffler,
including a major update to the DBI::DBD driver author guide.
Clarified that execute() should itself call finish() if it's
called on a statement handle that's still active.
Clarified $sth->{ParamValues}. Driver authors please note.
Removed "NEW" markers on some methods and attributes and
added text to each giving the DBI version it was added in,
if it was added after DBI 1.21 (Feb 2002).
Changes of note for authors of all drivers:
Added SQL_DATA_TYPE, SQL_DATETIME_SUB, NUM_PREC_RADIX, and
INTERVAL_PRECISION fields to docs for type_info_all. There were
already in type_info(), but type_info_all() didn't specify the
index values. Please check and update your type_info_all() code.
Added DBI::DBD::Metadata module that auto-generates y
Re: Can't rebind placeholder 1 (DBD-ODBC)?
On Mon, Mar 10, 2003 at 12:26:51AM -0800, Victor A. Rodriguez wrote: > > I run through the same problem a few days ago, and I > just fetched all the rows in a hash with > fetchall_arrayref, finish()ed the query and performed > a do() again. If you fetch all the rows you should not need to call finish(). Tim.
Re: bind param array
On Mon, Mar 10, 2003 at 03:17:46PM +0530, murugan mohan wrote:
> Hi all,
>I am trying to know how I can use bind array. I am having Perl version 5.6 and i
> am working in windows 2k.
> what I tried is as follows.
>
> $sth = $g_dbh->prepare(q{
> BEGIN
> test_1.P1(
> ?,
> ?,
> ?,
> ?);
> END;
> });
> $sth->bind_param_array(1,[EMAIL PROTECTED]);
> $sth->bind_param_array(2,[EMAIL PROTECTED]);
> $sth->bind_param_array(3,[EMAIL PROTECTED]);
> $sth->bind_param_array(4,[EMAIL PROTECTED]);
>
> $sth->execute();
$sth->execute_array;
Tim.
Re: troubles with mysql_read_default_file
Thanks for posting the answer for the archives. Tim. On Mon, Mar 10, 2003 at 04:54:00PM +, Greg Thompson wrote: > > I found an answer to my problem regarding the use of > mysql_read_default_file and my perl script crashing. According to: > > http://www.rosat.mpe-garching.mpg.de/mailing-lists/dbi/2002-06/msg00159.html > > and a page referenced therein, MySQL v3.23.49 contains the problem > and v3.23.50 fixed it. Damn, why doesn't Debian (woody distribution) > include the .50 release yet. > > Hopefully my 8-9 hours spent seeking this answer will help someone else. > > -- Greg ThompsonNCAR/RAP
shortcuts for common placeholder idioms...
> foreach ( $cgi->param() ) {
>push @cols, $_;
>push @vals, $cgi -> param( $_ );
> }
> my $sql = "INSERT INTO table ( " . join( ", ", @cols ) . " )\n" .
>" VALUES ( " . join( ", ", map { "?" } @cols ) . " )";
Seeing all that 'line noise' makes me think we need a neater way.
Personally I'd have written it more like
my $sql = qq{
INSERT INTO table
( } . join( ", ", @cols ) . qq{ )
VALUES ( } . join( ", ", ("?") x @cols ) . qq{ )
};
but that's not really that much clearer and possibly more
'magical' to the novice who may not be familiar with 'x' as a
list replication operator.
But imagine the DBI provided these two functions:
sub comma_separated_values { join ", ", @_ }
sub comma_separated_placeholders { join ", ", ("?") x @_ }
you could then write the statement like this:
separated
my $sql = qq{
INSERT INTO table
( ${\comma_separated_values(@col)} )
VALUES ( ${\comma_separated_placeholders(@col)} )
};
The "... ${\...} ..." is a little magical but not hard to master.
It's just a cute way to evaluate expressions inside a double quoted
string. The ${...} part expects a reference to a scalar so that's
what the backslash before the function name is for. The backslash
takes a reference to the scalar value returned by the function and
the ${...} then interpolates that into the string.
Perhaps we could call the functions dbi_csv and dbi_csp then we'd have
my $sql = "INSERT INTO table ( ${\dbi_csv(@col)} ) VALUES ( ${\dbi_csp(@col)} )";
which seems rather neater than where we started:
my $sql = "INSERT INTO table ( " . join( ", ", @cols ) . " )\n" .
" VALUES ( " . join( ", ", map { "?" } @cols ) . " )";
Comments?
Tim.
Re: Subclass Exporter and version number
On Mon, Mar 10, 2003 at 02:39:36PM -0800, Jeff Zucker wrote: > Tim Bunce wrote: > > >On Tue, Mar 04, 2003 at 09:32:27AM -0800, Jeff Zucker wrote: > > > >>>Or run this command > >>> > >>> perl -MSQL::Statement= > >>> > >>Hmm, what am I missing? That doesn't work for me > >> > >>From memory... it needs a non-lexical $VERSION and (I think) to be > >a subclass of Exporter. > > Hmm, that's right. If I subclass Exporter, the version number trick > works. Is it worth subclassing it just for this feature? Probably, unless there's a good reason not to. I'm not sure if subclassing is really needed. I think the version check logic is nt in UNIVERSAL. See XS(XS_UNIVERSAL_VERSION) in http://search.cpan.org/src/GSAR/perl-5.6.1/universal.c But I'll leave you to onder that if you want to. Tim.
Re: shortcuts for common placeholder idioms...
On Mon, Mar 10, 2003 at 03:47:31PM -0800, Jeff Zucker wrote:
> Paul Boutros wrote:
>
> >my $sql = qq{
> > INSERT INTO table
> >( ${\comma_separated_values(@col)} )
> > VALUES ( ${\comma_separated_placeholders(@col)} )
> >};
> >
>
> I'm not sure I like this, but if it is to be used, a better name might
> be "comma_list" which is the BNF short notation for all comma separated
> lists in SQL (e.g. select lists, value lists, etc.). Also, no reason to
> have two routines or to call them twice -- have the first set an
> attribute and then later read it. For example the call to
> $dbh->comma_list() would both return a comma separated list of the
> column names and set $dbh->{placeholders} to a string of comma separated
> placeholder marks which could be used later without a second call to a
> method:
>
>my $sql = qq{
>INSERT INTO table
>( $dbh->comma_list(@col) )
> VALUES ( $dbh->{placeholders} )
>};
Method calls don't interpolate, and I'm really not keen on relying
on the order they are called.
Tim.
Re: DBD 1.35 compile problems
On Mon, Mar 10, 2003 at 10:51:21PM -0500, Matthew O. Persico wrote:
> I am using Perl 5.6.1, DBI 1.32 and DBD::Oracle 1.12. I have decided to upgrade to
> DBI 1.35 BEFORE reporting a problem I am having.
>
> I built DBI 1.35 with no problems. Then I tried to rebuild DBD::Oracle 1.12.
>
> 1) compile warning:
> cc -c -I/opt/oracle/product/8.1.6/rdbms/demo
> -I/opt/oracle/product/8.1.6/rdbms/public
> -I/opt/oracle/product/8.1.6/plsql/public
> -I/opt/oracle/product/8.1.6/network/public
> -I/opt/oracle/product/8.1.6/rdbms/demo -I/opt/oracle/product/8.1.6/rdbms/demo
> -I/opt/perl/lib/site_perl/5.6.1/sun4-solaris/auto/DBI -I/usr/local/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O-DVERSION=\"1.12\"
> -DXS_VERSION=\"1.12\" -KPIC -I/opt/perl/lib/5.6.1/sun4-solaris/CORE oci8.c
> "oci8.c", line 267: warning: assignment type mismatch:
> pointer to function(pointer to struct imp_dbh_st {struct {..} com,
> pointer to function(pointer to struct imp_dbh_st {..}, in... "=" pointer to void
>
> This is probably NOT due to DBI 1.35, but I thought I'd report it anyway.
Thanks. It's not DBI related. And it's odd that the compiler is
warning about an assignment involving a void* pointer.
> 2) testing:
>
> Because of this in DBI.pm:
>
> sub connect {
> my $class = shift;
> my ($dsn, $user, $pass, $attr, $old_driver) = my @orig_args = @_;
> my $driver;
>
> if ($attr and !ref($attr)) { # switch $old_driver<->$attr if called in old style
> ->>> Carp::croak("DBI->connect using 'old-style' syntax is deprecated and will
> be an error in future versions");
> ($old_driver, $attr) = ($attr, $old_driver);
> }
>
> (which doesn't make sense to me because the croak seems to make the old-style
> syntax be an error in this version!)
Uh, that should have been a carp! Of well, that'll get people to fix their scripts!
But I'll change it to a carp for the next release.
Thanks.
Tim.
Re: Fwd: Cannot bind a single blank space to a non-null varchar?
On Mon, Mar 10, 2003 at 10:55:26PM -0500, Matthew O. Persico wrote:
> I am calling bind_param like this:
>
> $sth->bind_param($col_idx,
> $value,
> {TYPE =>?DBI::SQL_VARCHAR});
>
> for a column defined as varchar(8), not null
>
> When $value == ' ' (one space) or $value == ' ?' (two spaces), ?I get the error:
>
> DBD::Oracle::st execute failed: ORA-01400: cannot insert NULL into
> ("AMGDEV"."AM_BILLING_PS_INTERFACE"."DOC_SEQ_NBR") (DBD ERROR:
> OCIStmtExecute)
> at am_billing_dd_load.pl line 1185.
>
> When I hardcode a ' ' into the query (no binding), I don't get an
> error. When I hardcode '' into the query, I get the error.
>
> Conclusion: somewhere in bind_param or whatever it is that it
> invokes, trailing blanks are being stripped before the call to the OCI.
>
> I was able to get around this by using
>
> $sth->bind_param($col_idx,
> $value,
> {TYPE =>?DBI::SQL_CHAR});
>
> So, my question is, why is the DBI apparently taking it upon itself to enforce
> string trimming for varchars?
It isn't. Oracle is.
> Shouldn't the server be responsible? And shouldn't the DBI behave
> the same for th same value whether it is bound or constant? Or is
> there something stupid I am missing?
Not stupid. Subtle. Check google for
dbi ora_type char spaces
Tim.
Re: bind param array
On Tue, Mar 11, 2003 at 03:13:32PM +0530, murugan mohan wrote:
> Hi Tim,
> I know that my DBI version is old. I can't update my version since there
> are lot of security restrictions. So the last thing I am left is call the stored
> procedure each time for inserting a single row. Is there any other better way so
> that I can minimize the calls to the SQL/PL. Please let me know.
I don't think so.
Tim.
> Regards
> Murugan
>
>
> - Original Message -
> From: Tim Bunce
> Sent: Tuesday, March 11, 2003 3:08 PM
> To: murugan mohan
> Cc: Tim Bunce
> Subject: Re: bind param array
>
> Maybe your DBI version is too old.
>
> Tim.
>
> p.s. Please send all email to [EMAIL PROTECTED], not to me. Thanks.
>
> On Tue, Mar 11, 2003 at 10:32:25AM +0530, murugan mohan wrote:
> > Hi Tim,
> >Thanks for sending me the reply so soon. I changes the code to
> > execute_array and the error message I got is
> > Can't locate object method "bind_param_array" via package "DBI::st" at dbcon.pl
> > line 80
> > whether bind_param_array is not supported in 5.6 version?. Also I can't shift my
> > perl version to 5.8 or later because It involves lot of work. Is there any other
> > way in 5.6 where I can call a stored procedure passing arrays as the arguments.
> >
> > Regards
> > Murugan
> >
> > - Original Message -
> > From: Tim Bunce
> > Sent: Monday, March 10, 2003 5:43 PM
> > To: murugan mohan
> > Cc: users perl perl
> > Subject: Re: bind param array
> >
> > On Mon, Mar 10, 2003 at 03:17:46PM +0530, murugan mohan wrote:
> > > Hi all,
> > >I am trying to know how I can use bind array. I am having Perl version 5.6
> > > and i am working in windows 2k.
> > > what I tried is as follows.
> > >
> > > $sth = $g_dbh->prepare(q{
> > > BEGIN
> > > test_1.P1(
> > > ?,
> > > ?,
> > > ?,
> > > ?);
> > > END;
> > > });
> > > $sth->bind_param_array(1,[EMAIL PROTECTED]);
> > > $sth->bind_param_array(2,[EMAIL PROTECTED]);
> > > $sth->bind_param_array(3,[EMAIL PROTECTED]);
> > > $sth->bind_param_array(4,[EMAIL PROTECTED]);
> > >
> > > $sth->execute();
> >
> > $sth->execute_array;
> >
> > Tim.Get more from the Web. FREE MSN Explorer download :
> > http://explorer.msn.comGet more from the Web. FREE MSN Explorer download :
> > http://explorer.msn.com
Re: How to check your Solaris DBD:Oracle environ is ok
On Tue, Mar 11, 2003 at 07:03:30PM -0500, Matthew O. Persico wrote: > On Tue, 11 Mar 2003 21:26:56 +1100 (EST), Mark Ashley wrote: > > > >So using the truss output I went through each file it was missing > >and copied it into the local tree. My finished tree consists of: > This REALLY needs to get into the DBI FAQ: > http://xmlproj.com/fom-serve/cache/1.html Along with a note that this is a risky thing to do. It only includes files that happened to be used during the test run. There may be files that are needed in other circumstances not yet encountered. If so, things may break down the road (not to mention other issues like Oracle patches and upgrades). Tim.
Re: Fwd: Re: Fwd: Cannot bind a single blank space to a non-null varchar?
On Tue, Mar 11, 2003 at 09:28:50PM -0500, Matthew O. Persico wrote: > --- Original Message --- > From: "M. Addlework" <[EMAIL PROTECTED]> > To: Matthew O. Persico <[EMAIL PROTECTED]> > Cc: > Sent: Tue, 11 Mar 2003 15:59:27 -0800 (PST) > Subject: Re: Fwd: Cannot bind a single blank space to a non-null varchar? > > > > >>Why isn't the trailing whitespace stripped in the third insert? Is > >>this an SQLPLUS aberration? > > > >Sort of. ?The space trimming is happening in OCI, but sqlplus > >does not use OCI. ?Nor does PL/SQL. > > > >OCI is for third-parties. ?Internally, Oracle has a different API. > > Oh, so the high and exalted internal apps get a high powered API and we get stuck > with something else? > > Maybe that's unfair, but that's what it looks like to me. The issue is what 'extern type code' is used for the placeholders. Oracle has several character types with different behaviours (such as allowing embedded nulls and/or stripping trailing spaces). Google for DBD::Oracle ora_ph_type Bunce for more info. Tim.
Re: DBD-Oracle and CLOBS/BLOBS
On Wed, Mar 12, 2003 at 01:46:48PM +0100, Bernhard Donaubauer wrote:
> Hello!
>
> I have a problem to insert NULL values in CLOB/BLOB fields.
I think that's not currently supported. Patches welcome.
Tim.
> In the following example I insert four records into a testtable. The third row
> causes my problem. I try to insert again NULL values (as i did with row 1)
> into the lob fields. Therefore I call:
> $sth->bind_param(2, undef(), { ora_type=>112, ora_field=>'mytext' });
> $sth->bind_param(3, undef(), { ora_type=>113, ora_field=>'myblob' });
>
> But despite of the undef() - Value the driver saves the values of row 2 for
> the lob - Fields!
>
> What is wrong?
>
> Here is my testtable:
> |DROP TABLE blobtest;
> |CREATE TABLE blobtest (
> |id INTEGER,
> |mytext clob,
> |myblob blob
> |);
>
>
> Here is my testscript:
> |#!/usr/bin/env perl
> |
> |use warnings;
> |use diagnostics;
> |use strict;
> |use Getopt::Long;
> |use English;
> |use DBI;
> |
> |my $langtext="";
> |my $zaehler=0;
> |while ( $zaehler < 500 ) {
> |$langtext=$langtext . "0123456789";
> |$zaehler=$zaehler+1;
> |}
> |
> |#BD connect to Oracle
> |my $dbv=DBI->connect("dbi:Oracle:i001.tux", "yucatan", "yucatan");
> |
> |#BD Datenbank - Verbindung konfigurieren
> |$dbv->{PrintError} = 1;
> |$dbv->{AutoCommit} = 1;
> |
> |#BD delete all rows
> |$dbv->do("delete from blobtest");
> |
> |#BD Insert Statement
> |my $insertsql=< |insert into blobtest (id, mytext, myblob)
> |values (?, ?, ?)
> |EOF
> |
> |#BD Prepare the Insert Statement
> |my $sth=$dbv->prepare($insertsql);
> |
> |#BD insert first row
> |$sth->bind_param(1, 0);
> |$sth->bind_param(2, undef(), { ora_type=>112, ora_field=>'mytext' });
> |$sth->bind_param(3, undef(), { ora_type=>113, ora_field=>'myblob' });
> |$sth->execute();
> |
> |#BD insert second row
> |$sth->bind_param(1, 1);
> |$sth->bind_param(2, 'this_is_a_clob', { ora_type=>112,
> | ora_field=>'mytext' });
> |$sth->bind_param(3, 'this_is_a_blob', { ora_type=>113,
> | ora_field=>'myblob' });
> |$sth->execute();
> |
> |#BD insert third row
> |$sth->bind_param(1, 2);
> |$sth->bind_param(2, undef(), { ora_type=>112, ora_field=>'mytext' });
> |$sth->bind_param(3, undef(), { ora_type=>113, ora_field=>'myblob' });
> |$sth->execute();
> |
> |#BD insert fourth row
> |$sth->bind_param(1, 3);
> |$sth->bind_param(2, $langtext, { ora_type=>112, ora_field=>'mytext' });
> |$sth->bind_param(3, $langtext, { ora_type=>113, ora_field=>'mytext' });
> |$sth->execute();
>
> If I launch the this query:
> |select id, mytext, myblob, dbms_lob.getlength(mytext),
> | dbms_lob.getlength(myblob)
> |from blobtest
> |order by id;
>
> I get this result:
> |id mytext myblob len mytext len myblob
> | 0 NULL NULL0 0
> | 1 this_is_a_clob this_is_a_blob 14 14
> | 2 this_is_a_clob this_is_a_blob 14 14 <-ERROR ROW
> | 3 0123...0123... 5000 5000
>
>
> Regards,
> Bernhard Donaubauer
>
Re: DBD::mysqlPP and NET::MySQL
Just looks like some left-over debugging. If unsigned short
columns are fetched okay then you can probably ignore the warning.
Tim.
On Wed, Mar 12, 2003 at 05:32:07PM +0100, Stephan Harren wrote:
> I did, my first mail was:
>
> ---snip---
> > I'm working on a perl-script connecting to myqsl using the above
> > modules. This script works fine on one database-server, but if I try
> > another on (both mysql-version 3.23.55) I get a warning from Net::Mysql:
> >
> > in short at /usr/lib/perl5/site-perl/5.6.1/Net/MySQL.pm line 591.
> ---snip---
>
> while "in short at /usr/lib/perl5/site-perl/5.6.1/Net/MySQL.pm line 591" is
> the warning that I get. I know that this is a curious message (in short!?!)
> but that's why I'm asking. The code in Net::MySQL that leads to this message
> is:
>
> ---snip---
> elsif ($head == UNSIGNED_SHORT_COLUMN) {
> warn "in short"; #line 591
> my $length = unpack 'v', substr(
> $self->{packet},
> $self->{position},
> UNSIGNED_SHORT_LENGTH
> );
> $self->{position} += UNSIGNED_SHORT_LENGTH;
> return $length;
> }
> ---snip---
>
> Best regards,
>
> Stephan
>
> Am Mittwoch, 12. März 2003 17:13 schrieb BAO RuiXian:
> > You still have not given out what the warning message is.
> >
> > Best
> >
> > Bao
>
> --
> Stephan Harren
> Manager Site Operations
> MFN-IS
> ---
> Phone +49 69 90554 153
> Fax +49 69 90554 111
> Cell +49 173 7011126
>
>
Re: DBD::mysqlPP and NET::MySQL
Ask the author, or you could always try debuging it yourself. Tim. On Thu, Mar 13, 2003 at 07:29:35AM +0100, Stephan Harren wrote: > Thanks Tim, > > but what makes me worry is that this happens if I use a TEXT column and the > field content is longer than 255 !? Another point is, that there are no > "short" columns in MySQL. Maybe my knowledge on databases is too little, but > maybe you can give me an explanation for that? > > Best regards, > > Stephan > > Am Mittwoch, 12. März 2003 18:47 schrieb Tim Bunce: > > Just looks like some left-over debugging. If unsigned short > > columns are fetched okay then you can probably ignore the warning. > > > > Tim. > > -- > Stephan Harren > Manager Site Operations > MFN-IS > --- > Phone +49 69 90554 153 > Fax +49 69 90554 111 > Cell +49 173 7011126 > >
Status of DBI 1.35 (was: Install of DBI)
On Thu, Mar 13, 2003 at 09:57:12AM +0100, [EMAIL PROTECTED] wrote: > > www.perl.com/CPAN should work nicely :) > > Latest stable version of DBI would appear to be 1.30. Changes coming a bit > too fast to call the newer versions 'stable' though (sorry Tim). No need to appologise. The only problems I'm aware of for 1.35 are: perl Makefile.PL PREFIX= reported not to work (not checked yet) Minor tweak to t/80proxy.t test (not important) The t/zz_* test files are not deleted by 'make clean' (not important) So I think it's well worth testing by a wider audience now. Tim.
Re: Status of DBI 1.35 (was: Install of DBI)
On Thu, Mar 13, 2003 at 07:43:17AM -0600, James.FitzGibbon wrote: > There is one outstanding issue that I am aware of. We reported a problem > setting the RootClass > attribute in DBI v1.30, which was addressed in v1.31. Unfortunately, the > fix has a small problem. > > Here is the original message from rt.cpan.org: rt.cpan.org has not notified me about any reports filed there, so I didn't know they existed. > Mon Nov 18 17:09:05 2002 guest - Ticket created [Reply] [Comment] > Subject: Cannot set RootClass attribute to a package in the same file Thanks, I'll fix it. Tim.
test of TIMB@cpan.org
[EMAIL PROTECTED]
Re: DBD:Oracle 1.12 makefile patches for building on HPUX11
Thanks. I'll include it.
Tim.
On Fri, Mar 14, 2003 at 10:21:04AM +0100, [EMAIL PROTECTED] wrote:
> Hi,
>
> That Makefile.PL still leaves the -l:libcl.a which causes this error:
>
> /usr/bin/ld: Invalid loader fixup in text space needed in output file for
> symbol "$005C" in input file: "/usr/lib/libcl.a(ftnerr.o)". Make sure it
> was compiled with +z/+Z.
>
> Attempting to discover Oracle OCI build rules...
> cc-c DBD_ORA_OBJ.c -o DBD_ORA_OBJ.o
> Oracle oci build command:
> + -Wl,+s -Wl,+n -L/afs1/ora8174/lib/ -L/afs1/ora8174/rdbms/lib/ -o
> DBD_ORA_EXE DBD_ORA_OBJ.o /afs1/ora8174/rdbms/lib/kpudfo.o -lclntsh -lnbeq8
> -lnhost8 -lnus8 -lnldap8 -lldapclnt8 -lnsslb8 -ln8 -lncrypt8 -ln8 -lncrypt8
> -lnoname8 -lntcp8 -lntcps8 -lnsslb8 -lnent8 -lntcp8 -lntns8 -lnsgr8 -lnzjs8
> -ln8 -lnl8 -lnro8 -lnbeq8 -lnhost8 -lnus8 -lnldap8 -lldapclnt8 -lnsslb8 -ln8
> -lncrypt8 -ln8 -lncrypt8 -lnoname8 -lntcp8 -lntcps8 -lnsslb8 -lnent8 -lntcp8
> -lntns8 -lnsgr8 -lnzjs8 -ln8 -lnl8 -lclient8 -lvsn8 -lwtc8 -lcommon8
> -lgeneric8 -lwtc8 -lmm -lnls8 -lcore8 -lnls8 -lcore8 -lnls8 -lnbeq8 -lnhost8
> -lnus8 -lnldap8 -lldapclnt8 -lnsslb8 -ln8 -lncrypt8 -ln8 -lncrypt8 -lnoname8
> -lntcp8 -lntcps8 -lnsslb8 -lnent8 -lntcp8 -lntns8 -lnsgr8 -lnzjs8 -ln8 -lnl8
> -lnro8 -lnbeq8 -lnhost8 -lnus8 -lnldap8 -lldapclnt8 -lnsslb8 -ln8 -lncrypt8
> -ln8 -lncrypt8 -lnoname8 -lntcp8 -lntcps8 -lnsslb8 -lnent8 -lntcp8 -lntns8
> -lnsgr8 -lnzjs8 -ln8 -lnl8 -lclient8 -lvsn8 -lwtc8 -lcommon8 -lgeneric8
> -ltrace8 -lnls8 -lcore8 -lnls8 -lcore8 -lnls8 -lclient8 -lvsn8 -lwtc8
> -lcommon8 -lgeneric8 -lnls8 -lcore8 -lnls8 -lcore8 -lnls8
> /afs1/ora8174/rdbms/lib/kpuadef.o -l:libcl.a -l:librt.sl -lpthread
> -l:libnss_dns.1 -l:libdld.sl -lm
>
> It seem Oracle does it wrong but since it probably does it wrong on all HPUX
> with Ora8174 it's likely faster to change the Makefile.PL as opposed to
> waiting for Oracle to fix it :). The new Makefile.PL *does* seem to find
> OCI8 on our installs now, which is good.
>
> Also I got annoyed by the warning about not having perl build with +z so I
> changed that too :)
>
> Diff below and also attached (NOTE: diff based on the 1.13 Makefile.PL file
> you supplied):
>
> *** Makefile.PL.113 Fri Mar 14 10:14:02 2003
> --- Makefile.fixed.113Fri Mar 14 10:13:31 2003
> ***
> *** 441,453
> }
> }
>
> if (($linkwith !~ m/-lcl/) || ($linkwith !~ m/-lpthread/)) {
> print "Warning: Oracle is built with multi-threading
> libraries\n"
> . " You will most likely need to rebuild perl from
> sources\n"
> . " with the following libraries: -lcl
> -lpthread\n" ;
> }
>
> ! if ( ($Config{'cc'} eq 'cc') && ($Config{'ccflags'} !~ m/\+z/ ) )
> {
> print "Warning: perl was not built with +z in ccflags\n"
> . " You may need to rebuild perl from sources\n"
> . " See instructions in README.hpux\n" ;
> --- 441,458
> }
> }
>
> + if ( $os eq "hpux" && $osvers >= 11 and $linkwith =~
> m/-l:libcl.a/) {
> + print "Warning: stripping -l:libcl.a from liblist
> (conflict with ld looking for shared libs)";
> + $linkwith =~ s/\s*-l:libcl.a\b//g;
> + }
> +
> if (($linkwith !~ m/-lcl/) || ($linkwith !~ m/-lpthread/)) {
> print "Warning: Oracle is built with multi-threading
> libraries\n"
> . " You will most likely need to rebuild perl from
> sources\n"
> . " with the following libraries: -lcl
> -lpthread\n" ;
> }
>
> ! if ( ($Config{'cc'} eq 'cc') && ($Config{'ccflags'} !~ m/\+z/ &&
> $Config{'ccldflags'} !~ m/\+Z/i) ) {
> print "Warning: perl was not built with +z in ccflags\n"
> . " You may need to rebuild perl from sources\n"
> . " See instructions in README.hpux\n" ;
>
>
>
> ---
> Frans Postma, (050-58) 81 852
> ATOS Origin, Unix Support
> "If at first you don't succeed, skydiving isn't for you"
>
>
>
>
> > -Oorspronkelijk bericht-
> > Van: Tim Bunce [mailto:[EMAIL PROTECTED]
> > Verzonden: donderdag 13 maart 2003 17:48
> > Aan: [EMAIL PRO
Re: test failed (make test TEST_VERBOSE=1)
Looks like you're using DBI v1.32. Try DBI 1.35 Tim. On Fri, Mar 14, 2003 at 02:22:38PM +0800, [EMAIL PROTECTED] wrote: > Dear sir, > > I have a problem with installing the DBI. I get 2 test failed > when I perform "make test" and "make test TEST_VERBOSE=1". > Attached is the > logging message. > > Thank you very much for your help. > > Regards, > Fujin
Re: script for oracle performance
Buy this book: "Oracle performance tuning 101". You won't regret it. Tim. On Fri, Mar 14, 2003 at 10:54:24AM +0100, Filipe Vasconcelos wrote: > Hello, > > Does anybody has any script that could give, detailed information about the > performance of an Oracle Database. > > regards, > > __ > > Filipe Vasconcelos >
ANNOUNCE: DBD::Oracle 1.13
After over 18 months of "stability" it gives me great pleasure to say that the monstrous hunk of rock that is DBD::Oracle is rolling forward once again... file: $CPAN/authors/id/T/TI/TIMB/DBD-Oracle-1.13.tar.gz size: 194630 bytes md5: bcb1a887ac8f5da415a78fe7abb012b5 Special thanks are due to Jeff Urlwin who helped me greatly by handling a bunch of the outstanding issues. =head1 Changes in DBD-Oracle 1.1314th March 2003 Fixed null user issue when using OS Authentication thanks to Christopher R. Baker Fixed precision for Raw types in oci7.c thanks to J.D. Laub. Fixed LOB code for table names containing $ thanks to Wayne Volkmuth. Fixed LOB synonym handling thanks to John Milton. Fixed dbms_output_get to be immune to ora_ph_type changes thanks to Michael Fox. Fixed to now not treat SUCCESS_WITH_INFO (eg ORA-28011) on connect as an error. Updated table_info to decode SYS and SYSTEM to prepend 'SYSTEM ' thanks to Olga Voronina Updated table_info and added get_info, foreign_key_info thanks to Steffen Goeldner. Added that ShowErrorStatement is now enabled by default. Added ParamValues attribute so ShowErrorStatement includes bind_param values. Added experimental utf8 support thanks to Stefan Eissing. See README.utf8 Added BFILE support thanks to David Hull. Added :ora_session_modes export tag for ORA_SYSDBA ORA_SYSOPER constants, added ORA_STRING and ORA_CHARZ to :ora_types export tag and added docs for ora_ph_type attribute and other doc fixes, thanks to Michael A Chase. Added t/cursor.t tests thanks to Jeffrey Horn. Added ability to share connections between threads via ora_dbh_share attribute, thanks to Gerald Richter. Added ability to connect() via 'external process context', for embedding Perl DBI into Oracle server, thanks to Jeff Horwitz. Documentation changes: Updated README.hpux thanks to Lincoln Baxter and Jay Strauss. Documented ora_parse_lang, ora_auto_lob, and ora_check_sql prepare() method attributes thanks to Michael A Chase. Configuration and build related changes: Added Win32 support on systems with multiple Oracle Homes thanks To Jeff Urlwin. Fixed prototype for constant() thanks to Sreeji K Das. Fixed warning in Oraperl.pm with recent perl versions thanks to Ilya V.Rachkov. Fixed handling of shell backticks in make output during build rule discovery. Fixed Win32 build using gcc thanks to Chris R. Donnelly and Michael A Chase. Help HPUX configs by removing -l:libcl.a from liblist, thanks to Frans Postma. Assorted improvements to Makefile.PL thanks to Michael A Chase and Stephen Clouse. Updated tests and Oraperl.pm to not use old style connect (deprecated in DBI 1.33). =cut There are still many outstanding issues to address (I've over 100 separate email threads saved). I'll get to them in time, but if you've anything urgent you want in, it's *much* more likely to happen if you sent me a *tested patch*. Anything else will probably just be added to the queue. Enjoy! Tim.
Please ignore previous test email to TIMB@cpan.org
Please ignore previous test email to [EMAIL PROTECTED] I'd forgotten that I'd set [EMAIL PROTECTED] to redirect to dbi-users. Tim.
Re: shortcuts for common placeholder idioms...
On Mon, Mar 17, 2003 at 12:04:22PM -0800, Michael A Chase wrote:
> On Mon, 17 Mar 2003 05:07:36 -0600 Moritz von Schweinitz <[EMAIL PROTECTED]> wrote:
>
> > i'd just like to recommend some more hash-friendly routines for these
> > kind of operations. i know that they are relativly tricial to code, but
> > would make it all seem more "natural" for the beginners, methinks.
> >
> > something like
> >
> > $dbh->hash_do("INSERT INTO table (?) VALUES (?)", \%hash);
> >
> > (where the first ? would be expanded to something along the lines of
> > 'join(',', keys %hash)'
> > and the second ? would become something like
> > 'join(',', map($dbh->quote($_), values %hash))'
>
> That may be too specialized for DBI, but you could use a locally
> maintained module that provides the subroutines.
>
> Spliting into separate prepare and execute stages and using
> placeholders would allow prepare once and execute many times and allow
> the subroutines to be used for SELECTs. I'd also sort the hash keys
> so the order of the keys and values would be consistant.
>
> # All untested
>
># call as: my $sth = hash_prepare( $dbh, $sql, \%hash );
># %col% = place to insert column list
># %ph% = place to insert placeholder list
># %val% = place to insert value list
># %eqp% = place to insert col=? pairs
># %eqv% = place to insert col=val pairs
>sub hash_prepare {
I'd rather something like construct_sql(...) so people can use do(),
prepare(), prepare(cached) etc as needed.
> my ( $dbh, $sql, $rhash ) = @_;
> my @col = sort keys %$rhash;
> $sql =~ s/%(col|ph|val|eqp|eqv)%/
> if( "col" eq $1 ) { join ", ", @col }
> elsif ( "ph" eq $1 ) { join ", ", ("?") x @col }
> elsif ( "val" eq $1 ) { join ", ",
> map { $dbh -> quote( $$rhash{$_} ) } @col }
> elsif ( "eqp" eq $1 ) { join ", ", map { "$_ = ?" } @col }
> elsif ( "eqv" eq $1 ) { join ", ",
> map { "$_ = " . $dbh -> quote( $$rhash{$_} } @col }
>/xeg;
And using the established ODBC style of SQL escape clause would
probably be smart, so something like:
INSERT INTO table ({dbi names}) VALUES ({dbi placeholders})
INSERT INTO table ({dbi names}) VALUES ({dbi values})
UPDATE table SET ... WHERE {dbi names = placeholders}
UPDATE table SET ... WHERE {dbi names = values}
and used like:
($sql, @bind_values) = $dbh->construct_sql("...", \%hash);
$dbh->do($sql, undef, @bind_values);
or
$sth = $dbh->prepare_cached($sql);
$sth->execute(@bind_values);
Tim.
Re: whats wrong? select to array and read array...
finish() should be probably be called discard_pending_results(). It should only ever be used for SELECT statements where you have not fetched past all the returned rows. (In which case it avoids the warning message you'd otherwise get.) Tim. On Tue, Mar 18, 2003 at 10:17:19AM +0100, alex wrote: > hi > > > You do not need either finish() above. It is only necessary for > > SELECTs that don't fetch until told there are no more rows. > > fetchall_*() does fetch until then and $sth9 is not a SELECT. > > See the section on finish() in the fine DBI manual. > > is it correct - i should remove *all* finish commands from my scripts? i'm > not sure if i understood the docu correctly... my script are full of > finish's :-). i have finished everything in the past :-) > > 1. on a UPDATE it is *never* needed!? > 2. on a INSERT it is *never* needed, too!? > 3 on a SELECT it is normaly never needed - but needed in rarely situations - > i will never come in *g* > > > Alex > >
Re: Trouble: DBD Oracle on Solaris
Try DBD::Oracle 1.13. Tim. On Mon, Mar 17, 2003 at 03:58:11PM -0800, Maggie Wing (Sun Contractor) wrote: > Hi. > > I've been trying for a week now to install DBD on my > development machine. I was able to get the DBI installed, > but make-test (and by extension, yours truly) keeps failing > with the DBD stuff. > > I'm using: > > SunOS RELEASE: 5.7 > Oracle, v8.0.3 > DBI-1.34 > DBD-Oracle-1.12 > > Here's what I've done: > > I have read the README files. > > I've built, tested & installed a fresh, shiny new copy of perl5 > (5.8.0, to be exact), and it is in my path. > > I've successfully built the makefile for, made, make-tested, and > make-installed the DBI. > > I've successfully built the makefile for and made the DBD stuff, > but when I do the make-test part (with TEST_VERBOSE set to 1), > I get this (what follows is an excerpt -- the full text of the DBD- > make-test output is attached): > > > > t/general1..17 > ok 1 > ok 2 > ok 3 > ok 4 > ok 5 > ok 6 > ok 7 > ok 8 > ok 9 > ok 10 > ok 11 > # failed test 12 at line 62 > not ok 12 > ok 13 > ok 14 > ok 15 > ok 16 > ok 17 > FAILED test 12 > Failed 1/17 tests, 94.12% okay > > . > . > t/plsql..dubious > Test returned status 255 (wstat 65280, 0xff00) > t/reauth.1..0 > skipped > all skipped: no reason given > Failed Test Stat Wstat Total Fail Failed List of Failed > --- > t/general.t 171 5.88% 12 > t/plsql.t255 65280?? ?? % ?? > 1 test skipped. > *** Error code 29 > > ~~ > > > I also tried sacrificing a couple of small animals, holding my breath with > a paper bag over my head, and repeating the phrase, "I understand how to > do this" until the people in the cubes near mine got together and asked > me to "take a ten-minute break or something". > > If you think you hear a cringe-worthy whine of desperation in this post, > you're hearing right. Any help, insight, or suggestions would be greatly > appreciated. > > Thanks, Content-Description: maketest_dbd.out > PERL_DL_NONLAZY=1 /usr/local/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(1, 'blib/lib', 'blib/arch')" t/*.t > t/base...1..5 > ok 1 > ok 2 > ok 3 > ok 4 > ok 5 > ok > t/general1..17 > ok 1 > ok 2 > ok 3 > ok 4 > ok 5 > ok 6 > ok 7 > ok 8 > ok 9 > ok 10 > ok 11 > # failed test 12 at line 62 > not ok 12 > ok 13 > ok 14 > ok 15 > ok 16 > ok 17 > FAILED test 12 > Failed 1/17 tests, 94.12% okay > t/long...create table dbd_ora__drop_me ( idx integer, lng LONG, dt date ) > 1..73 > long_data0 length 10240 > long_data1 length 81920 > long_data2 length 71680 > create table dbd_ora__drop_me ( idx integer, lng LONG, dt date ) > --- insert some LONG data > ok 1 > ok 2 > ok 3 > ok 4 > --- fetch LONG data back again -- truncated - LongTruncOk == 1 > LongReadLen 20, LongTruncOk 1 > ok 5 > ok 6 > ok 7 > ok 8 > ok 9 > ok 10 > --- fetch LONG data back again -- truncated - LongTruncOk == 0 > LongReadLen 81910, LongTruncOk > ok 11 > ok 12 > ok 13 > ok 14 > ok 15 > ok 16 > --- fetch LONG data back again -- complete - LongTruncOk == 0 > LongReadLen 82920, LongTruncOk > ok 17 > ok 18 > ok 19 > ok 20 > ok 21 > ok 22 > ok 23 > ok 24 > --- fetch LONG data back again -- via blob_read > ok 25 > ok 26 > ok 27 > ok 28 > ok 29 > ok 30 > ok 31 > ok 32 > ok 33 > ok 34 > ok 35 > long_data0 length 20480 > long_data1 length 81920 > long_data2 length 71680 > create table dbd_ora__drop_me ( idx integer, lng LONG RAW, dt date ) > --- insert some LONG RAW data > ok 36 > ok 37 > ok 38 > ok 39 > --- fetch LONG RAW data back again -- truncated - LongTruncOk == 1 > LongReadLen 20, LongTruncOk 1 > ok 40 > ok 41 > ok 42 > ok 43 > ok 44 > ok 45 > --- fetch LONG RAW data back again -- truncated - LongTruncOk == 0 > LongReadLen 40955, LongTruncOk > ok 46 > ok 47 > ok 48 > ok 49 > ok 50 > ok 51 > --- fetch LONG RAW data back again -- complete - LongTruncOk == 0 > LongReadLen 82920, LongTruncOk > ok 52 > ok 53 > ok 54 > ok 55 > ok 56 > ok 57 > ok 58 > ok 59 > --- fetch LONG RAW data back again -- via blob_read > ok 60 > ok 61 > ok 62 > ok 63 > ok 64 > ok 65 > ok 66 > ok 67 > ok 68 > ok 69 > ok 70 > ok 71 > ok 72 > ok 73 > ok > t/ph_type1..53 > ok 1 > # > # testing VARCHAR2 (ora_type 1) ... > # > ok 2 > ok 3 > ok 4 > ok 5 > ok 6 > ok 7 > ok 8 > ok 9 > ok 10 > ok 11 > ok 12 > ok 13 > ok 14 > # > # testing STRING (ora_type 5) ... > # > # skipping tests > ok 15 > ok 16 > ok 17 > ok 18 > ok 19 > ok 20 > ok 21 > ok 22 > ok 23 > ok 24 > ok 25 > ok 26 > # > # testing CHAR (ora_type 96) ... > # > ok 27 > ok 28 > ok 29 > ok 30 > ok 31 > ok 32 > ok 33 > ok 34 > ok 35 > ok 36 > ok 37 > ok 38 > ok 39 > # > # testing CHARZ (ora_type 97) ... > # > # skipping tests > ok 40 > ok 41 > ok 42 > ok 43 > ok 44 > ok 45 > ok 46 > ok 47 > ok 48 > ok 49 > ok 50 > ok 51 > ok 52 > ok 53 > ok > t/plsql..
Re: Using perl 5.8.0?
Thomas, did you get round to doing this?
Tim.
On Wed, Feb 26, 2003 at 10:54:12AM +, Tim Bunce wrote:
> On Tue, Feb 25, 2003 at 05:30:31PM -0500, Thomas Good wrote:
> > On Tue, 25 Feb 2003, Tim Bunce wrote:
> >
> > > > While I was using 5.8 large data transfers via DBI failed consistently.
> > > > I have compared notes with others (including Lincoln Stein) and this
> > > > problem is easily reproduced. In fact, I can't stop reproducing it. ;-)
> > > >
> > > A self-contained test case would be ideal!
> >
> > Hi, I will try to put this together, meanwhile here is a summary:
> >
> > I have a postgres table with 220 individual patient skills -
> > these skills become questions on a long form. Another table
> > holding live patient records is queried and the returned values
> > serve as popup_menu() defaults
> >
> > Tr ( td ( "$skill[0]" ) <-- Here is the string/question
> > td ( popup_menu( ...
> >-values=>['1 - Excellent', '2 - Adequate', '3 - Needs
> > Attention',
> > '4 - Needs Immediate Attention', '5 - Not
> > Applicable'],
> >-default=>"$row->{item_01}" <-- Here is the returned value
> > ...
> >
> > On wellworn test equipment (all ide, 64M RAM, clock speed of 300MHz) running
> > Slackware 8.1, perl 5.6.1, DBI 1.25, Apache 1.3.26, DBD-Pg 1.21, Postgres 7.3.1
> > this script runs.
> >
> > On a brand new IBM eServer (LSI SCSI, 512M RAM, 2 GHz clock) running Redhat 8.0,
> > perl 5.8.0, DBI 1.28, Apache 2.0.40, DBD-Pg 1.21 the script hangs.
> > I tried commenting out the defaults, etc. Only removing both queries allowed
> > the script to run. The CGI form was not a problem, even when I doubled the
> > length as a test.
>
> Enable tracing to a log file (eg set DBI_TRACE env var to something
> like "6=/tmp/dbi.log") and then run the script using truss
> (or similar tool that shows operating system calls).
>
> As a (better) alternative to using truss you could do a kill -QUIT
> on the process once it has hung and then get a stack trace from the
> core file.
>
> That would be useful, but to be *really* helpful the DBI and DBD::Pg
> would need to be compiled and linked with debugging enabled (ie -g
> option to the compiler/linker).
>
> For the DBI you can do that by simply rebuilding it starting with
> "perl Makefile.PL -g".
>
> For DBD::Pg you may need to run "perl Makefile.PL" and then hack the
> generated Makefile: Add -g as an option on the "CCCMD = $(CC) ..."
> line and also to the "OTHERLDFLAGS =" line.
>
> Once you've got the core file you can get a stack dump using a debugger
> like gdb ("gdb /path/to/the/perl/you/used /path/to/core" then "bt".)
>
> Tim.
Re: DBD::Oracle on MacOSX - multiple definitions of symbol problem
On Wed, Mar 19, 2003 at 10:07:20PM +1000, Brook Schofield wrote: > I've been unable to install DBD::Oracle on MacOS X > > I have: > > MacOS X 10.2.4 > Perl 5.8.0 > DBI-1.35 > DBD::Oracle-1.13 > Oracle Developer Editior 9iR2 for MacOS X > > the core errors that I receive are during 'make test': > t/cursor.dyld: /usr/bin/perl multiple definitions of symbol _kpuexes > /Users/oracle/src/DBD-Oracle-1.13/blib/arch/auto/DBD/Oracle/ > Oracle.bundle definition of _kpuexes > /Users/oracle/9iR2/orahome/lib/libclntsh.dylib.9.0(kpudfo.o) definition of _kpuexes > Attempting to discover Oracle OCI build rules... > cc-c -o DBD_ORA_OBJ.o DBD_ORA_OBJ.c > by executing: > [make -f /Users/oracle/9iR2/orahome/rdbms/demo/demo_rdbms.mk build ECHODO=echo > ECHO=echo GENCLNTSH='echo genclntsh' CC=echo OPTIMIZE= CCFLAGS= EXE=DBD_ORA_EXE > OBJS=DBD_ORA_OBJ.o] > returned: > [make: *** No rule to make target `/Users/oracle/9iR2/orahome/lib/libwtc9.so', > needed by `/Users/oracle/9iR2/orahome/lib/libclntsh.dylib'. Stop. > ] > Warning: Oracle build rule discovery failed (512) It would be a big help if you could get the build rule discovery to work. Oracle ships some example code and makefiles to build the examples. What DBD::Oracle's Makefile.PL tries to do is make a dummy example and analyse what commands and options were used. So the first step is for you to try manually building one of the Oracle examples. If you can't get that to work then it's very much Oracle's problem. If you can, then we need to tweak DBD::Oracle's Makefile.PL to do the right thing for you. I can't help much more as I know very little about MacOS X. Tim.
Re: DBI Installation Problem
Perl 5.005 is not supported by the DBI. You may find 5.005_03 will work (but that version is also very old and the DBI soon won't support that). I'd recommend using perl 5.6.1. DBI-1.201 is also very old. Try 1.35. Tim. On Wed, Mar 19, 2003 at 12:38:43PM +, Venky Karuppur wrote: > Hello All, > I have attached here the log files (and error files) during the > installation of DBI-1.201 on to a SCO box. I had error during Make Test > process. Guess the attached file will tell more abt the problem. Help > please!.. > > Thanks > Venky > > > > > > _ > Surf together with new Shared Browsing > http://join.msn.com/?page=features/browse&pgmarket=en-gb&XAPID=74&DI=1059
Re: DBD::Oracle on MacOSX - multiple definitions of symbol problem
On Thu, Mar 20, 2003 at 07:59:52AM +1000, Brook Schofield wrote: > I haven't yet attempted the examples but I was hoping that the > instructions and associated downloads from Tom Mornini > ([EMAIL PROTECTED]) where more widely available: They are... they're now shipped with DBD::Oracle in the README.macosx file :) Tim. > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=400FBBA7-FE88- > 11D6-A100-00306546AE4A%40infomania.com > > as I can't seem to connect to his website. It seems like some very good > DBD::Oracle on MacOSX instructions - I just can't try them out. > > -Brook > > On Thursday, March 20, 2003, at 12:05 AM, Tim Bunce wrote: > > >the first step is for you to try manually building one of the Oracle > >examples. > >If you can't get that to work then it's very much Oracle's problem. > >If you can, then we need to tweak DBD::Oracle's Makefile.PL to do the > >right thing for you. >
Re: DBD::Oracle on MacOSX - multiple definitions of symbol problem
On Wed, Mar 19, 2003 at 10:21:20PM +, Tim Bunce wrote: > On Thu, Mar 20, 2003 at 07:59:52AM +1000, Brook Schofield wrote: > > I haven't yet attempted the examples but I was hoping that the > > instructions and associated downloads from Tom Mornini > > ([EMAIL PROTECTED]) where more widely available: > > They are... they're now shipped with DBD::Oracle in the README.macosx file :) Ah, of course it would be *much* better if someone could send me the required patches to DBD::Oracle. That way the README.macosx file would be a lot smaller! Tim. > Tim. > > > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=400FBBA7-FE88- > > 11D6-A100-00306546AE4A%40infomania.com > > > > as I can't seem to connect to his website. It seems like some very good > > DBD::Oracle on MacOSX instructions - I just can't try them out. > > > > -Brook > > > > On Thursday, March 20, 2003, at 12:05 AM, Tim Bunce wrote: > > > > >the first step is for you to try manually building one of the Oracle > > >examples. > > >If you can't get that to work then it's very much Oracle's problem. > > >If you can, then we need to tweak DBD::Oracle's Makefile.PL to do the > > >right thing for you. > >
Re: DBD::Oracle on MacOSX - multiple definitions of symbol problem
On Thu, Mar 20, 2003 at 05:17:48PM +1000, Brook Schofield wrote: > Patches are available from: > > http://199.182.37.33/dbd-oracle-osx/Makefile.PL.patch > http://199.182.37.33/dbd-oracle-osx/oracle-support.tar.gz > http://199.182.37.33/dbd-oracle-osx/dbd-support.tar.gz > > as Tim let his domain name lapse. > > NB:- patches are against DBD::Oracle-1.12 not 1.13 Thanks. Since I don't have a MacOS X system I can't test any of this or reliably do any integration work. But I would like to see better MacOS X support included in the DBD::Oracle distribution. So, I'm looking for a volunteer to work on this. Any offers? Firstly, I'd really like the 'build rule discovery' process to work for MacOS X, or at least have a very good understanding of why it can't be used. (Don't Oracle ship buildable examples on MacOS X?) Secondly, the removable_symbols_dbd_create.pl logic can be integrated into Makefile.PL. Thirdly, ... anything else to make life easier... Tim. > -Brook > > On Thursday, March 20, 2003, at 08:37 AM, Tim Bunce wrote: > > >On Wed, Mar 19, 2003 at 10:21:20PM +, Tim Bunce wrote: > >>On Thu, Mar 20, 2003 at 07:59:52AM +1000, Brook Schofield wrote: > >>>I haven't yet attempted the examples but I was hoping that the > >>>instructions and associated downloads from Tom Mornini > >>>([EMAIL PROTECTED]) where more widely available: > >> > >>They are... they're now shipped with DBD::Oracle in the README.macosx > >>file :) > > > >Ah, of course it would be *much* better if someone could send me > >the required patches to DBD::Oracle. That way the README.macosx > >file would be a lot smaller! > > > >Tim. > > > >>Tim. > >> > >>>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=400FBBA7- > >>>FE88- > >>>11D6-A100-00306546AE4A%40infomania.com > >>> > >>>as I can't seem to connect to his website. It seems like some very > >>>good > >>>DBD::Oracle on MacOSX instructions - I just can't try them out. > >>> > >>>-Brook > >>> > >>>On Thursday, March 20, 2003, at 12:05 AM, Tim Bunce wrote: > >>> > >>>>the first step is for you to try manually building one of the Oracle > >>>>examples. > >>>>If you can't get that to work then it's very much Oracle's problem. > >>>>If you can, then we need to tweak DBD::Oracle's Makefile.PL to do > >>>>the > >>>>right thing for you. > >>> > > >
(Fwd) Oracle 9i and DBD::Oracle
- Forwarded message from Carlos Ferreiro <[EMAIL PROTECTED]> - Delivered-To: [EMAIL PROTECTED] From: "Carlos Ferreiro" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Oracle 9i and DBD::Oracle Date: Thu, 20 Mar 2003 09:40:01 +0100 X-MDRemoteIP: 192.168.0.249 X-Return-Path: [EMAIL PROTECTED] X-MDaemon-Deliver-To: [EMAIL PROTECTED] Hello. I have read one of your comments and I am very sad about my installation of DBD::Oracle because I can't make it work. I have IRIX 6.5 and perl v.5.6.1 for ixix-n32. Could you help me please?? Thank you - End forwarded message -
Re: Retrieving the selected value from a popup_menu()/html select
I'm sure this could be done with much less code.
Any volunteers to try to create a shorter version?
Perhaps using selectall_hashref().
Tim.
On Fri, Mar 21, 2003 at 04:39:13PM -0800, Colette Lamm wrote:
> I have successfully created code that generates a popup_menu with the fields
> id & name. I would like to retrieve user's selection though by retrieving
> the selected id and passing it to functions that update a mysql database
> with the use of an Insert and an Update statement.
> What is the correct way to retrieve the selected value and pass it to to my
> functions?
>
> Thank you, Colette
>
> Here is the code at this point...
>
> #!/usr/bin/perl -w
> use CGI qw(:standard);
> use strict;
> use DBI;
> require
> '/home/httpd/secure.webhostinglogic.com/cgi-bin/database/mysql/dbfunctions.p
> l';
>
> my $mydbi = DBI->connect("DBI:mysql:webhostinglogic","whldb","whl96!pi") or
> die "Could not connect";
>
> ###
> # Popup Menus #
> ###
> my ($adsource_sth,$adsource_ref);
> my %adsource_hash=();
> my @adsource_array=();
> my $adsource_sql="SELECT ADVERTISING_SOURCE_ID,ADVERTISING_SOURCE FROM
> ADVERTISING_SOURCE";
> $adsource_sth=$mydbi ->prepare (qq{$adsource_sql})||die "unable to prepare
> statement ",$adsource_sql," :",$DBI::errstr;
> $adsource_sth->execute;
> $adsource_ref=$adsource_sth->fetchall_arrayref();
> $adsource_sth->finish;
>
> foreach (@{$adsource_ref})
> {
>if ($_->[0])
>{
> $adsource_hash{$_->[1]}=$_->[0];
> push (@adsource_array,$_->[1]);
> }
> }
>
> my ($actype_sth,$actype_ref);
> my %actype_hash=();
> my @actype_array=();
> my $actype_sql="SELECT ACCOUNT_TYPE_ID,ACCOUNT_TYPE FROM ACCOUNT_TYPE";
> $actype_sth=$mydbi ->prepare (qq{$actype_sql})||die "unable to prepare
> statement ",$actype_sql," :",$DBI::errstr;
> $actype_sth->execute;
> $actype_ref=$actype_sth->fetchall_arrayref();
> $actype_sth->finish;
>
> foreach (@{$actype_ref})
> {
>if ($_->[0])
>{
> $actype_hash{$_->[1]}=$_->[0];
> push (@actype_array,$_->[1]);
>}
> }
>
> ##
> # Begin HTML #
> ##
> print header('text/html');
> print <
>
> Web Hosting Logic DB Interface (Customer)
>
>
>
>
>
> Web Hosting Logic DB
> Interface(Customer)
> Customer Id:
> Company Name:
> Last Name:
> First Name:
> Phone:
> Fax:
> Email:
> URL:
> Address 1:
> Address 2:
> City:
> State:
> Zip:
> Country: name="country">
> Security Question: name="securityquestion">
> Security Answer: name="securityanswer">
> Notes:
> Current Customer:
> No
> Yes
>
> Advertising Source:
>
> HTML_1
> print popup_menu(-name=>'adsource',-value=>[EMAIL PROTECTED]);
> my $advertisingsourceid=param("adsource");
>
> print <
> Account Type:
>
> HTML_2
> print popup_menu(-name=>'actype',-value=>[EMAIL PROTECTED]);
> my $accounttypeid=param("actype");
>
> print <
> DateStarted: name="datestarted">
>
>
>
>
>
>
>
>
> HTML_3
>
> my ($CustomerId) = param("customerid");
> my ($Company) = param("company");
> my ($LastName) = param("lastname");
> my ($FirstName) = param("firstname");
> my ($Phone) = param("phone");
> my ($Fax) = param("fax");
> my ($Email) = param("email");
> my ($URL) = param("url");
> my ($Address1) = param("address1");
> my ($Address2) = param("address2");
> my ($City) = param("city");
> my ($State) = param("state");
> my ($Zip) = param("zip");
> my ($Country) = param("country");
> my ($SecurityQuestion) = param("securityquestion");
> my ($SecurityAnswer) = param("securityanswer");
> my ($Notes) = param("notes");
> my ($AdvertisingSourceId) = param("advertisingsourceid");
> my ($AccountTypeId) = param("accounttypeid");
> my ($CurrentCustomer) = param("currentcustomer");
> my ($DateStarted) = param("datestarted");
>
> my ($DBInsert) = param("insert");
> my ($DBDelete) = param("delete");
> my ($DBUpdate) = param("update");
> my ($DBSelect) = param("select");
>
> my $result=0;
>
> if ($DBSelect)
> {
> my $result = SelectCustomer();
> }
>
> if ($DBUpdate)
> {
>
> print $AdvertisingSourceId $AccountTypeId;
> my $result=
> UpdateCustomer($CustomerId,$Company,$LastName,$FirstName,$Phone,$Fax,$Email,
> $URL,$Address1,$Address2,$City,$State,$Zip,$Country,$SecurityQuestion,$Secur
> ityAnswer,$Notes,$AdvertisingSourceId,$AccountTypeId,$CurrentCustomer,$DateS
> tarted);
>
> my $result2= SelectCustomer();
> }
>
> print <
>
>
>
> END_Page
>
>
>
>
Re: Problem installing DBI module
On Fri, Mar 21, 2003 at 05:43:08PM -0500, SMITH,MICHAEL C (HP-PaloAlto,ex1) wrote: > I'm having a problem installing the DBI module on a Red Hat 8.0 system, > using Perl 5.8.0. There are two problems that show up in the build, > relating to t/40profile.t test and t/42prof_data.t. Those problems will not affect Bugzilla so you can go ahead and install. The failures are a bit of a puzzle though... t/40profile# Failed test 20 in t/40profile.t at line 91 t/42prof_data..Invalid data syntax format in dbi.prof line 14: = 20 0.96 0.001162 -0.007478 0.001162 +1048282722.560548 1048282722.573056 at t/42prof_data.t line 48 Both seem to be due to your system clock occasionally going slightly backwards in time! How repeatable is it? Do the tests always fail or just sometimes? When it does fail are the numbers shown similar (especially the negative one)? Tim. p.s. Where did you get the [EMAIL PROTECTED] email address from? It's not been valid for well over a year.
Re: Problem installing DBI module
Try [EMAIL PROTECTED] or else [EMAIL PROTECTED] will give you the info. Tim. On Sat, Mar 22, 2003 at 06:14:47PM -0500, Thomas A. Lowery wrote: > Tim, > For some reason none of my posts are making it to the list. > Do you have a contact with perl.org regarding the mail list? > > Thanks, > Tom > > On Sat, Mar 22, 2003 at 08:06:33PM +, Tim Bunce wrote: > > On Fri, Mar 21, 2003 at 05:43:08PM -0500, SMITH,MICHAEL C (HP-PaloAlto,ex1) wrote: > > > I'm having a problem installing the DBI module on a Red Hat 8.0 system, > > > using Perl 5.8.0. There are two problems that show up in the build, > > > relating to t/40profile.t test and t/42prof_data.t. > > > > Those problems will not affect Bugzilla so you can go ahead and install. > > > > The failures are a bit of a puzzle though... > > > > t/40profile# Failed test 20 in t/40profile.t at line 91 > > t/42prof_data..Invalid data syntax format in dbi.prof line 14: = 20 > > 0.96 0.001162 -0.007478 0.001162 > > +1048282722.560548 1048282722.573056 at t/42prof_data.t line 48 > > > > Both seem to be due to your system clock occasionally going slightly > > backwards in time! > > > > How repeatable is it? Do the tests always fail or just sometimes? > > When it does fail are the numbers shown similar (especially the > > negative one)?
Re: Slackware 8.0
Upgrade to DBD::Oracle 1.13 first, then try again. Tim. On Mon, Mar 24, 2003 at 04:57:44PM +0100, Salvatore Sorrentino wrote: > > Dear Sirs, could you help me in resolving the following error installing > DBD under Slackware? Here is the error: > > bash-2.05a# perl Makefile.PL > Using DBI 1.33 installed in > /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBI > Duplicate specification "S=s" for option "s" > > Configuring DBD::Oracle ... > > >>> Remember to actually *READ* the README file! > Especially if you have any problems. > > Using Oracle in /home/utenteOracle/OraHome1 > Found header files in rdbms/demo. > Found /home/utenteOracle/OraHome1/precomp/demo/proc/demo_proc.mk > Using /home/utenteOracle/OraHome1/precomp/demo/proc/demo_proc.mk > Reading /home/utenteOracle/OraHome1/precomp/demo/proc/demo_proc.mk. > Reading /home/utenteOracle/OraHome1/precomp/lib/env_precomp.mk. > Deleting ORA_NLS = $(ORACLE_HOME)/ocommon/nls/admin/data/ > because it is not already set in the environment > and it can cause ORA-01019 errors. > Deleting ORA_NLS33 = $(ORACLE_HOME)/ocommon/nls/admin/data/ > because it is not already set in the environment > and it can cause ORA-01019 errors. > Appending '-ldl' to TTLIBS > > Attempting to discover Oracle OCI build rules... > cc -c . public public demo public public > -I/home/utenteOracle/OraHome1/rdbms/demo > -I/home/utenteOracle/OraHome1/rdbms/demo -I/usr/l > ocal/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBI -fno-strict-aliasing > -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS > =64 -O3 -DVERSION=\"1.09\" -DXS_VERSION=\"1.09\" -fpic > "-I/usr/local/lib/perl5/5.8.0/i686-linux/CORE" -DNO_OCI8 DBD_ORA_OBJ.c > cc: public: No such file or directory > cc: public: No such file or directory > cc: demo: No such file or directory > cc: public: No such file or directory > cc: public: No such file or directory > make: *** [DBD_ORA_OBJ.o] Error 1 > Oracle oci build command: > echo -o DBD_ORA_EXE DBD_ORA_OBJ.o > -L/home/utenteOracle/OraHome1/lib/ -lclntsh `cat > /home/utenteOracle/OraHome1/lib/ldflags` > `cat /home/utenteOracle/OraHome1/lib/sysliblist` -ldl -lm > -o DBD_ORA_EXE DBD_ORA_OBJ.o -L/home/utenteOracle/OraHome1/lib/ > -lclntsh -lnbeq9 -lnhost9 -lnus9 -lnldap9 -lldapclnt9 -lnssl > b9 -lnoname9 -lntcp9 -lntcps9 -lnsslb9 -lntcp9 -lntns9 -ldl -lm -lpthread > -lnsl -ldl -lm > Unable to interpret Oracle oci build commands. Using fallback approach. > > > System: perl5.008 linux pcextsys05 2.4.18 #2 thu feb 13 11:36:28 utc 2003 > i686 unknown > Compiler: cc -O3 -fno-strict-aliasing -I/usr/local/include > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > Linker: /usr/bin/ld > Sysliblist: -ldl -lm -lpthread -lnsl > Oracle makefiles would have used these definitions but we override them: > CC: cc > > CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ > $(SHARED_CFLAG) $(USRFLAGS) >[$(GFLAG) -O3 $(CDEBUG) -trigraphs -fPIC -DPRECOMP -I. > -I/home/utenteOracle/OraHome1/precomp/public -I/home/utenteOracle/ > OraHome1/rdbms/public -I/home/utenteOracle/OraHome1/rdbms/demo > -I/home/utenteOracle/OraHome1/plsql/public -I/home/utenteOracle/OraHo > me1/network/public -DLINUX -D_GNU_SOURCE -D_LARGEFILE64_SOURCE=1 > -D_LARGEFILE_SOURCE=1 -DSLTS_ENABLE -DSLMXMX_ENABLE -D_REENTRANT -D > NS_THREADS $(LPFLAGS) $(USRFLAGS)] > > build: $(CC) -o $(EXE) $(OBJS) $(LDPATHFLAG)$(LIBHOME) $(PROLDLIBS) > Evaluating `cat $(LIBHOME)ldflags` > expanded `cat /home/utenteOracle/OraHome1/lib/ldflags` > returned '-lnbeq9 -lnhost9 -lnus9 -lnldap9 -lldapclnt9 -lnsslb9 > -lnoname9 -lntcp9 -lntcps9 -lnsslb9 -lntcp9 -lntns9 ' > Evaluating `cat $(LIBHOME)sysliblist` > expanded `cat /home/utenteOracle/OraHome1/lib/sysliblist` > returned '-ldl -lm -lpthread -lnsl' >[ cc -o $(EXE) $(OBJS) -L$(LIBHOME) -lclntsh -lnbeq9 -lnhost9 > -lnus9 -lnldap9 -lldapclnt9 -lnsslb9 -lnoname9 -lntcp9 -lnt > cps9 -lnsslb9 -lntcp9 -lntns9 $(EXPDLIBS) $(EXOSLIBS) -ldl -lm -lpthread > -lnsl -ldl -lm $(USRLIBS) ] > > LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) > $(LDPATHFLAG)$(LIBHOME)stubs/ >[-o $@ -L/home/utenteOracle/OraHome1/precomp/lib/ -L$(LIBHOME) > -L$(LIBHOME)stubs/] > > > Linking with -L/home/utenteOracle/OraHome1/lib -lclntsh [from > $(LIBCLNTSH)] > > > Use of uninitialized value in substitution (s///) at Makefile.PL line > 1124. > LD_RUN_PATH=/home/utenteOracle/OraHome1/lib:/home/utenteOracle/OraHome1/rdbms/lib > Using DBD::Oracle 1.09. > Using DBD::Oracle 1.09. > Using DBI 1.33 installed in > /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/auto/DBI > Writing Makefile for DBD::Oracle > > *** If you have problems... > read all the log printed above, and the README and README.help files. > (Of course, you have read README by now anyway, haven't you?) > > -
Re: DBD:Oracle for Oracle 9.0.2 and 9.2 ?
On Tue, Mar 25, 2003 at 09:04:41AM +0100, [EMAIL PROTECTED] wrote: > Hi all, > > > > Currently in a project to convert our existing 7.3.4 and 8.1.7 Databases > to Oracle9i.( Either the 9.0.1 or 9.2 version ) Now I'm having some > problems connecting to some test databases I have setup. Do I need to > upgrade my perl version or Dbi / DBD version to be able to connect? You could try just rebuilding them, but upgrading may be a good idea. Tim. > I keep getting the : > > > > DBI->connect(servwhDBMET) failed: ORA-03113: end-of-file on > communication channel (DBD: login failed) > > > > Error and this points to an incorrect sqlnet communication between the > client and the server. > > > > Any help is greatly appreciated. > > > > Kind regards > > > > Bjorn Naessens > > system engineer > > > > >
Re: Slackware 8.0
On Tue, Mar 25, 2003 at 09:06:16AM +0100, Salvatore Sorrentino wrote: > Thanks for your answer. > I upgraded to DBD::Oracle 1.13 then I tried again. > This time things seems better but nevertheless there is an error: > ocidfn.h and ociapr.h include files are missing. > Could you please help me again? You need to install them from the Oracle media. They're probably in the OCI or Pro*C packages. Tim.
Re: DBD:Oracle for Oracle 9.0.2 and 9.2 ?
Or wait a day or so till DBD::Oracle 1.14 is out. Tim. On Tue, Mar 25, 2003 at 10:41:03AM -0500, [EMAIL PROTECTED] wrote: > To build with Oracle 9.x and the current version of DBD-Oracle. You care > going to have to hack the generated Makefile to change all the Oracle > library paths from lib to lib32. And to run you are going to have to update > your SHLIB_PATH to point to $ORACLE_HOME/lib32. > > > Lincoln > > > -Original Message- > From: Tim Bunce [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2003 5:38 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: DBD:Oracle for Oracle 9.0.2 and 9.2 ? > > On Tue, Mar 25, 2003 at 09:04:41AM +0100, [EMAIL PROTECTED] wrote: > > Hi all, > > > > > > > > Currently in a project to convert our existing 7.3.4 and 8.1.7 Databases > > to Oracle9i.( Either the 9.0.1 or 9.2 version ) Now I'm having some > > problems connecting to some test databases I have setup. Do I need to > > upgrade my perl version or Dbi / DBD version to be able to connect? > > You could try just rebuilding them, but upgrading may be a good idea. > > Tim. > > > I keep getting the : > > > > > > > > DBI->connect(servwhDBMET) failed: ORA-03113: end-of-file on > > communication channel (DBD: login failed) > > > > > > > > Error and this points to an incorrect sqlnet communication between the > > client and the server. > > > > > > > > Any help is greatly appreciated. > > > > > > > > Kind regards > > > > > > > > Bjorn Naessens > > > > system engineer > > > > > > > > > >
Re: DBD:Oracle for Oracle 9.0.2 and 9.2 ?
On Tue, Mar 25, 2003 at 05:51:01PM +0100, [EMAIL PROTECTED] wrote: > > Errr... why the rapid new releases all of a sudden ? Errr... well I could take an 18 month break from DBD::Oracle development again, if you'd like :) Or else I could work towards addressing at least the main build / perl version / os version compatibility issues so it'll build 'out of the box' in more places. That's been the priority for 1.13 and 1.14. There's likely to be a pause for a while after 1.14 (assuming there are no significant problems in that release). Tim. > Besides, you only need to changed those entries to lib32 if you don't have a > 64bit perl build. I did succeed building a 64bit perl and get it to work > with a DBD built versus standard Oracle 9.2.0.2 on a HPUX 11i system. Worked > fine. The trouble was/is that we need ndbm libs which are difficult to find > (and get to work) for 64bit HPUX :(. So in the end we're using a DBD build > on a 8.1.7.4 oracle to talk to the 9.2 database. > > I'm not all that sure it's desirable to use 32bit libraries when using > Oracle9. I tried that first on our HP systems but couldn't get it to work > reasonably fast. So I went the 64bit route and hit the ndbm problem, but at > least we know the 64bit approach by itself DOES work :) > > (need to add "-Dcc=cc -Ui_dbm useposix=true -A prepend:libswanted='cl > pthread ' -Duse64bitall " to your Configure command to get a nicely working > 64bit perl on HP, for those interested) > > Greetings, > > --- > Frans Postma, (050-58) 81 852 > ATOS Origin, Unix Support > "If at first you don't succeed, skydiving isn't for you" > > > > > > -Oorspronkelijk bericht- > > Van: Tim Bunce [mailto:[EMAIL PROTECTED] > > Verzonden: dinsdag 25 maart 2003 17:39 > > Aan: [EMAIL PROTECTED] > > CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Onderwerp: Re: DBD:Oracle for Oracle 9.0.2 and 9.2 ? > > > > > > Or wait a day or so till DBD::Oracle 1.14 is out. > > > > Tim. > > > > On Tue, Mar 25, 2003 at 10:41:03AM -0500, [EMAIL PROTECTED] wrote: > > > To build with Oracle 9.x and the current version of > > DBD-Oracle. You care > > > going to have to hack the generated Makefile to change all > > the Oracle > > > library paths from lib to lib32. And to run you are going > > to have to update > > > your SHLIB_PATH to point to $ORACLE_HOME/lib32. > > > > > > > > > Lincoln > > > > > > > > > -Original Message- > > > From: Tim Bunce [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, March 25, 2003 5:38 AM > > > To: [EMAIL PROTECTED] > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: DBD:Oracle for Oracle 9.0.2 and 9.2 ? > > > > > > On Tue, Mar 25, 2003 at 09:04:41AM +0100, > > [EMAIL PROTECTED] wrote: > > > > Hi all, > > > > > > > > > > > > > > > > Currently in a project to convert our existing 7.3.4 and > > 8.1.7 Databases > > > > to Oracle9i.( Either the 9.0.1 or 9.2 version ) Now I'm > > having some > > > > problems connecting to some test databases I have setup. > > Do I need to > > > > upgrade my perl version or Dbi / DBD version to be able > > to connect? > > > > > > You could try just rebuilding them, but upgrading may be a > > good idea. > > > > > > Tim. > > > > > > > I keep getting the : > > > > > > > > > > > > > > > > DBI->connect(servwhDBMET) failed: ORA-03113: end-of-file on > > > > communication channel (DBD: login failed) > > > > > > > > > > > > > > > > Error and this points to an incorrect sqlnet > > communication between the > > > > client and the server. > > > > > > > > > > > > > > > > Any help is greatly appreciated. > > > > > > > > > > > > > > > > Kind regards > > > > > > > > > > > > > > > > Bjorn Naessens > > > > > > > > system engineer > > > > > > > > > > > > > > > > > > > > > >
Re: Problem with Apache::Session and LongReadLen
On Tue, Mar 25, 2003 at 09:55:40AM -0700, Ken Miller wrote: > I've got a strange problem with Apache::Session, and DBD::Oracle: > > [Tue Mar 25 10:01:03 2003] [error] Invoking view: /security/list-users.html > --> DBH LONG READ LEN: 256000 <-- > --> STATEMENT LONG READ LEN: 256000 <-- > [Tue Mar 25 10:01:05 2003] [error] Error trying to access session: > DBD::Oracle::st fetchrow_arrayref failed: ORA-24345: A Truncation or null > fetch error occurred (DBD ERROR: ORA-01406 error on field 1 of 1, ora_type > 8, LongReadLen too small and/or LongTruncOk not set) [for statement `` > SELECT a_session FROM sessions WHERE id = ? FOR UPDATE'' > with params: :p1='eb9d7cb85362e686ed6dacb5bd9caea8']) at > /home/miller/lib/perl5/site_perl/5.6.1/Apache/Session/Store/Oracle.pm line > 83. > > I looked at the session in question I was tring to fetch, and found that the > length of the session was 8718 bytes. 8718 is a *lot* less than 256000 > bytes, so there should not have been an error. But 256000 is a lot more than 64K and that _might_ be the problem (on some Oracle and/or DBD::Oracle versions). Try setting LongReadLen to 64000. Also try fetching DBD::Oracle 1.13 (or 1.14 in a day or so) and run the test suite. The t/long.t test should pass and thus demonstrate that LongReadLen can be set higher than 64K. > The strange thing is that this error is not consistent. I can populate the > session with a large set of data, access a few other pages (which in turn > causes the session to be loaded), and then it fails. Or, it can fail on the > next request after loading the session. It's always possible there's a deeper bug lurking in there, but I'd need a small self-contained test case in order to find it. Tim.
Re: Problem with Apache::Session and LongReadLen
Smells of memory corruption. Not good.
If you can turn that script into a patch to the t/longs.t that
demonstrates the problem (just to save me some time), I will attempt
to fix it asap.
Just send it direct to me along with a summary of your configuration
(perl -V output, DBI version, Oracle client and server version, etc).
Thanks.
Tim.
On Tue, Mar 25, 2003 at 11:25:59AM -0700, Ken Miller wrote:
> A bit more information. I'm wondering if something is broken with my perl
> installation. Here's a sample program I wrote to test out the fetching of
> longs from the sessions table:
>
> #!/usr/local/bin/perl -w
>
> use strict;
> use DBI;
>
> my $dbh = DBI->connect( 'dbi:Oracle:SSS', 'websec', 'websec',
> { LongReadLen => 256000,
> RaiseError => 1 } );
>
> $| = 1;
>
> for( ;; ) {
> my $stmt = $dbh->prepare_cached(qq{ select a_session from sessions for
> update});
> $stmt->execute;
> while( my( $x ) = $stmt->fetchrow_array ) {
> print length( $x ), "\n";
> }
> print "\n";
> $stmt->finish;
> }
>
> If LongReadLen is set to a value smaller then the smallest LONG in the
> sessions table, I get this error:
>
> Bad hash at ./test line 15.
>
> Erk! That's an internal perl error. If LongReadLen is greater than the
> longest long, I see no error. The script runs forever, gladly fetching the
> sessions with no errors.
>
> Now, what makes this even more interesting is that when I trace the above
> with LongReadLen set to a small value, I don't get the 'Bad hash' error.
> Here's the log at trace level 1:
>
> pink:/home/miller/src> ./test
> DBI::db=HASH(0x8261690) trace level set to 1 in DBI 1.35-nothread
> 1 <- FETCH('CachedKids')= undef at DBI.pm line 1410
> 1 <- STORE('CachedKids' HASH(0x81cae14))= 1 at DBI.pm line 1411
> 1 <- prepare(' select a_session from sessions for update' undef)=
> DBI::st=HASH(0x826178c) at DBI.pm line 1423
> <- prepare_cached(' select a_session from sessions for update')=
> DBI::st=HASH(0x826178c) at test line 15
> <- execute= '0E0' at test line 16
> !! ERROR: 24345 'ORA-24345: A Truncation or null fetch error occurred
> (DBD ERROR: ORA-01406 error on field 1 of 1, ora_type 8, LongReadLen too
> small and/or LongTruncOk not set)'
> <- fetchrow_array= ( ) [0 items] row1 at test line 17
> Bad hash at ./test line 17.
>error: 24345 'ORA-24345: A Truncation or null fetch error occurred
> (DBD ERROR: ORA-01406 error on field 1 of 1, ora_type 8, LongReadLen too
> small and/or LongTruncOk not set)'
> <- DESTROY= undef
>error: 24345 'ORA-24345: A Truncation or null fetch error occurred
> (DBD ERROR: ORA-01406 error on field 1 of 1, ora_type 8, LongReadLen too
> small and/or LongTruncOk not set)'
> <- DESTROY= undef
>
> This is *very* strange
>
> -klm.
>
> > -Original Message-
> > From: Ken Miller [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, March 25, 2003 9:56 AM
> > To: Dbi-Users
> > Subject: Problem with Apache::Session and LongReadLen
> >
> >
> > I've got a strange problem with Apache::Session, and DBD::Oracle:
> >
> > [Tue Mar 25 10:01:03 2003] [error] Invoking view:
> > /security/list-users.html
> > --> DBH LONG READ LEN: 256000 <--
> > --> STATEMENT LONG READ LEN: 256000 <--
> > [Tue Mar 25 10:01:05 2003] [error] Error trying to access session:
> > DBD::Oracle::st fetchrow_arrayref failed: ORA-24345: A Truncation or null
> > fetch error occurred (DBD ERROR: ORA-01406 error on field 1 of 1, ora_type
> > 8, LongReadLen too small and/or LongTruncOk not set) [for statement ``
> > SELECT a_session FROM sessions WHERE id = ? FOR UPDATE''
> > with params: :p1='eb9d7cb85362e686ed6dacb5bd9caea8']) at
> > /home/miller/lib/perl5/site_perl/5.6.1/Apache/Session/Store/Oracle.pm line
> > 83.
> >
> > I looked at the session in question I was tring to fetch, and
> > found that the
> > length of the session was 8718 bytes. 8718 is a *lot* less than 256000
> > bytes, so there should not have been an error.
> >
> > The strange thing is that this error is not consistent. I can
> > populate the
> > session with a large set of data, access a few other pages (which in turn
> > causes the session to be loaded), and then it fails. Or, it can
> > fail on the
> > next request after loading the session.
> >
> > You can see by the --> <-- delimited comments above that both the database
> > handle and statement handle have been set to 256000 bytes. This
> > only seems
> > to slightly help the problem, in that the error doesn't occur immediately
> > after the session load.
> >
> > Anyone have any ideas?
> >
> > I'm running perl 5.6.1, with current (stable) versions of Apache::Session,
> > DBI, and DBD::Oracle. I'm communicating with Oracle 8.1.7. I've also
> > included a trace below showing the error, with the LongReadLen=256000.
> >
> > Cheers!
> >
> >-klm.
> >
> > -> FETCH for DBD::Oracle::st (DBI::st=HASH(0x999c810)~0x999a738
