Re: ANNOUNCE: DBD::Oracle 1.25 Release Candidate 1
On Fri, 2010-07-16 at 13:04 -0400, John Scoles wrote: > John Scoles wrote: > > Nobody wants to play with my new toy? > I will, waiting for our dba to setup the DRCP for me. > :( > > > Well it is finally here the 'two bit' version of DBD::Oracle 1.25 > > > > You can find the release candidate here > > > > http://svn.perl.org/modules/dbd-oracle/trunk/DBD-Oracle-1.25-RC1.tar.gz > > > > Any and all testing will be most welcome! > > > > The big add in this time is support for DRCP (Database Resident Connection > > Pool) if you happen to be using 11g or later > > > > As well 'get_info' has been greatly expanded > > > > Plus the the usual hodgepodge of bug fixes detailed below > > > > Added support for the OCIPing by John Scoles > > Spell checked the pod (the first time in a while me thinks) updated the > > todo By John Scoles > > Added support for DCRP (Database Resident Connection Pooling) by John > > Scoles with Luben Karavelov > > Fix for odd error with Ping from Tom Payerle > > Removed the NEW_OCI_INIT compile directive and the deprecated > > OCIInitialize calls > > Fix for rt.cpan.org Ticket #=57256 : Double free problem in dbdimp.c by > > John Scoles > > Fix for invalid format in trace of OCILobLocatorIsInit_log_stat reported > > by Martin Evans Fixed by John Scoles > > Fix for very odd UNKNOWN OCI STATUS 1041 (OCILobFreeTemporary) on > > disconnect reported by John Parker and Bob Mcgowan fixed by John Scoles > > Fix for rt.cpan.org Ticket #=55445: get_info(28) SQL_IDENTIFIER_CASE seems > > to return the wrong value from Martin J Evans and a bunch of re jigging from > > John Scoles > > Patch for PL/SQL: numeric or value error: character string buffer too > > small from Scott T. Hildreth > > Fix for rt.cpan.org Ticket #=51594 type_info and type_info_all miss vital > > information from John Scoles > > Added ora_lob_is_init function by John Scoles > > Fix for rt.cpan.org Ticket #=55031 Ubuntu Server Building with Oracle XE > > under 32-bit from Brian Candler > > Fix for rt.cpan.org Ticket #=56810 bug with multiple nested cursor from > > John Scoles > > Fix for bug found only on Big-Endian hardware reported by Timothy Everett > > and others from Charles Jardine > > Fix for memory leak when using prepared_cached and lobs reported by Mark > > Bobak and Martin Evans found and fixed by John Scoles and a test from Martin > > Evans > > Added more entries to the Readmes from John Scoles > > > > > > Cheers > > John Scoles > > > > -- > > New! Learn why & how to love your data with Pythian's new webinar series. > > Topics, details & register: http://www.pythian.com/webinars > > > >
Re: DBD::Oracle 11gr2 & ORA-38909
On Fri, 2010-06-04 at 16:42 -0400, John Scoles wrote:
> Had a quick look at it today give it a try agian but this time make
> sure you have autocommit off
>
>
> AutoCommit=>1
This turns it on, so you want it on or off?
>
> on the connection method
>
> cheers
>
> On Fri, May 21, 2010 at 11:20 AM, John Scoles
> wrote:
> Ok I guess it is back to square 1 on this.
>
> Unfortunetly no time to look at it today
>
> Will write up a small test script and see if my patch actually
> does anything
>
> You may hear from me in a few days
>
> Cheers
> John
>
>
>
>
> Scott T. Hildreth wrote:
> On Fri, 2010-05-21 at 09:23 +0100, Martin Evans wrote:
>
> John Scoles wrote:
>
> Ok I have patched up a solution I
> think will work across the board and
> you
> can find it here
>
>
> http://svn.perl.org/modules/dbd-oracle/branches/oci_batch
>
> here are the details
>
> ora_oci_batch
>
> For 11g users you may encounter an
> error while using the execute_array in
> that it does not
> return a full list of tuples. This
> seems to be a result in that a
> statement
> can only
> have 'LOG ERRORS' or 'SAVE
> EXCEPTIONS'set, By setting this flag
> to a value
> should stop this
> problem error.
>
> For convenience I have added support
> for a 'ORA_DBD_OCI_BATCH'
> environment variable that you can use
> at the OS level to set this
> value. It can also be set as an
> attribute on both the Connect and
> Prepare.
>
> Unfortunately I can't test it (do not
> have an 11g box yet) so It will stay
> in the above branch until it is tested
> hopefully by you Scott
>
> Cheers
> John Scoles
>
> --
> See Pythian's Alex Gorbachev,
> co-author of "Expert Oracle Practices"
> at NoCOUG Spring Conference May 20th.
> Details, interview & book chapter in
> the May NoCOUG Journal:
> http://bit.ly/alexnocoug
>
>
> I'm not sure why I seem to have ignored your
> mail but I just noticed it
> again - sorry for the delay.
>
> I checked out the branch you mentioned and
>
> export ORA_DBD_OCI_BATCH=1
>
> but 26exe_array still seems to fail for me:
>
>
> Sorry John, I meant to test earlier but its been a
> busy week.
>
> Fails for me as well.
>
> DB<7> x $dbh->{'ora_oci_batch'}
> 0 1
> DB<8> n
> main::(../tst_exec_ary.pl:13): my $sth =
> $dbh->prepare("Insert into TestArray Values(?, ?, ?)
> LOG ERRORS INTO ERR_TESTARRAY");
>
Re: DBD::Oracle 11gr2 & ORA-38909
On Fri, 2010-05-21 at 09:23 +0100, Martin Evans wrote:
> John Scoles wrote:
> > Ok I have patched up a solution I think will work across the board and you
> > can find it here
> >
> > http://svn.perl.org/modules/dbd-oracle/branches/oci_batch
> >
> > here are the details
> >
> > ora_oci_batch
> >
> > For 11g users you may encounter an error while using the execute_array in
> > that it does not
> > return a full list of tuples. This seems to be a result in that a statement
> > can only
> > have 'LOG ERRORS' or 'SAVE EXCEPTIONS'set, By setting this flag to a value
> > should stop this
> > problem error.
> >
> > For convenience I have added support for a 'ORA_DBD_OCI_BATCH'
> > environment variable that you can use at the OS level to set this
> > value. It can also be set as an attribute on both the Connect and Prepare.
> >
> > Unfortunately I can't test it (do not have an 11g box yet) so It will stay
> > in the above branch until it is tested hopefully by you Scott
> >
> > Cheers
> > John Scoles
> >
> > --
> > See Pythian's Alex Gorbachev, co-author of "Expert Oracle Practices" at
> > NoCOUG Spring Conference May 20th.
> > Details, interview & book chapter in the May NoCOUG Journal:
> > http://bit.ly/alexnocoug
> >
>
> I'm not sure why I seem to have ignored your mail but I just noticed it
> again - sorry for the delay.
>
> I checked out the branch you mentioned and
>
> export ORA_DBD_OCI_BATCH=1
>
> but 26exe_array still seems to fail for me:
Sorry John, I meant to test earlier but its been a busy week.
Fails for me as well.
DB<7> x $dbh->{'ora_oci_batch'}
0 1
DB<8> n
main::(../tst_exec_ary.pl:13): my $sth = $dbh->prepare("Insert into TestArray
Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY");
DB<8> n
main::(../tst_exec_ary.pl:15): $sth->bind_param_array(1, [ qw(One Uno Il oNe)
]);
DB<8> n
main::(../tst_exec_ary.pl:16): $sth->bind_param_array(2, [ 2, 22, 0, 222 ]);
DB<8> n
main::(../tst_exec_ary.pl:17): $sth->bind_param_array(3, [ qw(20070101
20080101 20090101 20060101) ]);
DB<8> n
main::(../tst_exec_ary.pl:21): $sth->execute_array({});
DB<8> n
DBD::Oracle::st execute_array failed: ORA-38909: DML Error logging is not
supported with BATCH ERROR mode (DBD ERROR: OCIStmtExecute) [for Statement
"Insert into TestArray Values(?, ?, ?) LOG ERRORS INTO ERR_TESTARRAY"] at
../tst_exec_ary.pl line 21.
at ../tst_exec_ary.pl line 21
>
> mar...@bragi:~/svn/dbd-oracle/branches/oci_batch$ prove -vb t/26exe_array.t
> t/26exe_array.t ..
> 1..17
> ok 1 - use DBI;
> ok 2 - The object isa DBI::db
> ok 3 - ... execute_array should return true
> ok 4 - ... we should have 10 tuple_status
> ok 5 - ... execute_array should return false
> ok 6 - ... we should have 10 tuple_status
> ok 7 - ... we should get text
> ok 8 - ... we should get -1
> ok 9 - ... we should get a warning
> ok 10 - ... execute_for_fetch should return true
> not ok 11 - ... we should have 19 tuple_status
>
> # Failed test '... we should have 19 tuple_status'
> # at t/26exe_array.t line 128.
> # got: 10
> # expected: 19
> ok 12 - ... execute_array should return flase
> ok 13 - ... we should have 10 tuple_status
> not ok 14 - ... we should have 48 rows
>
> # Failed test '... we should have 48 rows'
> # at t/26exe_array.t line 154.
> # got: 30
> # expected: 48
> ok 15 - ... execute_array should return true
> ok 16 - ... \#5 should be a warning
> ok 17 - ... we should have 10 tuple_status
> # Looks like you failed 2 tests of 17.
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 2/17 subtests
>
> Test Summary Report
> ---
> t/26exe_array.t (Wstat: 512 Tests: 17 Failed: 2)
> Failed tests: 11, 14
> Non-zero exit status: 2
> Files=1, Tests=17, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.05 cusr
> 0.01 csys = 0.09 CPU)
> Result: FAIL
>
> This was using oracle 11.1 server and 11.1 instant client.
>
> If I've not set the right thing let me know.
>
> Martin
Re: DBD::Oracle 11gr2 & ORA-38909
On Tue, 2010-04-06 at 09:51 +0100, Martin Evans wrote:
> I haven't seen a reply to this yet but I've been on holiday so might
> have missed it:
>
> Scott T. Hildreth wrote:
> > On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
> >> We have run into an issue with array processing in 11g. The developer
> >> was using execute_array and his sql statement had 'LOG ERRORS' in it.
> >> This did not error out until we switched to 11g. The issue is that only
> >> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
> >> logged and error report with Oracle and after several posts back and
> >> forth this is what they concluded,
> >>
> >> ==
> >> After investigation and discussion, development has closed the bug as
> >> 'Not a Bug' with the following reason:
> >>
> >> "this is an expected behavior in 11g and the user needs to specify
> >> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging', but NOT
> >> both together.
> >> The batch error mode, in the context of this bug, is basically referring
> >> to the SAVE EXCEPTIONS clause.
> >> It seems the code is trying to use both dml error logging and batch
> >> error handling for the same insert. In that case, this is not a bug.
> >>
> >> For INSERT, the data errors are logged in an error logging table (when
> >> the dml error logging feature is used) or returned in batch error
> >> handles (when using batch mode).
> >> Since the error messages are available to the user in either case, there
> >> is no need to both log the error in the error logging table and return
> >> the errors in batch error handles,
> >> and we require the user to specify one option or the other but not both
> >> in 11G.
> >>
> >> Both features exist in 10.x. For 11.x, users should change their
> >> application to avoid the error.
> >> ==
> >>
> >> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
> >> batch mode. I found in dbdimp.c that the oci_mode is being set to
> >> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was planning
> >> on setting it to OCI_BATCH_MODE and running a test to see if this will
> >> not error out. I report back when I have run the test, but I was
> >> wondering what would be the best way to give the user the ability to
> >> override the oci_mode.
> >
> > Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
> > attribute that will turn off the SAVE EXCEPTIONS. I'm looking for some
> > direction on how to add it to dbdimp.c. I haven't thought of a name yet,
> > but something like
> >
> > my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
> >
> > I assume I would have to add it to dbd_db_FETCH_attrib() and would I do
> > something like this in ora_st_execute_array(),
>
> Don't you mean dbd_st_FETCH_attrib as it is a statement level attribute
> not a connection one?
Yes.
> Anyway, I don't think it is required unless you
> really want to get it back out in a Perl script.
>
> I don't even think you need to add it to a statements
> private_attribute_info but then when I checked Oracle.pm it appears a
> load of prepare flags have been added. I might be wrong here but since
> there is no way to get ora_parse_lang etc (prepare attributes) I don't
> think they should be in private_attribute_info.
>
> perl -e 'use DBI;$h =
> DBI->connect("dbi:Oracle:host=xxx;sid=yyy","xxx","yyy"); $s =
> $h->prepare("select 1 from dual", {ora_parse_lang => 2}); print
> $s->{ora_parse_lang};'
>
> prints nothing as you'd expect as there is no way to get ora_parse_lang.
>
> > if (DBD_ATTRIB_TRUE(attr,"ora_oci_err_mode",16,svp))
> > DBD_ATTRIB_GET_IV( attr, "ora_oci_err_mode", 16, svp,
> > ora_oci_err_mode);
>
> I don't understand why you need it in ora_st_execute_array - the
> statement has already been parsed by then.
I don't either, I was looking at other attributes and how they are in
the code. That's why I asked for direction, :-)
> Do you mean dbd_st_prepare in
> oci8.c.
I think John is going to add this attribute, but I will give it a whirl
for the sake of learning more about DBD::Oracle.
Thanks.
>
> >
> > Thanks,
> > Scott
> >
> >
> >> An attribute in the prepare method?
> >>
> >> Thanks,
> >> Scott
> >
> >
>
> Martin
Re: DBD::Oracle 11gr2 & ORA-38909
On Wed, 2010-03-31 at 12:20 -0500, Scott T. Hildreth wrote:
> We have run into an issue with array processing in 11g. The developer
> was using execute_array and his sql statement had 'LOG ERRORS' in it.
> This did not error out until we switched to 11g. The issue is that only
> one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA
> logged and error report with Oracle and after several posts back and
> forth this is what they concluded,
>
> ==
> After investigation and discussion, development has closed the bug as
> 'Not a Bug' with the following reason:
>
> "this is an expected behavior in 11g and the user needs to specify
> either of 'SAVE EXCEPTIONS' clause or the 'DML error logging', but NOT
> both together.
> The batch error mode, in the context of this bug, is basically referring
> to the SAVE EXCEPTIONS clause.
> It seems the code is trying to use both dml error logging and batch
> error handling for the same insert. In that case, this is not a bug.
>
> For INSERT, the data errors are logged in an error logging table (when
> the dml error logging feature is used) or returned in batch error
> handles (when using batch mode).
> Since the error messages are available to the user in either case, there
> is no need to both log the error in the error logging table and return
> the errors in batch error handles,
> and we require the user to specify one option or the other but not both
> in 11G.
>
> Both features exist in 10.x. For 11.x, users should change their
> application to avoid the error.
> ==
>
> So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the
> batch mode. I found in dbdimp.c that the oci_mode is being set to
> OCI_BATCH_ERRORS in the ora_st_execute_array function. I was planning
> on setting it to OCI_BATCH_MODE and running a test to see if this will
> not error out. I report back when I have run the test, but I was
> wondering what would be the best way to give the user the ability to
> override the oci_mode.
Setting oci_mode to OCI_BATCH_MODE works. So I want to add a prepare
attribute that will turn off the SAVE EXCEPTIONS. I'm looking for some
direction on how to add it to dbdimp.c. I haven't thought of a name yet,
but something like
my $sth = $dbh->prepare($SQL,{ora_oci_err_mode => 0});
I assume I would have to add it to dbd_db_FETCH_attrib() and would I do
something like this in ora_st_execute_array(),
if (DBD_ATTRIB_TRUE(attr,"ora_oci_err_mode",16,svp))
DBD_ATTRIB_GET_IV( attr, "ora_oci_err_mode", 16, svp,
ora_oci_err_mode);
Thanks,
Scott
> An attribute in the prepare method?
>
> Thanks,
> Scott
Comments on this patch for dbms_output_get() ?
I created this patch because of this issue (which we have run into),
==
Parameter Description
lineReturns a single line of buffered information,
excluding a final newline character. You should
declare the actual for this parameter as VARCHAR2 (32767)
to avoid the risk of "ORA-06502: PL/SQL: numeric or value
error:
character string buffer too small".
status If the call completes successfully, then the status returns as
0.
If there are no more lines in the buffer, then the status is 1.
==
--- Oracle.pm.orig 2010-03-31 15:27:16.0 -0500
+++ Oracle.pm 2010-03-31 16:09:37.0 -0500
@@ -766,8 +766,11 @@
my $sth = $dbh->prepare_cached("begin
dbms_output.get_line(:l, :s); end;")
or return;
my ($line, $status, @lines);
+ my $version = join ".", @{ ora_server_version($dbh) }[0..1];
+ my $len = $version >= 10.2 ? 32767 : 400;
+
# line can be greater that 255 (e.g. 7 byte date is expanded on
output)
- $sth->bind_param_inout(':l', \$line, 400, { ora_type => 1 });
+ $sth->bind_param_inout(':l', \$line, $len, { ora_type => 1 });
$sth->bind_param_inout(':s', \$status, 20, { ora_type => 1 });
if (!wantarray) {
$sth->execute or return undef;
Thanks,
Scott
DBD::Oracle 11gr2 & ORA-38909
We have run into an issue with array processing in 11g. The developer was using execute_array and his sql statement had 'LOG ERRORS' in it. This did not error out until we switched to 11g. The issue is that only one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA logged and error report with Oracle and after several posts back and forth this is what they concluded, == After investigation and discussion, development has closed the bug as 'Not a Bug' with the following reason: "this is an expected behavior in 11g and the user needs to specify either of 'SAVE EXCEPTIONS' clause or the 'DML error logging', but NOT both together. The batch error mode, in the context of this bug, is basically referring to the SAVE EXCEPTIONS clause. It seems the code is trying to use both dml error logging and batch error handling for the same insert. In that case, this is not a bug. For INSERT, the data errors are logged in an error logging table (when the dml error logging feature is used) or returned in batch error handles (when using batch mode). Since the error messages are available to the user in either case, there is no need to both log the error in the error logging table and return the errors in batch error handles, and we require the user to specify one option or the other but not both in 11G. Both features exist in 10.x. For 11.x, users should change their application to avoid the error. == So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the batch mode. I found in dbdimp.c that the oci_mode is being set to OCI_BATCH_ERRORS in the ora_st_execute_array function. I was planning on setting it to OCI_BATCH_MODE and running a test to see if this will not error out. I report back when I have run the test, but I was wondering what would be the best way to give the user the ability to override the oci_mode. An attribute in the prepare method? Thanks, Scott
Re: DBD::Oracle 1.20 - t/80ora_charset.t fails 4 tests
On Wed, 2008-03-12 at 14:55 -0400, [EMAIL PROTECTED] wrote:
> Well I have spend some time with this today and here is what I found out.
>
> no errors with present code on 6 installations but you patch causes a
> semi- error (incomplete tests) on 4 systems. So me thinks there just
> might be some sort of oracle/Debi/DB bub or misconfiguration in you
> system.
Could very well be, I am getting a crash course on utf8. :-)
When I get more time, I will figure out why they fail on our DB's
and report back my findings.
Thanks.
>
> Most likely a harmless environment variable that is set or a patch or lack
> thereof on Oracle that might cause it.
>
> I will keep this patch for now in reserve if other people start
> complaining about this test
>
> cheers
> John Scoles
> > On Wed, 2008-03-05 at 17:39 -0600, Scott T. Hildreth wrote:
> >> On Thu, 2008-02-14 at 10:03 -0600, Scott T. Hildreth wrote:
> >> > not ok 9 - match char
> >> > # Failed test 'match char'
> >> > # at t/80ora_charset.t line 83.
> >> > # got: '?'
> >> > # expected: ' '
> >> > /\
> >> > ||
> >> > a char I can't print, looks like a degree symbol :-)
> >> >
> >> > not ok 10 - match char
> >> > # Failed test 'match char'
> >> > # at t/80ora_charset.t line 84.
> >> > # got: '?'
> >> >
> >>
> >> This patch fixes test 9 & 10,
> >>
> >> --- 80ora_charset.t.orig2008-03-05 17:34:58.0 -0600
> >> +++ 80ora_charset.t 2008-03-05 17:34:47.0 -0600
> >> @@ -74,14 +74,14 @@
> >> if ($is_utf8) {
> >> ok(Encode::is_utf8($ch));
> >> ok(Encode::is_utf8($nch));
> >> +
> >> +is($ch, "\xb0", "match char");
> >> +is($nch, "\xb0", "match char");
> >> }
> >> else {
> >> ok(!Encode::is_utf8($ch));
> >> ok(!Encode::is_utf8($nch));
> >> }
> >> -
> >> -is($ch, "\xb0", "match char");
> >> -is($nch, "\xb0", "match char");
> >> }
> >>
> >>
> >>
> >> > ok 11
> >> > ok 12
> >> > not ok 13 - match char
> >> > # Failed test 'match char'
> >> > # at t/80ora_charset.t line 83.
> >> > # got: '?'
> >> >
> >> > not ok 14 - match char
> >> > # Failed test 'match char'
> >> > # at t/80ora_charset.t line 84.
> >> > # got: '?'
> >>
> >>
> >> These test assume that the database can use utf8, as far as I know the
> >> database has to be created with a certain character set, i.e. utf8 for
> >> it to handle utf8 data.
> >
> > Okay not true, I just asked a dba.
> >
> >>
> >> >
> >> > ...I install the module anyways, since only 4 tests fail and
> >> 80ora_charset is a
> >> >new test in 1.20. I would like to know why this fails.
> >> >
> >> >
> >> > Thanks,
> >> > STH
> >
>
>
Re: DBD::Oracle 1.20 - t/80ora_charset.t fails 4 tests
On Wed, 2008-03-05 at 17:39 -0600, Scott T. Hildreth wrote:
> On Thu, 2008-02-14 at 10:03 -0600, Scott T. Hildreth wrote:
> > not ok 9 - match char
> > # Failed test 'match char'
> > # at t/80ora_charset.t line 83.
> > # got: '?'
> > # expected: ' '
> > /\
> > ||
> > a char I can't print, looks like a degree symbol :-)
> >
> > not ok 10 - match char
> > # Failed test 'match char'
> > # at t/80ora_charset.t line 84.
> > # got: '?'
> >
>
> This patch fixes test 9 & 10,
>
> --- 80ora_charset.t.orig2008-03-05 17:34:58.0 -0600
> +++ 80ora_charset.t 2008-03-05 17:34:47.0 -0600
> @@ -74,14 +74,14 @@
> if ($is_utf8) {
> ok(Encode::is_utf8($ch));
> ok(Encode::is_utf8($nch));
> +
> +is($ch, "\xb0", "match char");
> +is($nch, "\xb0", "match char");
> }
> else {
> ok(!Encode::is_utf8($ch));
> ok(!Encode::is_utf8($nch));
> }
> -
> -is($ch, "\xb0", "match char");
> -is($nch, "\xb0", "match char");
> }
>
>
>
> > ok 11
> > ok 12
> > not ok 13 - match char
> > # Failed test 'match char'
> > # at t/80ora_charset.t line 83.
> > # got: '?'
> >
> > not ok 14 - match char
> > # Failed test 'match char'
> > # at t/80ora_charset.t line 84.
> > # got: '?'
>
>
> These test assume that the database can use utf8, as far as I know the
> database has to be created with a certain character set, i.e. utf8 for
> it to handle utf8 data.
Okay not true, I just asked a dba.
>
> >
> > ...I install the module anyways, since only 4 tests fail and 80ora_charset
> > is a
> >new test in 1.20. I would like to know why this fails.
> >
> >
> > Thanks,
> > STH
Re: DBD::Oracle 1.20 - t/80ora_charset.t fails 4 tests
On Thu, 2008-02-14 at 10:03 -0600, Scott T. Hildreth wrote:
> not ok 9 - match char
> # Failed test 'match char'
> # at t/80ora_charset.t line 83.
> # got: '?'
> # expected: ' '
> /\
> ||
> a char I can't print, looks like a degree symbol :-)
>
> not ok 10 - match char
> # Failed test 'match char'
> # at t/80ora_charset.t line 84.
> # got: '?'
>
This patch fixes test 9 & 10,
--- 80ora_charset.t.orig2008-03-05 17:34:58.0 -0600
+++ 80ora_charset.t 2008-03-05 17:34:47.0 -0600
@@ -74,14 +74,14 @@
if ($is_utf8) {
ok(Encode::is_utf8($ch));
ok(Encode::is_utf8($nch));
+
+is($ch, "\xb0", "match char");
+is($nch, "\xb0", "match char");
}
else {
ok(!Encode::is_utf8($ch));
ok(!Encode::is_utf8($nch));
}
-
-is($ch, "\xb0", "match char");
-is($nch, "\xb0", "match char");
}
> ok 11
> ok 12
> not ok 13 - match char
> # Failed test 'match char'
> # at t/80ora_charset.t line 83.
> # got: '?'
>
> not ok 14 - match char
> # Failed test 'match char'
> # at t/80ora_charset.t line 84.
> # got: '?'
These test assume that the database can use utf8, as far as I know the
database has to be created with a certain character set, i.e. utf8 for
it to handle utf8 data.
>
> ...I install the module anyways, since only 4 tests fail and 80ora_charset is
> a
>new test in 1.20. I would like to know why this fails.
>
>
> Thanks,
> STH
DBD::Oracle - execute_array core dumps intermittently
I am not sure how to describe this, my co-worker will run his process and get a core dump (I pasted the back trace below) and then run the process again with no core dumps. Sometimes it will core dump several times in a row and then the next run it finishes fine. I ran the process with DBI_TRACE=9 and this is what shows up at the end of the log, 1 -> execute_for_fetch for DBD::Oracle::st (DBI::st=HASH(0xN)~INNER CODE(0xN) undef) ora_st_execute_array UPDATE count=10 (ARRAY(0xN) undef undef)... OCIBindByName(112df38,1132188,10a9138,":p1",placeh_len=3,value_p=0,value_sz=-1517274788,dty=1,indp=0,alenp=0,rcodep=0,maxarr_len=0,curelep=0 (*=0),mode=2)=ERROR OCIErrorGet(10a9138,1,"",7fff058d684c,"ORA-02005: implicit (-1) length not valid for this bind or define datatype ",1024,2)=SUCCESS OCIErrorGet after OCIBindByName (er1:ok): -1, 2005: ORA-02005: implicit (-1) length not valid for this bind or define datatype OCIErrorGet(10a9138,2,"",7fff058d684c,"ORA-02005: implicit (-1) length not valid for this bind or define datatype ",1024,2)=NO_DATA At first I thought it was a 32bit library with a 64bit Perl problem, but Oracle.so & Perl are both linked with the correct 64 bit libs. The Oracle client is 10.2.0.3 and DBI versions are, Perl: 5.008008(x86_64-linux) OS : linux (2.6.20.19) DBI : 1.602 DBD::mysql : 4.005 DBD::Sponge : 12.010002 DBD::SQLite : 1.13 DBD::Proxy : 0.2004 DBD::Oracle : 1.20 DBD::Multiplex : 2.04 DBD::Gofer : 0.010103 DBD::File : 0.35 DBD::ExampleP : 12.010007 DBD::DBM: 0.03 I am going to try to isolate a small test case, but right now I wanted to post what I have found so far. Thanks, STH ## Back Trace # (gdb) bt #0 0x2b66ec7d9b95 in raise () from /lib64/libc.so.6 #1 0x2b66ec7daf90 in abort () from /lib64/libc.so.6 #2 0x2b66ec81035b in __libc_message () from /lib64/libc.so.6 #3 0x2b66ec81534e in malloc_printerr () from /lib64/libc.so.6 #4 0x2b66ec81695c in free () from /lib64/libc.so.6 #5 0x2b66ef0ac102 in ora_st_execute_array () from /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so #6 0x2b66ef0a62bf in XS_DBD__Oracle__st_ora_execute_array () from /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so #7 0x0046bc47 in Perl_pp_entersub () #8 0x0046a29e in Perl_runops_standard () #9 0x0041e82d in Perl_call_sv () #10 0x2b66ec9ee038 in XS_DBI_dispatch () from /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so #11 0x0046bc47 in Perl_pp_entersub () #12 0x0046a29e in Perl_runops_standard () #13 0x0041e82d in Perl_call_sv () #14 0x2b66ec9ee038 in XS_DBI_dispatch () from /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so #15 0x0046bc47 in Perl_pp_entersub () #16 0x0046a29e in Perl_runops_standard () #17 0x0041f1d1 in perl_run () #18 0x0041ba2c in main () *** glibc detected *** /usr/local/bin/perl: double free or corruption (!prev): 0x01163e10 *** === Backtrace: = /lib64/libc.so.6[0x2ad39584e34e] /lib64/libc.so.6(__libc_free+0x6c)[0x2ad39584f95c] /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so(ora_st_execute_array+0xfa4)[0x2ad3980e6e94] /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so(XS_DBD__Oracle__st_ora_execute_array+0xef)[0x2ad3980e0f9f] /usr/local/bin/perl(Perl_pp_entersub+0x6b7)[0x46bae7] /usr/local/bin/perl(Perl_runops_standard+0xe)[0x46a13e] /usr/local/bin/perl(Perl_call_sv+0x49d)[0x41e80d] /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so(XS_DBI_dispatch+0x7a8)[0x2ad395a27068] /usr/local/bin/perl(Perl_pp_entersub+0x6b7)[0x46bae7] /usr/local/bin/perl(Perl_runops_standard+0xe)[0x46a13e] /usr/local/bin/perl(Perl_call_sv+0x49d)[0x41e80d] /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so(XS_DBI_dispatch+0x7a8)[0x2ad395a27068] /usr/local/bin/perl(Perl_pp_entersub+0x6b7)[0x46bae7] /usr/local/bin/perl(Perl_runops_standard+0xe)[0x46a13e] /usr/local/bin/perl(perl_run+0x2c1)[0x41f1b1] /usr/local/bin/perl(main+0xac)[0x41ba2c] /lib64/libc.so.6(__libc_start_main+0xf4)[0x2ad395800154] /usr/local/bin/perl[0x41b8e9] === Memory map: 0040-004fc000 r-xp 08:02 427095 /usr/local/perl-5.8.8/bin/perl 005fb000-00601000 rw-p 000fb000 08:02 427095 /usr/local/perl-5.8.8/bin/perl 00601000-01183000 rw-p 00601000 00:00 0 [heap] 2ad39511b000-2ad395136000 r-xp 08:0
DBD::Oracle 1.20 - t/80ora_charset.t fails 4 tests
not ok 9 - match char # Failed test 'match char' # at t/80ora_charset.t line 83. # got: '?' # expected: ' ' /\ || a char I can't print, looks like a degree symbol :-) not ok 10 - match char # Failed test 'match char' # at t/80ora_charset.t line 84. # got: '?' ok 11 ok 12 not ok 13 - match char # Failed test 'match char' # at t/80ora_charset.t line 83. # got: '?' not ok 14 - match char # Failed test 'match char' # at t/80ora_charset.t line 84. # got: '?' ...I install the module anyways, since only 4 tests fail and 80ora_charset is a new test in 1.20. I would like to know why this fails. Thanks, STH
Re: DBD::Proxy - getting unitialized error for $numFields
On Wed, 2007-04-25 at 22:34 +0100, Tim Bunce wrote:
> On Wed, Apr 25, 2007 at 02:45:47PM -0500, Scott T. Hildreth wrote:
> > On Wed, 2007-03-28 at 21:26 +0100, Tim Bunce wrote:
> > > On Wed, Mar 28, 2007 at 01:54:51PM -0500, Scott T. Hildreth wrote:
> > > > I should also mention that this is a $dbh->do( "an insert statement").
> > > > A quick look at DBI::ProxyServer, shows that the NUMFIELDS indicates
> > > > a select, therefore in this case 'undef' would be returned for an
> > > > insert. Should it be initialized to '0', to quite warnings on
> > > > non-selects?
> > >
> > > That would work. As would:
> > >
> > > $sth->SUPER::STORE('NUM_OF_FIELDS' => $numFields) if $numFields;
> > >
> > > Doing both would make life easier for people who can't upgrade client
> > > and server at the same time.
> > >
> > > But I wonder if this is really the issue. Why hasn't anyone reported
> > > undef warnings on insert statement before? Would be good to add a test
> > > case to t/80proxy.t that reproduces the problem before you fix it.
> >
> > Upgrading DBI to 1.54 (where the proxy server runs) has seemed to fix
> > this issue. Do you think tests should still be added to t/80proxy.t?
>
> Or perhaps a doc patch to stress the risks of client and server getting
> out of sync.
What I have seen is that a newer client connecting to the older
server is trouble. I have not had an issue with the older clients
connecting to the new server. Which make sense, since I was having
problems with the newer clients expecting functionality that was
present in the older server.
>
> Or perhaps identify the precise way the version skew affects the client
> and server and have them report a useful error when they detect it.
Okay, I would say that the Proxy Server should always be a version
that is >= to the newest client.
>
> Tim.
>
> > > Tim.
> > >
> > > p.s. Any volunteers to work on a daemon wrapper for DBI::Gofer::Execute
> > > so it can be used as a replacement for the current DBI proxy server.
> > > (DBD::Gofer is potentially significantly faster than DBD::Proxy.)
> > > If so please start a new thread and I'll give a brain dump...
> > >
> > >
> > > > On Wed, 2007-03-28 at 13:35 -0500, Scott T. Hildreth wrote:
> > > > > So I tracked this down further, DBD::Proxy gets an array returned
> > > > > from the client calling
> > > > > the server. Which is ultimately put into @outData, and
> > > > > $outData[0]($numFields) is 'undef'
> > > > > and produces this warning,
> > > > >
> > > > > Use of uninitialized value in subroutine entry at
> > > > >/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm
> > > > > line 566.
> > > > >
> > > > >
> > > > > Here is where @outData is spliced,
> > > > >
> > > > > DBD::Proxy::st::execute(/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm:559):
> > > > > 559:my ($numFields, $numParams, $names, $types) =
> > > > > splice(@outData, 0, 4);
> > > > >
> > > > > I guess my next step is to run the Proxy server in debug mode and
> > > > > figure out why numFields
> > > > > is not filled in. I was hoping someone might know what is going on
> > > > > before I do that.
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > >
> > > > > On Thu, 2007-01-18 at 15:37 -0600, Scott T. Hildreth wrote:
> > > > > > ###
> > > > > >
> > > > > > Perl: 5.008008(i386-freebsd)
> > > > > > OS : freebsd (6.1-stable)
> > > > > > DBI : 1.53
> > > > > > DBD::mysql : 3.0004
> > > > > > DBD::Sponge : 11.10
> > > > > > DBD::SQLite : 1.12
> > > > > > DBD::Proxy : 0.2004
> > > > > > DBD::Multiplex : 2.00
> > > > > > DBD::File : 0.35
> > > > > > DBD::ExampleP : 11.12
> > > > > > DBD::DBM: 0.03
> > > > > > DBD::CSV: 0.22
> > > > >
Re: DBD::Proxy - getting unitialized error for $numFields
On Wed, 2007-03-28 at 21:26 +0100, Tim Bunce wrote:
> On Wed, Mar 28, 2007 at 01:54:51PM -0500, Scott T. Hildreth wrote:
> > I should also mention that this is a $dbh->do( "an insert statement").
> > A quick look at DBI::ProxyServer, shows that the NUMFIELDS indicates
> > a select, therefore in this case 'undef' would be returned for an
> > insert. Should it be initialized to '0', to quite warnings on
> > non-selects?
>
> That would work. As would:
>
> $sth->SUPER::STORE('NUM_OF_FIELDS' => $numFields) if $numFields;
>
> Doing both would make life easier for people who can't upgrade client
> and server at the same time.
>
> But I wonder if this is really the issue. Why hasn't anyone reported
> undef warnings on insert statement before? Would be good to add a test
> case to t/80proxy.t that reproduces the problem before you fix it.
Upgrading DBI to 1.54 (where the proxy server runs) has seemed to fix
this issue. Do you think tests should still be added to t/80proxy.t?
>
> Tim.
>
> p.s. Any volunteers to work on a daemon wrapper for DBI::Gofer::Execute
> so it can be used as a replacement for the current DBI proxy server.
> (DBD::Gofer is potentially significantly faster than DBD::Proxy.)
> If so please start a new thread and I'll give a brain dump...
>
>
> > On Wed, 2007-03-28 at 13:35 -0500, Scott T. Hildreth wrote:
> > > So I tracked this down further, DBD::Proxy gets an array returned from
> > > the client calling
> > > the server. Which is ultimately put into @outData, and
> > > $outData[0]($numFields) is 'undef'
> > > and produces this warning,
> > >
> > > Use of uninitialized value in subroutine entry at
> > >/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm line
> > > 566.
> > >
> > >
> > > Here is where @outData is spliced,
> > >
> > > DBD::Proxy::st::execute(/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm:559):
> > > 559:my ($numFields, $numParams, $names, $types) =
> > > splice(@outData, 0, 4);
> > >
> > > I guess my next step is to run the Proxy server in debug mode and figure
> > > out why numFields
> > > is not filled in. I was hoping someone might know what is going on
> > > before I do that.
> > >
> > >
> > > Thanks
> > >
> > >
> > > On Thu, 2007-01-18 at 15:37 -0600, Scott T. Hildreth wrote:
> > > > ###
> > > >
> > > > Perl: 5.008008(i386-freebsd)
> > > > OS : freebsd (6.1-stable)
> > > > DBI : 1.53
> > > > DBD::mysql : 3.0004
> > > > DBD::Sponge : 11.10
> > > > DBD::SQLite : 1.12
> > > > DBD::Proxy : 0.2004
> > > > DBD::Multiplex : 2.00
> > > > DBD::File : 0.35
> > > > DBD::ExampleP : 11.12
> > > > DBD::DBM: 0.03
> > > > DBD::CSV: 0.22
> > > > DBD::AnyData: 0.08
> > > >
> > > > ##
> > > >
> > > > For every database call, do, execute, ...etc I get the warning,
> > > >
> > > > Use of uninitialized value in subroutine entry
> > > > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm
> > > > line 567.
> > > >
> > > > Which is " 'NUM_OF_FIELDS' => $numFields, ".
> > > >
> > > > I don't think this matters but, the proxy is connecting to DBD::Oracle,
> > > > the connect is in another module that is inherited by the module I am
> > > > testing.
> > > >
> > > > I am also getting disconnect errors on the DESTROY,
> > > >
> > > > (in cleanup) DBD::Proxy::db disconnect failed: Can't call method
> > > > "disconnect" on an undefined value
> > > > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm
> > > > line 311 during global destruction.
> > > >
> > > > (in cleanup) DBD::Proxy::db DESTROY failed: Can't call method
> > > > "disconnect" on an undefined value
> > > > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm
> > > > line 311 during global destruction.
> > > >
> > > >
> > > > My eyes are glazing over, so any help would be appreciated. I'm sure it
> > > > is something simple I am missing here...
> > > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > --
> > Scott T. Hildreth <[EMAIL PROTECTED]>
--
Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBI-1.54 proxy connect errors
On Mon, 2007-04-23 at 16:41 -0500, Scott T. Hildreth wrote:
> On Mon, 2007-04-23 at 21:23 +0100, Tim Bunce wrote:
> > On Mon, Apr 23, 2007 at 12:38:36PM -0500, Scott T. Hildreth wrote:
> > > On Mon, 2007-04-23 at 12:34 -0500, Scott T. Hildreth wrote:
> > > > I can confirm this,
> > > >
> > > > http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/aa1a09e3ac0aa54f/6d96262964f376aa?lnk=st&q=Not+permitted+for+method+connected+of+class+DBI%3A%3AProxyServer%3A%3Adb+&rnum=1#6d96262964f376aa
> > > >
> > > >
> > > > ...I am not using debian, just saw the same problem. At first I thought
> > > > it was a problem with 64bit Perl client connecting to 32bit Perl Server,
> > > > but downgrading to DBI-1.53 on the 64bit server fixes the Proxy problem.
> > > > I will try DBI-1.55rc1 and report back.
> > >
> > > DBI-1.55rc1 fails as well.
> >
> > Looks like the message is from this code:
> >
> > sub CallMethod ($$$@) {
> > my($self, $handle, $method, @args) = @_;
> > ...
> > if ($self->{'methods'}) {
> > my $class = $self->{'methods'}->{$ref};
> > if (!$class || !$class->{$method}) {
> > die "Not permitted for method $method of class $ref";
> > }
> > }
> > ...
> > }
> >
> > In which case this is due to the server side running an old version of DBI.
>
> Older, 1.50. I will update the server to 1.54, will older clients be
> able connect or will I have to update all the DBIs?
>
For archive completeness,
updating the DBI where the proxy server runs fixed it (as expected)
and the older DBIs are able to communicate with the new proxy server.
> >
> > Tim.
--
Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBI-1.54 proxy connect errors
On Mon, 2007-04-23 at 21:23 +0100, Tim Bunce wrote:
> On Mon, Apr 23, 2007 at 12:38:36PM -0500, Scott T. Hildreth wrote:
> > On Mon, 2007-04-23 at 12:34 -0500, Scott T. Hildreth wrote:
> > > I can confirm this,
> > >
> > > http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/aa1a09e3ac0aa54f/6d96262964f376aa?lnk=st&q=Not+permitted+for+method+connected+of+class+DBI%3A%3AProxyServer%3A%3Adb+&rnum=1#6d96262964f376aa
> > >
> > >
> > > ...I am not using debian, just saw the same problem. At first I thought
> > > it was a problem with 64bit Perl client connecting to 32bit Perl Server,
> > > but downgrading to DBI-1.53 on the 64bit server fixes the Proxy problem.
> > > I will try DBI-1.55rc1 and report back.
> >
> > DBI-1.55rc1 fails as well.
>
> Looks like the message is from this code:
>
> sub CallMethod ($$$@) {
> my($self, $handle, $method, @args) = @_;
> ...
> if ($self->{'methods'}) {
> my $class = $self->{'methods'}->{$ref};
> if (!$class || !$class->{$method}) {
> die "Not permitted for method $method of class $ref";
> }
> }
> ...
> }
>
> In which case this is due to the server side running an old version of DBI.
Older, 1.50. I will update the server to 1.54, will older clients be
able connect or will I have to update all the DBIs?
>
> Tim.
--
Scott T. Hildreth <[EMAIL PROTECTED]>
DBI-1.54 proxy connect errors
I can confirm this, http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/aa1a09e3ac0aa54f/6d96262964f376aa?lnk=st&q=Not+permitted+for+method+connected+of+class+DBI%3A%3AProxyServer%3A%3Adb+&rnum=1#6d96262964f376aa ...I am not using debian, just saw the same problem. At first I thought it was a problem with 64bit Perl client connecting to 32bit Perl Server, but downgrading to DBI-1.53 on the 64bit server fixes the Proxy problem. I will try DBI-1.55rc1 and report back. -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBI-1.54 proxy connect errors
On Mon, 2007-04-23 at 12:34 -0500, Scott T. Hildreth wrote: > I can confirm this, > > http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/aa1a09e3ac0aa54f/6d96262964f376aa?lnk=st&q=Not+permitted+for+method+connected+of+class+DBI%3A%3AProxyServer%3A%3Adb+&rnum=1#6d96262964f376aa > > > ...I am not using debian, just saw the same problem. At first I thought > it was a problem with 64bit Perl client connecting to 32bit Perl Server, > but downgrading to DBI-1.53 on the 64bit server fixes the Proxy problem. > I will try DBI-1.55rc1 and report back. > DBI-1.55rc1 fails as well. -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::mysql 4.004 Released!
On Wed, 2007-04-11 at 09:59 -0500, Scott T. Hildreth wrote: > I had to add this to dbdimp.c, mysql_warning_count() is not implemented > before 4.1, > > #if MYSQL_VERSION_ID >= SQL_STATE_VERSION > imp_sth->warning_count = mysql_warning_count(&imp_dbh->mysql); > #else > imp_sth->warning_count = 0; > #endif > > Also :-), These tests fail since the older clients don't support the features, Failed Test Stat Wstat Total Fail List of Failed --- t/80procs.t 255 6528032 44 11-32 t/multi_statement.t 255 65280 78 4-7 t/prepare_noerror.t31 2 t/utf8.t 163 6 11-12 The tests need to check the version of the client as well as the server. I'm not sure how you would do that. > I don't know if setting the count to 0 is what I should do here. > > > On Wed, 2007-03-28 at 13:01 -0500, Scott T. Hildreth wrote: > > Feel free to send it to me before release, we will have the old client > > on that server until we upgrade it. Which will be awhile. > > > > > > On Tue, 2007-03-27 at 22:18 -0400, Patrick Galbraith wrote: > > > Scott, > > > > > > Thanks! I need to somehow find a 4.0 binary for OS X to find these pesky > > > things. > > > > > > regards, > > > > > > Patrick > > > > > > Scott T. Hildreth wrote: > > > > > > >Pat, > > > > > > > > The #ifdef's still need to be removed in the calls below. > > > > > > > >Thanks. > > > > > > > >dbdimp.c: In function `mysql_st_fetch': > > > >dbdimp.c:3429: error: too few arguments to function `mysql_dr_error' > > > >dbdimp.c:3593: error: too few arguments to function `mysql_dr_error' > > > >dbdimp.c: In function `mysql_st_FETCH_internal': > > > >dbdimp.c:3931: error: too few arguments to function `mysql_dr_error' > > > >dbdimp.c:3945: error: too few arguments to function `mysql_dr_error' > > > >dbdimp.c: In function `mysql_bind_ph': > > > >dbdimp.c:4264: error: too few arguments to function `mysql_dr_error' > > > >dbdimp.c:4291: error: too few arguments to function `mysql_dr_error' > > > >dbdimp.c:4303: error: too few arguments to function `mysql_dr_error' > > > >dbdimp.c: In function `mysql_db_reconnect': > > > >dbdimp.c:4465: error: too few arguments to function `mysql_dr_error' > > > > > > > >On Sun, 2007-03-25 at 10:40 -0400, Patrick Galbraith wrote: > > > > > > > > > > > >>Dear DBD::mysql users and developers, > > > >> > > > >>I'm pleased to announce the release of DBD::mysql 4.004! This release > > > >>contains various fixes, per Changelog: > > > >> > > > >>* Work around a bug in old 3.23 servers by specifying NOT NULL for > > > >>fields used > > > >> as a primary key in tests. (Bug #20325, reported by Julian Ladisch) > > > >>* Add support for mysql_warning_count statement handle attribute. (Bug > > > >>#25457, > > > >> patch from Philip Stoev) > > > >>* Add support for mysql_multi_statements connection option. (RT #12322, > > > >>based > > > >> on patch from Doug Morris) > > > >>* Had to bump to 4.003 do to print statement in mysql.pm that made it > > > >> into the dist. Even though you can delete a file on CPAN, you cannot > > > >> re-upload it if it's the same name. Mea Culpa. > > > >>* UTF8-Flag not set with flag mysql_enable_utf8 and column collation > > > >>utf8_bin patch, > > > >> Joost Diepenmaat, (RT #24738) > > > >>* Fixed do_error definition (Scott Hildreth, Tim Bunce) > > > >>* Conversion of test suite to Test::More > > > >> > > > >>This release was possible due to the efforts of: > > > >> > > > >>Jim Winstead > > > >>Tim Bunce > > > >>Scott Hildreth > > > >>Joost Diepenmaat > > > >>Dave Rolsky > > > >>Philip Stoev > > > >>Doug Morris > > > >>Julian Ladisch > > > >> > > > >>And the rest of the community, and anyone else I forgot to mention! > > > >> > > > >>Thank you for using DBD::mysql and MySQL! > > > >> > > > >>The files: > > > >> > > > >> file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.004.tar.gz > > > >> size: 122247 bytes > > > >> md5: ba89b04b003dec320c893f2553a98ede > > > >> > > > >> > > > >>Also: > > > >> > > > >>http://search.cpan.org/~capttofu/DBD-mysql-4.004/ > > > >> > > > >>Kind regards, > > > >> > > > >>Patrick Galbraith > > > >> > > > >> > > > >> > > > >> > > > > > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::mysql 4.004 Released!
I had to add this to dbdimp.c, mysql_warning_count() is not implemented before 4.1, #if MYSQL_VERSION_ID >= SQL_STATE_VERSION imp_sth->warning_count = mysql_warning_count(&imp_dbh->mysql); #else imp_sth->warning_count = 0; #endif I don't know if setting the count to 0 is what I should do here. On Wed, 2007-03-28 at 13:01 -0500, Scott T. Hildreth wrote: > Feel free to send it to me before release, we will have the old client > on that server until we upgrade it. Which will be awhile. > > > On Tue, 2007-03-27 at 22:18 -0400, Patrick Galbraith wrote: > > Scott, > > > > Thanks! I need to somehow find a 4.0 binary for OS X to find these pesky > > things. > > > > regards, > > > > Patrick > > > > Scott T. Hildreth wrote: > > > > >Pat, > > > > > > The #ifdef's still need to be removed in the calls below. > > > > > >Thanks. > > > > > >dbdimp.c: In function `mysql_st_fetch': > > >dbdimp.c:3429: error: too few arguments to function `mysql_dr_error' > > >dbdimp.c:3593: error: too few arguments to function `mysql_dr_error' > > >dbdimp.c: In function `mysql_st_FETCH_internal': > > >dbdimp.c:3931: error: too few arguments to function `mysql_dr_error' > > >dbdimp.c:3945: error: too few arguments to function `mysql_dr_error' > > >dbdimp.c: In function `mysql_bind_ph': > > >dbdimp.c:4264: error: too few arguments to function `mysql_dr_error' > > >dbdimp.c:4291: error: too few arguments to function `mysql_dr_error' > > >dbdimp.c:4303: error: too few arguments to function `mysql_dr_error' > > >dbdimp.c: In function `mysql_db_reconnect': > > >dbdimp.c:4465: error: too few arguments to function `mysql_dr_error' > > > > > >On Sun, 2007-03-25 at 10:40 -0400, Patrick Galbraith wrote: > > > > > > > > >>Dear DBD::mysql users and developers, > > >> > > >>I'm pleased to announce the release of DBD::mysql 4.004! This release > > >>contains various fixes, per Changelog: > > >> > > >>* Work around a bug in old 3.23 servers by specifying NOT NULL for > > >>fields used > > >> as a primary key in tests. (Bug #20325, reported by Julian Ladisch) > > >>* Add support for mysql_warning_count statement handle attribute. (Bug > > >>#25457, > > >> patch from Philip Stoev) > > >>* Add support for mysql_multi_statements connection option. (RT #12322, > > >>based > > >> on patch from Doug Morris) > > >>* Had to bump to 4.003 do to print statement in mysql.pm that made it > > >> into the dist. Even though you can delete a file on CPAN, you cannot > > >> re-upload it if it's the same name. Mea Culpa. > > >>* UTF8-Flag not set with flag mysql_enable_utf8 and column collation > > >>utf8_bin patch, > > >> Joost Diepenmaat, (RT #24738) > > >>* Fixed do_error definition (Scott Hildreth, Tim Bunce) > > >>* Conversion of test suite to Test::More > > >> > > >>This release was possible due to the efforts of: > > >> > > >>Jim Winstead > > >>Tim Bunce > > >>Scott Hildreth > > >>Joost Diepenmaat > > >>Dave Rolsky > > >>Philip Stoev > > >>Doug Morris > > >>Julian Ladisch > > >> > > >>And the rest of the community, and anyone else I forgot to mention! > > >> > > >>Thank you for using DBD::mysql and MySQL! > > >> > > >>The files: > > >> > > >> file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.004.tar.gz > > >> size: 122247 bytes > > >> md5: ba89b04b003dec320c893f2553a98ede > > >> > > >> > > >>Also: > > >> > > >>http://search.cpan.org/~capttofu/DBD-mysql-4.004/ > > >> > > >>Kind regards, > > >> > > >>Patrick Galbraith > > >> > > >> > > >> > > >> > > > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::Proxy - getting unitialized error for $numFields
On Wed, 2007-03-28 at 21:26 +0100, Tim Bunce wrote:
> On Wed, Mar 28, 2007 at 01:54:51PM -0500, Scott T. Hildreth wrote:
> > I should also mention that this is a $dbh->do( "an insert statement").
> > A quick look at DBI::ProxyServer, shows that the NUMFIELDS indicates
> > a select, therefore in this case 'undef' would be returned for an
> > insert. Should it be initialized to '0', to quite warnings on
> > non-selects?
>
> That would work. As would:
>
> $sth->SUPER::STORE('NUM_OF_FIELDS' => $numFields) if $numFields;
>
> Doing both would make life easier for people who can't upgrade client
> and server at the same time.
Do think if I updated my server this would go away?
The proxy server is,
Perl: 5.008008(i686-linux)
OS : linux (2.6.14.6)
DBI : 1.50
DBD::mysql : 3.0002
DBD::Sponge : 11.10
DBD::SQLite : 1.11
DBD::Proxy : 0.2004
DBD::Oracle : 1.19
DBD::Multiplex : 1.98
DBD::File : 0.33
DBD::ExampleP : 11.12
DBD::DBM: 0.03
The calling client is,
Perl: 5.008008 (i686-linux)
OS : linux (2.6.17.14-abi)
DBI : 1.52
DBD::mysql : 3.0008
DBD::Sponge : 11.10
DBD::SQLite : 1.13
DBD::Proxy : 0.2004
DBD::Oracle : 1.19
DBD::Multiplex : 1.99
DBD::File : 0.35
DBD::ExampleP : 11.12
DBD::DBM: 0.03
RPC::PlServer are the same version.
>
> But I wonder if this is really the issue. Why hasn't anyone reported
> undef warnings on insert statement before? Would be good to add a test
> case to t/80proxy.t that reproduces the problem before you fix it.
>
> Tim.
>
> p.s. Any volunteers to work on a daemon wrapper for DBI::Gofer::Execute
> so it can be used as a replacement for the current DBI proxy server.
> (DBD::Gofer is potentially significantly faster than DBD::Proxy.)
> If so please start a new thread and I'll give a brain dump...
>
>
> > On Wed, 2007-03-28 at 13:35 -0500, Scott T. Hildreth wrote:
> > > So I tracked this down further, DBD::Proxy gets an array returned from
> > > the client calling
> > > the server. Which is ultimately put into @outData, and
> > > $outData[0]($numFields) is 'undef'
> > > and produces this warning,
> > >
> > > Use of uninitialized value in subroutine entry at
> > >/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm line
> > > 566.
> > >
> > >
> > > Here is where @outData is spliced,
> > >
> > > DBD::Proxy::st::execute(/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm:559):
> > > 559:my ($numFields, $numParams, $names, $types) =
> > > splice(@outData, 0, 4);
> > >
> > > I guess my next step is to run the Proxy server in debug mode and figure
> > > out why numFields
> > > is not filled in. I was hoping someone might know what is going on
> > > before I do that.
> > >
> > >
> > > Thanks
> > >
> > >
> > > On Thu, 2007-01-18 at 15:37 -0600, Scott T. Hildreth wrote:
> > > > ###
> > > >
> > > > Perl: 5.008008(i386-freebsd)
> > > > OS : freebsd (6.1-stable)
> > > > DBI : 1.53
> > > > DBD::mysql : 3.0004
> > > > DBD::Sponge : 11.10
> > > > DBD::SQLite : 1.12
> > > > DBD::Proxy : 0.2004
> > > > DBD::Multiplex : 2.00
> > > > DBD::File : 0.35
> > > > DBD::ExampleP : 11.12
> > > > DBD::DBM: 0.03
> > > > DBD::CSV: 0.22
> > > > DBD::AnyData: 0.08
> > > >
> > > > ##
> > > >
> > > > For every database call, do, execute, ...etc I get the warning,
> > > >
> > > > Use of uninitialized value in subroutine entry
> > > > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm
> > > > line 567.
> > > >
> > > > Which is " 'NUM_OF_FIELDS' => $numFields, ".
> > > >
> > > > I don't think this matters but, the proxy is connecting to DBD::Oracle,
> > > > the connect is in another module that is inherited by the module I a
Re: DBD::mysql 4.004 Released!
Feel free to send it to me before release, we will have the old client on that server until we upgrade it. Which will be awhile. On Tue, 2007-03-27 at 22:18 -0400, Patrick Galbraith wrote: > Scott, > > Thanks! I need to somehow find a 4.0 binary for OS X to find these pesky > things. > > regards, > > Patrick > > Scott T. Hildreth wrote: > > >Pat, > > > > The #ifdef's still need to be removed in the calls below. > > > >Thanks. > > > >dbdimp.c: In function `mysql_st_fetch': > >dbdimp.c:3429: error: too few arguments to function `mysql_dr_error' > >dbdimp.c:3593: error: too few arguments to function `mysql_dr_error' > >dbdimp.c: In function `mysql_st_FETCH_internal': > >dbdimp.c:3931: error: too few arguments to function `mysql_dr_error' > >dbdimp.c:3945: error: too few arguments to function `mysql_dr_error' > >dbdimp.c: In function `mysql_bind_ph': > >dbdimp.c:4264: error: too few arguments to function `mysql_dr_error' > >dbdimp.c:4291: error: too few arguments to function `mysql_dr_error' > >dbdimp.c:4303: error: too few arguments to function `mysql_dr_error' > >dbdimp.c: In function `mysql_db_reconnect': > >dbdimp.c:4465: error: too few arguments to function `mysql_dr_error' > > > >On Sun, 2007-03-25 at 10:40 -0400, Patrick Galbraith wrote: > > > > > >>Dear DBD::mysql users and developers, > >> > >>I'm pleased to announce the release of DBD::mysql 4.004! This release > >>contains various fixes, per Changelog: > >> > >>* Work around a bug in old 3.23 servers by specifying NOT NULL for > >>fields used > >> as a primary key in tests. (Bug #20325, reported by Julian Ladisch) > >>* Add support for mysql_warning_count statement handle attribute. (Bug > >>#25457, > >> patch from Philip Stoev) > >>* Add support for mysql_multi_statements connection option. (RT #12322, > >>based > >> on patch from Doug Morris) > >>* Had to bump to 4.003 do to print statement in mysql.pm that made it > >> into the dist. Even though you can delete a file on CPAN, you cannot > >> re-upload it if it's the same name. Mea Culpa. > >>* UTF8-Flag not set with flag mysql_enable_utf8 and column collation > >>utf8_bin patch, > >> Joost Diepenmaat, (RT #24738) > >>* Fixed do_error definition (Scott Hildreth, Tim Bunce) > >>* Conversion of test suite to Test::More > >> > >>This release was possible due to the efforts of: > >> > >>Jim Winstead > >>Tim Bunce > >>Scott Hildreth > >>Joost Diepenmaat > >>Dave Rolsky > >>Philip Stoev > >>Doug Morris > >>Julian Ladisch > >> > >>And the rest of the community, and anyone else I forgot to mention! > >> > >>Thank you for using DBD::mysql and MySQL! > >> > >>The files: > >> > >> file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.004.tar.gz > >> size: 122247 bytes > >> md5: ba89b04b003dec320c893f2553a98ede > >> > >> > >>Also: > >> > >>http://search.cpan.org/~capttofu/DBD-mysql-4.004/ > >> > >>Kind regards, > >> > >>Patrick Galbraith > >> > >> > >> > >> > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
DBD::Gofer::Execute - daemon
> p.s. Any volunteers to work on a daemon wrapper for DBI::Gofer::Execute > so it can be used as a replacement for the current DBI proxy server. > (DBD::Gofer is potentially significantly faster than DBD::Proxy.) Are you envisioning DBD::Gofer replacing DBD::Proxy? If so, would a daemon process enable transactions for DBD::Gofer? Probably still stateless, thought I would ask. > If so please start a new thread and I'll give a brain dump... > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::Proxy - getting unitialized error for $numFields
On Wed, 2007-03-28 at 15:59 -0500, Scott T. Hildreth wrote:
> On Wed, 2007-03-28 at 21:26 +0100, Tim Bunce wrote:
> > On Wed, Mar 28, 2007 at 01:54:51PM -0500, Scott T. Hildreth wrote:
> > > I should also mention that this is a $dbh->do( "an insert statement").
> > > A quick look at DBI::ProxyServer, shows that the NUMFIELDS indicates
> > > a select, therefore in this case 'undef' would be returned for an
> > > insert. Should it be initialized to '0', to quite warnings on
> > > non-selects?
> >
> > That would work. As would:
> >
> > $sth->SUPER::STORE('NUM_OF_FIELDS' => $numFields) if $numFields;
> >
> > Doing both would make life easier for people who can't upgrade client
> > and server at the same time.
>
> Do think if I updated my server this would go away?
..Never mind, I misread the above statement.
>
> The proxy server is,
>
> Perl: 5.008008(i686-linux)
> OS : linux (2.6.14.6)
> DBI : 1.50
> DBD::mysql : 3.0002
> DBD::Sponge : 11.10
> DBD::SQLite : 1.11
> DBD::Proxy : 0.2004
> DBD::Oracle : 1.19
> DBD::Multiplex : 1.98
> DBD::File : 0.33
> DBD::ExampleP : 11.12
> DBD::DBM: 0.03
>
> The calling client is,
>
> Perl: 5.008008 (i686-linux)
>
> OS : linux (2.6.17.14-abi)
> DBI : 1.52
> DBD::mysql : 3.0008
> DBD::Sponge : 11.10
> DBD::SQLite : 1.13
> DBD::Proxy : 0.2004
> DBD::Oracle : 1.19
> DBD::Multiplex : 1.99
> DBD::File : 0.35
> DBD::ExampleP : 11.12
> DBD::DBM: 0.03
>
>
> RPC::PlServer are the same version.
>
>
> >
> > But I wonder if this is really the issue. Why hasn't anyone reported
> > undef warnings on insert statement before? Would be good to add a test
> > case to t/80proxy.t that reproduces the problem before you fix it.
> >
> > Tim.
> >
> > p.s. Any volunteers to work on a daemon wrapper for DBI::Gofer::Execute
> > so it can be used as a replacement for the current DBI proxy server.
> > (DBD::Gofer is potentially significantly faster than DBD::Proxy.)
>
>
> > If so please start a new thread and I'll give a brain dump...
> >
> >
> > > On Wed, 2007-03-28 at 13:35 -0500, Scott T. Hildreth wrote:
> > > > So I tracked this down further, DBD::Proxy gets an array returned from
> > > > the client calling
> > > > the server. Which is ultimately put into @outData, and
> > > > $outData[0]($numFields) is 'undef'
> > > > and produces this warning,
> > > >
> > > > Use of uninitialized value in subroutine entry at
> > > >/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm
> > > > line 566.
> > > >
> > > >
> > > > Here is where @outData is spliced,
> > > >
> > > > DBD::Proxy::st::execute(/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm:559):
> > > > 559:my ($numFields, $numParams, $names, $types) =
> > > > splice(@outData, 0, 4);
> > > >
> > > > I guess my next step is to run the Proxy server in debug mode and
> > > > figure out why numFields
> > > > is not filled in. I was hoping someone might know what is going on
> > > > before I do that.
> > > >
> > > >
> > > > Thanks
> > > >
> > > >
> > > > On Thu, 2007-01-18 at 15:37 -0600, Scott T. Hildreth wrote:
> > > > > ###
> > > > >
> > > > > Perl: 5.008008(i386-freebsd)
> > > > > OS : freebsd (6.1-stable)
> > > > > DBI : 1.53
> > > > > DBD::mysql : 3.0004
> > > > > DBD::Sponge : 11.10
> > > > > DBD::SQLite : 1.12
> > > > > DBD::Proxy : 0.2004
> > > > > DBD::Multiplex : 2.00
> > > > > DBD::File : 0.35
> > > > > DBD::ExampleP : 11.12
> > > > > DBD::DBM: 0.03
> > > > > DBD::CSV: 0.22
> > > > > DBD::AnyData: 0.08
> > > > >
> > > > > ###
Re: DBD::Proxy - getting unitialized error for $numFields
I should also mention that this is a $dbh->do( "an insert statement"). A quick look at DBI::ProxyServer, shows that the NUMFIELDS indicates a select, therefore in this case 'undef' would be returned for an insert. Should it be initialized to '0', to quite warnings on non-selects? On Wed, 2007-03-28 at 13:35 -0500, Scott T. Hildreth wrote: > So I tracked this down further, DBD::Proxy gets an array returned from the > client calling > the server. Which is ultimately put into @outData, and > $outData[0]($numFields) is 'undef' > and produces this warning, > > Use of uninitialized value in subroutine entry at >/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm line 566. > > > Here is where @outData is spliced, > > DBD::Proxy::st::execute(/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm:559): > 559:my ($numFields, $numParams, $names, $types) = > splice(@outData, 0, 4); > > I guess my next step is to run the Proxy server in debug mode and figure out > why numFields > is not filled in. I was hoping someone might know what is going on before I > do that. > > > Thanks > > > On Thu, 2007-01-18 at 15:37 -0600, Scott T. Hildreth wrote: > > ### > > > > Perl: 5.008008(i386-freebsd) > > OS : freebsd (6.1-stable) > > DBI : 1.53 > > DBD::mysql : 3.0004 > > DBD::Sponge : 11.10 > > DBD::SQLite : 1.12 > > DBD::Proxy : 0.2004 > > DBD::Multiplex : 2.00 > > DBD::File : 0.35 > > DBD::ExampleP : 11.12 > > DBD::DBM: 0.03 > > DBD::CSV: 0.22 > > DBD::AnyData: 0.08 > > > > ## > > > > For every database call, do, execute, ...etc I get the warning, > > > > Use of uninitialized value in subroutine entry > > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm > > line 567. > > > > Which is " 'NUM_OF_FIELDS' => $numFields, ". > > > > I don't think this matters but, the proxy is connecting to DBD::Oracle, > > the connect is in another module that is inherited by the module I am > > testing. > > > > I am also getting disconnect errors on the DESTROY, > > > > (in cleanup) DBD::Proxy::db disconnect failed: Can't call method > > "disconnect" on an undefined value > > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm > > line 311 during global destruction. > > > > (in cleanup) DBD::Proxy::db DESTROY failed: Can't call method > > "disconnect" on an undefined value > > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm > > line 311 during global destruction. > > > > > > My eyes are glazing over, so any help would be appreciated. I'm sure it > > is something simple I am missing here... > > > > > > Thanks. > > > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::Proxy - getting unitialized error for $numFields
So I tracked this down further, DBD::Proxy gets an array returned from the client calling the server. Which is ultimately put into @outData, and $outData[0]($numFields) is 'undef' and produces this warning, Use of uninitialized value in subroutine entry at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm line 566. Here is where @outData is spliced, DBD::Proxy::st::execute(/usr/local/perl-5.8.8/lib/site_perl/5.8.8/i686-linux/DBD/Proxy.pm:559): 559:my ($numFields, $numParams, $names, $types) = splice(@outData, 0, 4); I guess my next step is to run the Proxy server in debug mode and figure out why numFields is not filled in. I was hoping someone might know what is going on before I do that. Thanks On Thu, 2007-01-18 at 15:37 -0600, Scott T. Hildreth wrote: > ### > > Perl: 5.008008(i386-freebsd) > OS : freebsd (6.1-stable) > DBI : 1.53 > DBD::mysql : 3.0004 > DBD::Sponge : 11.10 > DBD::SQLite : 1.12 > DBD::Proxy : 0.2004 > DBD::Multiplex : 2.00 > DBD::File : 0.35 > DBD::ExampleP : 11.12 > DBD::DBM: 0.03 > DBD::CSV: 0.22 > DBD::AnyData: 0.08 > > ## > > For every database call, do, execute, ...etc I get the warning, > > Use of uninitialized value in subroutine entry > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm > line 567. > > Which is " 'NUM_OF_FIELDS' => $numFields, ". > > I don't think this matters but, the proxy is connecting to DBD::Oracle, > the connect is in another module that is inherited by the module I am > testing. > > I am also getting disconnect errors on the DESTROY, > > (in cleanup) DBD::Proxy::db disconnect failed: Can't call method > "disconnect" on an undefined value > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm > line 311 during global destruction. > > (in cleanup) DBD::Proxy::db DESTROY failed: Can't call method > "disconnect" on an undefined value > at /usr/local/perl-5.8.8/lib/site_perl/5.8.8/i386-freebsd/DBD/Proxy.pm > line 311 during global destruction. > > > My eyes are glazing over, so any help would be appreciated. I'm sure it > is something simple I am missing here... > > > Thanks. > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::mysql 4.004 Released!
Pat, The #ifdef's still need to be removed in the calls below. Thanks. dbdimp.c: In function `mysql_st_fetch': dbdimp.c:3429: error: too few arguments to function `mysql_dr_error' dbdimp.c:3593: error: too few arguments to function `mysql_dr_error' dbdimp.c: In function `mysql_st_FETCH_internal': dbdimp.c:3931: error: too few arguments to function `mysql_dr_error' dbdimp.c:3945: error: too few arguments to function `mysql_dr_error' dbdimp.c: In function `mysql_bind_ph': dbdimp.c:4264: error: too few arguments to function `mysql_dr_error' dbdimp.c:4291: error: too few arguments to function `mysql_dr_error' dbdimp.c:4303: error: too few arguments to function `mysql_dr_error' dbdimp.c: In function `mysql_db_reconnect': dbdimp.c:4465: error: too few arguments to function `mysql_dr_error' On Sun, 2007-03-25 at 10:40 -0400, Patrick Galbraith wrote: > Dear DBD::mysql users and developers, > > I'm pleased to announce the release of DBD::mysql 4.004! This release > contains various fixes, per Changelog: > > * Work around a bug in old 3.23 servers by specifying NOT NULL for > fields used > as a primary key in tests. (Bug #20325, reported by Julian Ladisch) > * Add support for mysql_warning_count statement handle attribute. (Bug > #25457, > patch from Philip Stoev) > * Add support for mysql_multi_statements connection option. (RT #12322, > based > on patch from Doug Morris) > * Had to bump to 4.003 do to print statement in mysql.pm that made it > into the dist. Even though you can delete a file on CPAN, you cannot > re-upload it if it's the same name. Mea Culpa. > * UTF8-Flag not set with flag mysql_enable_utf8 and column collation > utf8_bin patch, > Joost Diepenmaat, (RT #24738) > * Fixed do_error definition (Scott Hildreth, Tim Bunce) > * Conversion of test suite to Test::More > > This release was possible due to the efforts of: > > Jim Winstead > Tim Bunce > Scott Hildreth > Joost Diepenmaat > Dave Rolsky > Philip Stoev > Doug Morris > Julian Ladisch > > And the rest of the community, and anyone else I forgot to mention! > > Thank you for using DBD::mysql and MySQL! > > The files: > > file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.004.tar.gz > size: 122247 bytes >md5: ba89b04b003dec320c893f2553a98ede > > > Also: > > http://search.cpan.org/~capttofu/DBD-mysql-4.004/ > > Kind regards, > > Patrick Galbraith > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::mysql 4.003 Released! - Error Compiling
On Tue, 2007-03-13 at 13:13 +, Tim Bunce wrote: > On Thu, Mar 08, 2007 at 12:23:17PM -0600, Scott T. Hildreth wrote: > > On Wed, 2007-03-07 at 16:58 -0600, Scott T. Hildreth wrote: > > > mysql Ver 12.21 Distrib 4.0.15, for suse-linux (i686) > > > > > > ... So my client is not >= to SQL_STATE_VERSION, but dbdimp.c > > > still has do_error accepting a sqlstate param, > > > > > > void do_error(SV* h, int rc, const char* what, const char* sqlstate) > > > > > > causing this compile error, > > > > > > dbdimp.c:1269: error: conflicting types for `mysql_dr_error' > > > dbdimp.h:288: error: previous declaration of `mysql_dr_error' > > > dbdimp.c: In function `mysql_st_fetch': > > > dbdimp.c:3419: error: too few arguments to function `mysql_dr_error' > > > dbdimp.c:3583: error: too few arguments to function `mysql_dr_error' > > > dbdimp.c: In function `mysql_st_FETCH_internal': > > > dbdimp.c:3915: error: too few arguments to function `mysql_dr_error' > > > dbdimp.c:3929: error: too few arguments to function `mysql_dr_error' > > > dbdimp.c: In function `mysql_bind_ph': > > > dbdimp.c:4244: error: too few arguments to function `mysql_dr_error' > > > dbdimp.c:4271: error: too few arguments to function `mysql_dr_error' > > > dbdimp.c:4283: error: too few arguments to function `mysql_dr_error' > > > dbdimp.c: In function `mysql_db_reconnect': > > > dbdimp.c:4445: error: too few arguments to function `mysql_dr_error' > > > make: *** [dbdimp.o] Error 1 > > > > Well I put the below #if's around all the do_error calls in dbdimp.c > > and got dbdimp.c to compile. Now mysql.xs needs these #if's. Before > > I add them, I wanted know if there is a better way of doing this or > > is this the right way to fix the error? > > I think the best fix is possibly just: > > --- ./dbdimp.h.orig 2007-03-13 13:12:20.0 + > +++ ./dbdimp.h 2007-03-13 13:12:32.0 + > @@ -282,11 +282,7 @@ > #endif > > #include > -#if MYSQL_VERSION_ID >= SQL_STATE_VERSION > voiddo_error (SV* h, int rc, const char *what, const char *sqlstate); > -#else > -voiddo_error (SV* h, int rc, const char *what); > -#endif > SV *dbd_db_fieldlist (MYSQL_RES* res); > > voiddbd_preparse (imp_sth_t *imp_sth, SV *statement); > > but I'm not in a position to test it. > > Could you try that on a freshly unpacked distribution with the old client? That worked. I had to remove the #if's from dbdimp.c where the "too few arguments" occurred (shown above). The same tests fail. I looked at some of them and this is due to the older client being used. This approach is to remove all the MYSQL_VERSION_ID checking and mine was to add it everywhere. I tend to over do things. :-) > > Tim. -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::mysql 4.003 Released! - Error Compiling
> > > > I went ahead and added the #if's to mysql.xs, everything compiled. > Most the tests pass, > > Failed Test Stat Wstat Total Fail List of Failed > --- > t/20createdrop.t 61 5 > t/80procs.t 255 6528032 44 11-32 > t/prepare_noerror.t31 2 > t/utf8.t 152 6 11 > 2 tests skipped. > Failed 4/27 test scripts. 26/575 subtests failed. > Files=27, Tests=575, 5 wallclock secs ( 1.39 cusr + 0.29 csys = 1.68 > CPU) > I think some of the failures are due to the older client being used. Would you like a patch of what I changed? > > > Thanks. > > > > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::mysql 4.003 Released! - Error Compiling
On Thu, 2007-03-08 at 12:23 -0600, Scott T. Hildreth wrote:
> On Wed, 2007-03-07 at 16:58 -0600, Scott T. Hildreth wrote:
> > mysql Ver 12.21 Distrib 4.0.15, for suse-linux (i686)
> >
> > ... So my client is not >= to SQL_STATE_VERSION, but dbdimp.c
> > still has do_error accepting a sqlstate param,
> >
> > void do_error(SV* h, int rc, const char* what, const char* sqlstate)
> >
> > causing this compile error,
> >
> > dbdimp.c:1269: error: conflicting types for `mysql_dr_error'
> > dbdimp.h:288: error: previous declaration of `mysql_dr_error'
> > dbdimp.c: In function `mysql_st_fetch':
> > dbdimp.c:3419: error: too few arguments to function `mysql_dr_error'
> > dbdimp.c:3583: error: too few arguments to function `mysql_dr_error'
> > dbdimp.c: In function `mysql_st_FETCH_internal':
> > dbdimp.c:3915: error: too few arguments to function `mysql_dr_error'
> > dbdimp.c:3929: error: too few arguments to function `mysql_dr_error'
> > dbdimp.c: In function `mysql_bind_ph':
> > dbdimp.c:4244: error: too few arguments to function `mysql_dr_error'
> > dbdimp.c:4271: error: too few arguments to function `mysql_dr_error'
> > dbdimp.c:4283: error: too few arguments to function `mysql_dr_error'
> > dbdimp.c: In function `mysql_db_reconnect':
> > dbdimp.c:4445: error: too few arguments to function `mysql_dr_error'
> > make: *** [dbdimp.o] Error 1
>
> Well I put the below #if's around all the do_error calls in dbdimp.c
> and got dbdimp.c to compile. Now mysql.xs needs these #if's. Before
> I add them, I wanted know if there is a better way of doing this or
> is this the right way to fix the error?
>
>
> #if MYSQL_VERSION_ID >= SQL_STATE_VERSION
>, {NULL or mysql_sqlstate());
> #else
>);
> #endif
>
>
I went ahead and added the #if's to mysql.xs, everything compiled.
Most the tests pass,
Failed Test Stat Wstat Total Fail List of Failed
---
t/20createdrop.t 61 5
t/80procs.t 255 6528032 44 11-32
t/prepare_noerror.t31 2
t/utf8.t 152 6 11
2 tests skipped.
Failed 4/27 test scripts. 26/575 subtests failed.
Files=27, Tests=575, 5 wallclock secs ( 1.39 cusr + 0.29 csys = 1.68
CPU)
> Thanks.
>
> >
> > I can upgrade my client, just thought you should be aware of the error.
> >
> >
> > On Sat, 2007-03-03 at 22:12 -0500, Patrick Galbraith wrote:
> > > Dear DBD::mysql users and developers,
> > >
> > > I'm pleased to announce the release of DBD::mysql 4.003! This release
> > > contains
> > > various fixes including:
> > >
> > > * Fix re-exec of Makefile.PL when forcing $ENV{LANG} to 'C'. (RT #25233,
> > > reported by Slaven Rezic)
> > > * Rewrote table_info method to support all arguments (previously it would
> > > only ever return all of the tables in the current database, no matter
> > > what
> > > was specified)
> > > * Fixed $DBD::mysql::VERSION to be a string instead of a float, which
> > > caused
> > > problems for certain locales
> > > * Fixed bug #23974. $dbh->column_info now returns empty arrayref upon
> > > table
> > >not existing. Much thanks to Tim Bunce for help fixing the problem in
> > >mysql.pm vs. dbdimp.c
> > > * Removed #ifdefs for do error (sqlstate being passed as last arg
> > > depending on
> > > version)
> > > * Fixed insertid test to work with auto_increment_increment replication
> > > setup.
> > > * Patch from Tim Bunce fixing do() not set $dbh->{Statement} attribute,
> > > which prevented DBD::Profile from giving correct results for calls to
> > > do()
> > > and causing ShowErrorStatement to possibly report the wrong statement
> > > in the
> > > error message
> > > * Patch from Tim Bunce clearing out the sth attribute cache when switching
> > > between result, sets which prevented the adjustedment of NUM_OF_FIELDS
> > > * Cleanup of several unused variables
> > > * Added support for wildcards in last argument of column_info().
> > > * Add mysql_is_auto_increment to results of column_info(). (Bug #26603,
> > > original patch from Dave Rolsky)
> > > * Return the correct table type for both tables and views from the
> > > table_info()
> > > method. (Bug #26603, original patch
Re: DBD::mysql 4.003 Released! - Error Compiling
On Wed, 2007-03-07 at 16:58 -0600, Scott T. Hildreth wrote:
> mysql Ver 12.21 Distrib 4.0.15, for suse-linux (i686)
>
> ... So my client is not >= to SQL_STATE_VERSION, but dbdimp.c
> still has do_error accepting a sqlstate param,
>
> void do_error(SV* h, int rc, const char* what, const char* sqlstate)
>
> causing this compile error,
>
> dbdimp.c:1269: error: conflicting types for `mysql_dr_error'
> dbdimp.h:288: error: previous declaration of `mysql_dr_error'
> dbdimp.c: In function `mysql_st_fetch':
> dbdimp.c:3419: error: too few arguments to function `mysql_dr_error'
> dbdimp.c:3583: error: too few arguments to function `mysql_dr_error'
> dbdimp.c: In function `mysql_st_FETCH_internal':
> dbdimp.c:3915: error: too few arguments to function `mysql_dr_error'
> dbdimp.c:3929: error: too few arguments to function `mysql_dr_error'
> dbdimp.c: In function `mysql_bind_ph':
> dbdimp.c:4244: error: too few arguments to function `mysql_dr_error'
> dbdimp.c:4271: error: too few arguments to function `mysql_dr_error'
> dbdimp.c:4283: error: too few arguments to function `mysql_dr_error'
> dbdimp.c: In function `mysql_db_reconnect':
> dbdimp.c:4445: error: too few arguments to function `mysql_dr_error'
> make: *** [dbdimp.o] Error 1
Well I put the below #if's around all the do_error calls in dbdimp.c
and got dbdimp.c to compile. Now mysql.xs needs these #if's. Before
I add them, I wanted know if there is a better way of doing this or
is this the right way to fix the error?
#if MYSQL_VERSION_ID >= SQL_STATE_VERSION
, {NULL or mysql_sqlstate());
#else
);
#endif
Thanks.
>
> I can upgrade my client, just thought you should be aware of the error.
>
>
> On Sat, 2007-03-03 at 22:12 -0500, Patrick Galbraith wrote:
> > Dear DBD::mysql users and developers,
> >
> > I'm pleased to announce the release of DBD::mysql 4.003! This release
> > contains
> > various fixes including:
> >
> > * Fix re-exec of Makefile.PL when forcing $ENV{LANG} to 'C'. (RT #25233,
> > reported by Slaven Rezic)
> > * Rewrote table_info method to support all arguments (previously it would
> > only ever return all of the tables in the current database, no matter what
> > was specified)
> > * Fixed $DBD::mysql::VERSION to be a string instead of a float, which caused
> > problems for certain locales
> > * Fixed bug #23974. $dbh->column_info now returns empty arrayref upon
> > table
> >not existing. Much thanks to Tim Bunce for help fixing the problem in
> >mysql.pm vs. dbdimp.c
> > * Removed #ifdefs for do error (sqlstate being passed as last arg
> > depending on
> > version)
> > * Fixed insertid test to work with auto_increment_increment replication
> > setup.
> > * Patch from Tim Bunce fixing do() not set $dbh->{Statement} attribute,
> > which prevented DBD::Profile from giving correct results for calls to do()
> > and causing ShowErrorStatement to possibly report the wrong statement
> > in the
> > error message
> > * Patch from Tim Bunce clearing out the sth attribute cache when switching
> > between result, sets which prevented the adjustedment of NUM_OF_FIELDS
> > * Cleanup of several unused variables
> > * Added support for wildcards in last argument of column_info().
> > * Add mysql_is_auto_increment to results of column_info(). (Bug #26603,
> > original patch from Dave Rolsky)
> > * Return the correct table type for both tables and views from the
> > table_info()
> > method. (Bug #26603, original patch from Dave Rolsky)
> > * Add implementation of foreign_key_info() (Bug #26604, original patch from
> > Dave Rolsky, and final implementation based on Connector/J code)
> >
> > Note: you may notice that the version went from 4.001 to 4.003. That's
> > because there
> > was an issue with the 4.002 distribution file that needed to be fixed,
> > and CPAN
> > doesn't allow uploading the same version file twice, hence the version
> > was bumped.
> >
> > This release was possible due to the efforts of:
> >
> > Jim Winstead
> > Tim Bunce
> > Dave Rolsky
> >
> > Thanks for bug reporting from
> >
> > Slaven Rezic RT #25233
> > Allard Hoeve and others alerting me to problems with version being
> > changed from
> > a string, which caused local issues for those who use ',' instead of '.'
> > for decimal.
> >
> > And anyone else I forgot to mention. Thank you for reporting bugs and
> > sending
> > patches!
> >
> > Also, thank you for using DBD::mysql!
> >
> > Kind regards,
> >
> > Patrick Galbraith
> >
> > The file:
> >
> > file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.003.tar.gz
> > size: 121582 bytes
> >md5: 157f817d26a52aaaff61ce38f7043b95
> >
> >
> --
> Scott T. Hildreth <[EMAIL PROTECTED]>
--
Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::mysql 4.003 Released! - Error Compiling
mysql Ver 12.21 Distrib 4.0.15, for suse-linux (i686)
... So my client is not >= to SQL_STATE_VERSION, but dbdimp.c
still has do_error accepting a sqlstate param,
void do_error(SV* h, int rc, const char* what, const char* sqlstate)
causing this compile error,
dbdimp.c:1269: error: conflicting types for `mysql_dr_error'
dbdimp.h:288: error: previous declaration of `mysql_dr_error'
dbdimp.c: In function `mysql_st_fetch':
dbdimp.c:3419: error: too few arguments to function `mysql_dr_error'
dbdimp.c:3583: error: too few arguments to function `mysql_dr_error'
dbdimp.c: In function `mysql_st_FETCH_internal':
dbdimp.c:3915: error: too few arguments to function `mysql_dr_error'
dbdimp.c:3929: error: too few arguments to function `mysql_dr_error'
dbdimp.c: In function `mysql_bind_ph':
dbdimp.c:4244: error: too few arguments to function `mysql_dr_error'
dbdimp.c:4271: error: too few arguments to function `mysql_dr_error'
dbdimp.c:4283: error: too few arguments to function `mysql_dr_error'
dbdimp.c: In function `mysql_db_reconnect':
dbdimp.c:4445: error: too few arguments to function `mysql_dr_error'
make: *** [dbdimp.o] Error 1
I can upgrade my client, just thought you should be aware of the error.
On Sat, 2007-03-03 at 22:12 -0500, Patrick Galbraith wrote:
> Dear DBD::mysql users and developers,
>
> I'm pleased to announce the release of DBD::mysql 4.003! This release
> contains
> various fixes including:
>
> * Fix re-exec of Makefile.PL when forcing $ENV{LANG} to 'C'. (RT #25233,
> reported by Slaven Rezic)
> * Rewrote table_info method to support all arguments (previously it would
> only ever return all of the tables in the current database, no matter what
> was specified)
> * Fixed $DBD::mysql::VERSION to be a string instead of a float, which caused
> problems for certain locales
> * Fixed bug #23974. $dbh->column_info now returns empty arrayref upon
> table
>not existing. Much thanks to Tim Bunce for help fixing the problem in
>mysql.pm vs. dbdimp.c
> * Removed #ifdefs for do error (sqlstate being passed as last arg
> depending on
> version)
> * Fixed insertid test to work with auto_increment_increment replication
> setup.
> * Patch from Tim Bunce fixing do() not set $dbh->{Statement} attribute,
> which prevented DBD::Profile from giving correct results for calls to do()
> and causing ShowErrorStatement to possibly report the wrong statement
> in the
> error message
> * Patch from Tim Bunce clearing out the sth attribute cache when switching
> between result, sets which prevented the adjustedment of NUM_OF_FIELDS
> * Cleanup of several unused variables
> * Added support for wildcards in last argument of column_info().
> * Add mysql_is_auto_increment to results of column_info(). (Bug #26603,
> original patch from Dave Rolsky)
> * Return the correct table type for both tables and views from the
> table_info()
> method. (Bug #26603, original patch from Dave Rolsky)
> * Add implementation of foreign_key_info() (Bug #26604, original patch from
> Dave Rolsky, and final implementation based on Connector/J code)
>
> Note: you may notice that the version went from 4.001 to 4.003. That's
> because there
> was an issue with the 4.002 distribution file that needed to be fixed,
> and CPAN
> doesn't allow uploading the same version file twice, hence the version
> was bumped.
>
> This release was possible due to the efforts of:
>
> Jim Winstead
> Tim Bunce
> Dave Rolsky
>
> Thanks for bug reporting from
>
> Slaven Rezic RT #25233
> Allard Hoeve and others alerting me to problems with version being
> changed from
> a string, which caused local issues for those who use ',' instead of '.'
> for decimal.
>
> And anyone else I forgot to mention. Thank you for reporting bugs and
> sending
> patches!
>
> Also, thank you for using DBD::mysql!
>
> Kind regards,
>
> Patrick Galbraith
>
> The file:
>
> file: $CPAN/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.003.tar.gz
> size: 121582 bytes
>md5: 157f817d26a52aaaff61ce38f7043b95
>
>
--
Scott T. Hildreth <[EMAIL PROTECTED]>
Re: ANNOUNCE: DBI 1.54 RC2 - including cool new DBD::Gofer stateless proxy
On Fri, 2007-02-02 at 11:50 +, Tim Bunce wrote: FreeBSD 6.1 This is perl, v5.8.8 built for i386-freebsd ** All tests pass. -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: ANNOUNCE: DBI 1.54 RC2 - including cool new DBD::Gofer stateless proxy
On Fri, 2007-02-02 at 15:45 +, Tim Bunce wrote: > Now an RC3 (with the t/*_13taint.t fix) to make life simple for those just > waking up: > > http://homepage.mac.com/tim.bunce/.Public/perl/DBI-1.54-RC3.tar.gz > 5.8.6 i386-freebsd= ok 5.8.8 i386-freebsd= ok 5.8.7 i386-freebsd-thread-multi = ok > Tim. > > On Fri, Feb 02, 2007 at 11:50:14AM +, Tim Bunce wrote: > > You can download it from: > > > > http://homepage.mac.com/tim.bunce/.Public/perl/DBI-1.54-RC2.tar.gz > > > > =head2 Changes in DBI 1.54 (svn rev 8791), 2nd February 2007 > > > > NOTE: This release includes the 'next big thing' for DBI: DBD::Gofer. > > Take a look! > > > > WARNING: This version has some subtle changes in DBI internals. > > It's possible, though doubtful, that some may affect your code. > > I recommend some extra texting before installing this release. > > > > Fixed type_info when called for multiple dbh thanks to Cosimo Streppone. > > Fixed compile warnings in bleadperl on freebsd-6.1-release > > and solaris 10g thanks to Philip M. Gollucci. > > Fixed to compile for perl built with -DNO_MATHOMS thanks to Jerry D. > > Hedden. > > Fixed to work for bleadperl (r29544) thanks to Nicholas Clark. > > Users of Perl >= 5.9.5 will require DBI >= 1.54. > > Fixed rare error when profiling access to $DBI::err etc tied variables. > > > > Changed t/40profile.t to skip tests for perl < 5.8.0. > > Changed setting trace file to no longer write "Trace file set" to new > > file. > > Changed 'handle cleared whilst still active' warning for dbh > > to only be given for dbh that have active sth or are not AutoCommit. > > Changed take_imp_data to call finish on all Active child sth. > > Changed DBI::PurePerl trace() method to be more consistent. > > Changed handle factory methods, like connect, prepare, and table_info, > > to copy any error/warn/info state of the handle being returned > > up into the handle the method was called on. > > Updated DBI::DBD docs for driver authors thanks to Ammon Riley > > and Dean Arnold. > > > > Added new DBD::Gofer 'stateless proxy' driver and framework, > > and the DBI test suite is now also executed via DBD::Gofer, > > and DBD::Gofer+DBI::PurePerl, in addition to DBI::PurePerl. > > Added ability for trace() to support filehandle argument, > > including tracing into a string, thanks to Dean Arnold. > > Added ability for drivers to implement func() method > > so proxy drivers can proxy the func method itself. > > Added SQL_BIGINT type code (resolved to the ODBC/JDBC value (-5)) > > > > =cut > > > > Same as RC1 except fixes a binary compatibility problem with compiled > > drivers > > (so this is safe to install) and removes dependency on Class::Accessor. > > > > I'd be grateful for any testing, and especially for feedback on DBD::Gofer > > (previously mentioned as DBD::Forward, but DBD::Gofer is a much better name > > :) > > > > Enjoy! > > > > Tim. -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: ANNOUNCE: DBI 1.54 RC2 - including cool new DBD::Gofer stateless proxy
On Fri, 2007-02-02 at 12:13 +, Tielman de Villiers wrote: > On Fri, 2007-02-02 at 11:50 +, Tim Bunce wrote: > > You can download it from: > > > > http://homepage.mac.com/tim.bunce/.Public/perl/DBI-1.54-RC2.tar.gz > > > > =head2 Changes in DBI 1.54 (svn rev 8791), 2nd February 2007 > > > > > Same as RC1 except fixes a binary compatibility problem with compiled > > drivers > > (so this is safe to install) and removes dependency on Class::Accessor. > > > > I'd be grateful for any testing, and especially for feedback on DBD::Gofer > > (previously mentioned as DBD::Forward, but DBD::Gofer is a much better name > > :) > > > > uname -a > Linux lmn12448 2.6.17-10-386 #2 Tue Dec 5 22:26:18 UTC 2006 i686 > GNU/Linux > > perl -v > This is perl, v5.8.8 built for i486-linux-gnu-thread-multi > > make test errors > > t/zvg_13taint.Can't locate t/13taint.t in @INC (@INC > contains: /home/tvilliers/usr/src/DBI-1.54/blib/lib > /home/tvilliers/usr/src/DBI-1.54/blib/arch > /home/tvilliers/usr/lib/perl5/5.8.7 /home/tvilliers/usr/lib/perl5/5.8.7 > /home/tvilliers/usr/lib/perl5 /etc/perl /usr/local/lib/perl/5.8.8 > /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 > /usr/share/perl/5.8 /usr/local/lib/site_perl /usr/local/lib/perl/5.8.7 > /usr/local/share/perl/5.8.7) at t/zvg_13taint.t line 3. > > t/zvp_13taint.Can't locate t/13taint.t in @INC (@INC > contains: /home/tvilliers/usr/src/DBI-1.54/blib/lib > /home/tvilliers/usr/src/DBI-1.54/blib/arch > /home/tvilliers/usr/lib/perl5/5.8.7 /home/tvilliers/usr/lib/perl5/5.8.7 > /home/tvilliers/usr/lib/perl5 /etc/perl /usr/local/lib/perl/5.8.8 > /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 > /usr/share/perl/5.8 /usr/local/lib/site_perl /usr/local/lib/perl/5.8.7 > /usr/local/share/perl/5.8.7) at t/zvp_13taint.t line 3. > > t/zvxgp_13taint...Can't locate t/13taint.t in @INC (@INC > contains: /home/tvilliers/usr/src/DBI-1.54/blib/lib > /home/tvilliers/usr/src/DBI-1.54/blib/arch > /home/tvilliers/usr/lib/perl5/5.8.7 /home/tvilliers/usr/lib/perl5/5.8.7 > /home/tvilliers/usr/lib/perl5 /etc/perl /usr/local/lib/perl/5.8.8 > /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 > /usr/share/perl/5.8 /usr/local/lib/site_perl /usr/local/lib/perl/5.8.7 > /usr/local/share/perl/5.8.7) at t/zvxgp_13taint.t line 3. > > Failed Test Stat Wstat Total Fail Failed List of Failed > --- > t/zvg_13taint.t 2 512?? ?? % ?? > t/zvp_13taint.t 2 512?? ?? % ?? > t/zvxgp_13taint.t2 512?? ?? % ?? > 18 tests and 260 subtests skipped. > Failed 3/117 test scripts, 97.44% okay. 0/4995 subtests failed, 100.00% > okay. Same errors on FreeBSD 6.1 This is perl, v5.8.7 built for i386-freebsd-thread-multi -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: Testing DBD::Oracle array interface
On Tue, 2006-06-06 at 08:20 -0400, John Scoles wrote: > http://svn.perl.org/modules/dbd-oracle/branches/array I am not an svn user (well we still use cvs at work), shouldn't I be able to run, 'svn co http://svn.perl.org/modules/dbd-oracle/branches/array' ..or is that dir not able to be checked out? > > I was hoping someone could do a benchmark type test on loading many thousand > or millions or records, as this seem to be what people want to use the > interface for. > > Cheers John Scoles > > > - Original Message - > From: "Shreedhar Natarajan" <[EMAIL PROTECTED]> > To: "John Scoles" <[EMAIL PROTECTED]> > Sent: Monday, May 29, 2006 10:03 AM > Subject: Re: oracle array interface > > > > Hi John, > > > > I am happy to do the testing. I was about to give up on perl/oracle. I > deal > > with large sets of data. I appreciate your working on it. > > > > In the meantime, to keep me productive on my research, I am considering > > using java and calling java from perl. Any thoughts on that? > > > > Thanks, > > Shreedhar > > > > > > At 09:51 AM 5/29/2006 -0400, you wrote: > > >I am sort of working on it right now. Slowly of course. The current one > > >works but all it does is iterate over you array and execute your > statements. > > >It makes your code tidy but does not go any faster that doing the > iteration > > >yourself. > > > > > >Look for a patch for Array Interface sometime within the next two > months. > > > > > >It would be great if you could do some testing with it as well > > > > > >Cheers. > > >John Scoles > > > > > >- Original Message - > > >From: "Shreedhar Natarajan" <[EMAIL PROTECTED]> > > >To: > > >Sent: Monday, May 29, 2006 9:25 AM > > >Subject: oracle array interface > > > > > > > > > > Hi, > > > > > > > > I saw on the web that the Oracle array interface has not been > implemented > > > > properly. I am new to DBI. Has the implementation been made more > > >efficient? > > > > > > > > Thanks, > > > > Shree > > > > > > > > > > > > > -- Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBI - where has dbish and DBD::Shell.pm gone
It is a seperate product, that gets installed by Bundle::DBI. I'm
pretty sure :-)
On Wed, 2006-05-10 at 15:08 +0200, H.Merijn Brand wrote:
> The docs state nothing about it being gone, nor does the changelist
> The Docs however still refer to it:
>
> /pro/3gl/CPAN/DBI-1.50 113 > grep -w -r dbish .
> ./Changes: Added DBD::Shell and dbish interactive DBI shell. Try it!
> ./lib/DBI/FAQ.pm:dbish -- The DBI Shell
> ./lib/DBI/ProxyServer.pm:Call a programm "dbish" from your commandline. I
> take the machine from rule "internal_webserver"
> ./lib/DBI/ProxyServer.pm: dbish
> "dbi:Proxy:hostname=oracle.zdf;port=12400;dsn=dbi:Oracle:e01" informationdesk
> xxx
> ./lib/DBI/ProxyServer.pm:=item * I don't know how to pass query-parameters
> via dbish
> ./ToDo:dbish - state AutoCommit status clearly at connect time.
> ./blib/lib/DBI/Changes.pm: Added DBD::Shell and dbish interactive DBI shell.
> Try it!
> ./blib/lib/DBI/FAQ.pm:dbish -- The DBI Shell
> ./blib/lib/DBI/ProxyServer.pm:Call a programm "dbish" from your commandline.
> I take the machine from rule "internal_webserver"
> ./blib/lib/DBI/ProxyServer.pm: dbish
> "dbi:Proxy:hostname=oracle.zdf;port=12400;dsn=dbi:Oracle:e01" informationdesk
> xxx
> ./blib/lib/DBI/ProxyServer.pm:=item * I don't know how to pass
> query-parameters via dbish
> ./blib/man3/DBI::FAQ.3:\&dbish -- The DBI Shell
> ./blib/man3/DBI::ProxyServer.3:Call a programm \*(L"dbish\*(R" from your
> commandline. I take the machine from rule \*(L"internal_webserver\*(R"
> ./blib/man3/DBI::ProxyServer.3:\&dbish
> "dbi:Proxy:hostname=oracle.zdf;port=12400;dsn=dbi:Oracle:e01" informationdesk
> xxx
> ./blib/man3/DBI::ProxyServer.3:.IP "* I don't know how to pass
> query-parameters via dbish" 4
> ./blib/man3/DBI::ProxyServer.3:.IX Item "I don't know how to pass
> query-parameters via dbish"
> /pro/3gl/CPAN/DBI-1.50 114 >
>
> I do not have DBI-1.33, but DBI-1.32 still had it, and DBI-1.34 was the first
> to miss it. The changelog for 1.34 states:
>
> Removed old DBI::Shell from distribution and added Tom Lowery's improved
> version to the Bundle::DBI file.
>
> But *is* is better? Last update was back in 2003, and it now requires other
> modules that did not used to be required when still bundled:
>
> /pro/3gl/CPAN/DBI-Shell-11.93 114 > perl Makefile.PL
> Checking if your kit is complete...
> Looks good
> Warning: prerequisite IO::Tee 0 not found.
> Warning: prerequisite Text::Reform 0 not found.
> Writing Makefile for DBI::Shell
>
> OK, I've changed the tests, so optional modules are not `required' anymore,
> but optional, and then the docs say:
>
> =head1 SYNOPSIS
>
> perl -MDBI::Shell -e shell [ [ []]]
>
> or
>
> dbish [ [ []]]
> dbish --debug [ [ []]]
> dbish --batch [ [ []]] < batch file
>
> Right, so
>
> bev l1:/pro/3gl/CPAN/DBI-Shell-11.93 121 > dbish --debug dbi:Unify: "" PROBEV
> DBI::Shell 11.93 using DBI 1.50
> Unrecognised options: --debug
> Exit 2
>
> OK ... (read the DBD::Unify documentation to see why
> the user is "", and the pass is the SCHEMA-name)
>
> bev l1:/pro/3gl/CPAN/DBI-Shell-11.93 119 > dbish dbi:Unify "" PROBEV
> DBI::Shell 11.93 using DBI 1.50
>
> WARNING: The DBI::Shell interface and functionality are
> === very likely to change in subsequent versions!
>
>
>
> Enter data source to connect to:
> 1:
> Enter data source or number, or full 'dbi:...:...' DSN: 1
>
> (not connected)>
>
> Grrr.
> $sh->{user} = shift(@args) || $ENV{DBI_USER} || '';
> $sh->{password} = shift(@args) || $ENV{DBI_PASS} || undef;
>
> and later:
> if (defined $user and length $user) {
> $sh->{user} = $user;
> $sh->{password} = undef;# force prompt below
> }
>
> dbish does not allow "" as user.
>
> bev l1:/pro/3gl/CPAN/DBI-Shell-11.93 123 > dbish dbi:Unify: "x" PROBEV
> DBI::Shell 11.93 using DBI 1.50
>
> WARNING: The DBI::Shell interface and functionality are
> === very likely to change in subsequent versions!
>
>
> Connecting to 'dbi:Unify:' as 'x'...
> [EMAIL PROTECTED]:Unify:> help
> [EMAIL PROTECTED]:Unify:> ;
> DBD::Unify::db prepare failed: Statement cannot be prepared., line 2.
> [EMAIL PROTECTED]:Unify:> help;
> DBD::Unify::db prepare failed: Statement cannot be prepared., line 3.
> [EMAIL PROTECTED]:Unify:>
>
> Now I entered a Ctrl-D
>
> [EMAIL PROTECTED]:Unify:> Disconnecting from dbi:Unify:.
> Segmentation fault (core dumped)
> Exit 139
> bev l1:/pro/3gl/CPAN/DBI-Shell-11.93 124 >
>
> I give up. dbish is not up to the greatness of DBI
> I suggest documenting in DBI that there is no more dbish
>
--
Scott T. Hildreth <[EMAIL PROTECTED]>
Re: DBD::Oracle & 10.1 client
To add more info, I was told this problem only occurs if there is only
one row returned. If more than one row is returned, the arrayref is
fine. I changed the selectall_arrayref to selectrow_array and the data
(one row returned) was fine. I'm posting to dev as well, just in case
this is a known bug. I copied the table to a 9i instance and the ran
the code below, and it worked fine. So it seems to be related to 10g.
Thu, 2005-10-20 at 14:07 -0500, Scott T. Hildreth wrote:
> I am going to investigate more, but I thought I would post the question
> to see if anyone has run into this problem.
>
> I have co-workers that connecting to a remote Oracle DB (10.1), I
> compiled DBD::Oracle 1.16 with the 10.1 client libraries. The data
> returned from a selectall_arrayref is 2 fields a filename and a
> quantity. Here is the isolated code,
>
> 286:my $load_file_ar = $dbh->selectall_arrayref(q{
> 287 select FILENAME, NUM_RECORDS
> 288 from LOAD_DATA_SRC_FILE
> 289 where LOAD_ID = ?
> 290and DATA_UPDATE_ID = ?
> 291 order by FILE_ID
> 292 }, undef, $load_id, $update_id);
>
> $load_id = 19 & $update_id = 51.
>
> ...here is the data returned.
>
> DB<4> x $files_ar
> 0 ARRAY(0x8536328)
>0 ARRAY(0x85e40e0)
> 0 (binary data)
> 1 51
>
> what ever $update_id's value is, this is always returned in the [1] position
> of the the arrayref and the filename is always binary data. This works fine
> with sqlplus.
>
> I have tried it with Perl 5.8.[167] always the same results. The database
> resides on an Alpha and the clients are on Linux. Trace doesn't show anything
> unusual. I don't know if this is an NLS-utf8 issue. Any ideas?
>
> Thanks,
> STH
>
> Trace- level 9 is attached.
>
--
Scott T. Hildreth <[EMAIL PROTECTED]>
Re: Named bind params with DBD::Proxy
Tim,
Are you still maintaining DBD::Proxy? Have you had a request for
supporting named parameters?
STH
On Thu, 2004-10-21 at 16:55, Scott T. Hildreth wrote:
> I was going bring this up myself. I had this problem the other day.
> To get it working I changed the param names to :p1, :p2, ...etc and
> used $sth->bind_param(1, 'foo'). For the return param I had to use the
> a :p? as well,
>
> i.e.
>
> my $sth = $dbh->prepare(q{
>BEGIN
>:p3 = some_pkg(:p1, :p2)
>END;
>});
>
> $sth->bind_param(1, 'foo');
> $sth->bind_param(2, 'bar');
>
> $sth->bind_param_inout(3, \$var, 10);
>
> I was considering trying to change DBD::Proxy to use named parameters.
> We use DBD::Proxy quite a bit. I didn't know if someone else is
> working on it already, so I guess I am asking now?
>
>STH
>
> On Thu, 2004-10-21 at 16:34, Steve Baldwin wrote:
> > We make extensive use of named bind params in our apps (our DB is Oracle).
> > I just tried running a test program over DBD::Proxy and found it barfs on
> > these. Here is the code in DBD::Proxy that doesn't like them .
> >
> >
> >
> > sub bind_param ($$$@) {
> >
> > my $sth = shift; my $param = shift;
> >
> > $sth->{'proxy_params'}->[$param-1] = [EMAIL PROTECTED];
> >
> > }
> >
> >
> >
> > Doing a google search on this turned up some pretty old stuff - e.g.
> >
> >
> >
> > http://www.grin.net/~mirthles/pile/dbi-tim_bunce_call_on_proxy_module_with_o
> > racle_bind_param.html
> >
> >
> >
> > Does anyone know whether a fix to DBD::Proxy is planned?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Steve
> >
Re: ORA-12154
This should be on the dbi-users list. Are you sure all of the
environment variables are set? Can you show the code? The
ORA-12154 is TNS error,
12154, 0, "TNS:could not resolve service name"
// *Cause: The service name specified is not defined correctly in the
// TNSNAMES.ORA file.
// *Action: Make the following checks and correct the error:
// - Verify that a TNSNAMES.ORA file exists and is in the
proper
// place and accessible. See the operating system specific
manual
// for details on the required name and location.
// - Check to see that the service name exists in one of the
// TNSNAMES.ORA files and add it if necessary.
// - Make sure there are no syntax errors anywhere in the
file.
// Particularly look for unmatched parentheses or stray
characters.
// Any error in a TNSNAMES.ORA file makes it unusable. See
// Chapter 4 in the SQL*Net V2 Administrator's Guide. If
// possible, regenerate the configuration files using the
Oracle
// Network Manager.
...in other words it doesn't know the db you are trying to connect to,
which means the ORACLE_SID is not set or it is wrong in your connect
statement. Posting the code would help.
On Tue, 2004-08-03 at 15:51, Robert wrote:
> Hi list
> Command line script test2-cgi works fine but when I try from the browser it is
> giving the following error
>
> DBI connect('db1','report',...) failed: Error while trying to retrieve text for
> error ORA-12154 (DBD ERROR: OCIServerAttach) at /home/report/www/cgi-bin/test2-cgi
> line 72
>
> I have complete ORACLE environment set, I can connect using sqlplus and also can run
> tnsping the database without any issues at command prompt.
>
> Anyone know how to fix this issue?.
>
> Thanks in advance
>
>
[Fwd: DBD::Proxy & Setting DBH attributes.]
Sorry, I know this belongs on dbi-users, but I've posted twice and it
is not showing up. I wanted to see if I can post to dbi-dev.
-Forwarded Message-
> From: Scott T. Hildreth <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Subject: DBD::Proxy & Setting DBH attributes.
> Date: Tue, 20 Jul 2004 16:39:21 -0500
>
> I am asking a question, that I'm pretty sure I know the answer to, but
> just in case I am missing something,
>
> The following example code works,
>
> use DBI;
>
> my $dbh = DBI->connect('dbi:Oracle:sid', 'user', 'password', {});
>
> $dbh->{FetchHashKeyName} = 'NAME_lc';
>
> my $res = $dbh->selectall_hashref(q{
> Select id, name, sum
> From foo
> }, 'id');
>
> ...if I use DBD::PROXY the setting of 'FetchHashKeyName' does not work.
>
> I did see this in DBD::Proxy perldocs,
>
> KNOWN ISSUES
>Complex handle attributes
>
>Sometimes handles are having complex attributes like hash refs or
> array
>refs and not simple strings or integers. For example, with
> DBD::CSV,
>you would like to write something like
>
> $dbh->{"csv_tables"}->{"passwd"} =
>{ "sep_char" => ":", "eol" => "\n";
>
>
> ...but I did not think that FetchHashKeyName is a complex attribute..
>
> Am I missing something(probably)?
>
> Thanks,
>
>STH
RE: ANNOUNCE: DBI 1.42 release candidate 4 for testing
http://lists.perl.org/showlist.cgi?name=dbi-dev On Fri, 2004-03-12 at 11:05, Lance Prais wrote: > How do I get removed from this list? > > I am so tired of seeing 30- messages in my inbox from Tim Bruce.. > > Please help > > -Original Message----- > From: Scott T. Hildreth [mailto:[EMAIL PROTECTED] > Sent: Friday, March 12, 2004 9:06 AM > To: Tim Bunce > Cc: [EMAIL PROTECTED] > Subject: Re: ANNOUNCE: DBI 1.42 release candidate 4 for testing > > All test pass, FreeBSD 4.9 perl 5.8.1 > > On Fri, 2004-03-12 at 07:21, Tim Bunce wrote: > > On Fri, Mar 12, 2004 at 12:01:55AM +, Tim Bunce wrote: > > > On Thu, Mar 11, 2004 at 04:26:40PM +, Tim Bunce wrote: > > > > A release candidate is available for testing at: > > > And another: > > > > And another: > > > > http://homepage.eircom.net/~timbunce/DBI-1.42-rc4-20040312.tar.gz > > > > > I hope this is the last release candidate (knowing full well that > > > by saying that I'm tempting fate :) > > > > I won't say that this time :) > > > > I've changed the t/50dbm.t test to only use SDBM_File by default. > > > > If I don't hear any bad news about this one soonish I'll probably > > do a release over the weekend. > > > > Tim.
Re: ANNOUNCE: DBI 1.42 release candidate 4 for testing
All test pass, FreeBSD 4.9 perl 5.8.1 On Fri, 2004-03-12 at 07:21, Tim Bunce wrote: > On Fri, Mar 12, 2004 at 12:01:55AM +, Tim Bunce wrote: > > On Thu, Mar 11, 2004 at 04:26:40PM +, Tim Bunce wrote: > > > A release candidate is available for testing at: > > And another: > > And another: > > http://homepage.eircom.net/~timbunce/DBI-1.42-rc4-20040312.tar.gz > > > I hope this is the last release candidate (knowing full well that > > by saying that I'm tempting fate :) > > I won't say that this time :) > > I've changed the t/50dbm.t test to only use SDBM_File by default. > > If I don't hear any bad news about this one soonish I'll probably > do a release over the weekend. > > Tim.
Re: ANNOUNCE: DBI 1.42 release candidate 2 for testing
David, I have had similar problems with FreeBSD, Linux, and OSF. http://www.perlmonks.org/index.pl?node_id=323847 what ended up doing is renaming the site_perl/5.6.1 directory to a temp name, while I upgraded to 5.8.*. Once everything was installed under 5.8.*, moved the 5.6.1 directory back. I know this is a hack around, but I have not had time to figure out what is going on. Not totally related, just thought I would mention it. On Thu, 2004-03-11 at 11:01, David Wheeler wrote: > On Mar 11, 2004, at 8:56 AM, David Wheeler wrote: > > > t/50dbmParameterless "use IO" deprecated at > > /usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/BerkeleyDB.pm line > > 24 > > t/50dbmok 132/132Undefined subroutine > > &BerkeleyDB::Term::close_everything called at > > /usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/BerkeleyDB.pm line > > 1388, line 23. > > Now I'm _really_ confused: > > % locate BerkeleyDB.pm > /usr/local/lib/perl5/site_perl/5.6.1/i386-freebsd/BerkeleyDB.pm > > > BerkeleyDB _is_ in the i386-freebsd directory. Perl 5.8.2 can't even > find it: > > sahlins% perl -MBerkeleyDB -le 'print BerkelyDB->VERSION' > Can't locate BerkeleyDB.pm in @INC (@INC contains: > /usr/local/lib/perl5/5.8.2/i386-freebsd /usr/local/lib/perl5/5.8.2 > /usr/local/lib/perl5/site_perl/5.8.2/i386-freebsd > /usr/local/lib/perl5/site_perl/5.8.2 > /usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd > /usr/local/lib/perl5/site_perl/5.8.0 > /usr/local/lib/perl5/site_perl/5.6.1 > /usr/local/lib/perl5/site_perl/5.005 /usr/local/lib/perl5/site_perl .). > BEGIN failed--compilation aborted. > > Here's an easier-to-read list of @INCs: > >@INC: > /usr/local/lib/perl5/5.8.2/i386-freebsd > /usr/local/lib/perl5/5.8.2 > /usr/local/lib/perl5/site_perl/5.8.2/i386-freebsd > /usr/local/lib/perl5/site_perl/5.8.2 > /usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd > /usr/local/lib/perl5/site_perl/5.8.0 > /usr/local/lib/perl5/site_perl/5.6.1 > /usr/local/lib/perl5/site_perl/5.005 > /usr/local/lib/perl5/site_perl > . > > So how the _hell_ are the DBI tests finding it??? > > Sorry for this mess. > > Regards, > > David
Re: ANNOUNCE: DBI 1.42 release candidate 2 for testing
FreeBSD 4.9, perl 5.8.1 - all test pass.
FreeBSD 4.9, perl 5.8.3 - all test pass.
I logged into my server at home, which has 5.6.1 installed,
I did a make test and it hangs until it uses all the memory/swap unless
I kill it,
t/01basics.ok 45/47^C
..just like described in the link below. As soon as I rename the
site_perl/5.6.1 dir, the make test works fine.
On Thu, 2004-03-11 at 10:26, Tim Bunce wrote:
> A release candidate is available for testing at:
>
> http://homepage.eircom.net/~timbunce/DBI-1.42-rc2-20040311.tar.gz
>
> =head1 CHANGES in DBI 1.42 (svn rev 218),11th March 2004
>
> Fixed $sth->{NUM_OF_FIELDS} of non-executed statement handle
> to be undef as per the docs (it was 0).
> Fixed t/41prof_dump.t to work with perl5.9.1.
> Fixed DBD_ATTRIB_DELETE macro thanks to Marco Paskamp.
> Fixed DBI::PurePerl looks_like_number() and $DBI::rows.
> Fixed ref($h)->can("foo") to not croak.
>
> Changed attributes (NAME, TYPE etc) of non-executed statement
> handle to be undef instead of triggering an error.
> Changed ShowErrorStatement to apply to more $dbh methods.
> Changed DBI_TRACE env var so just does this at load time:
> DBI->trace(split '=', $ENV{DBI_TRACE}, 2);
> Improved "invalid number of parameters" error message.
> Added DBI::common as base class for DBI::db, DBD::st etc.
> Moved methods common to all handles into DBI::common.
>
> Major tracing enhancement:
>
> Added $h->parse_trace_flags("foo|SQL|7") to map a group of
> trace flags into the corresponding trace flag bits.
> Added automatic calling of parse_trace_flags() if
> setting the trace level to a non-numeric value:
> $h->{TraceLevel}="foo|SQL|7"; $h->trace("foo|SQL|7");
> DBI->connect("dbi:Driver(TraceLevel=SQL|foo):...", ...);
> Currently no trace flags have been defined.
> Added to, and reworked, the trace documentation.
> Added dbivport.h for driver authors to use.
>
> Major driver additions that Jeff Zucker and I have been working on:
>
> Added DBI::SQL::Nano a 'smaller than micro' SQL parser
> with an SQL::Statement compatible API. If SQL::Statement
> is installed then DBI::SQL::Nano becomes an empty subclass
> of SQL::Statement, unless the DBI_SQL_NANO env var is true.
> Added DBD::File, modified to use DBI::SQL::Nano.
> Added DBD::DBM, an SQL interface to DBM files using DBD::File.
>
> Documentation changes:
>
> Corrected typos in docs thanks to Steffen Goeldner.
> Corrected execute_for_fetch example thanks to Dean Arnold.
>
> =cut
>
> Testing on a range of platforms, perl configs AND ESPECIALLY DRIVERS
> would be appreciated.
>
> I'd also like driver authors to consider/try-out the new
> - dbvport.h mechanism (see DBI::DBD docs)
> - The DBIc_TRACE_LEVEL(imp_xxh) macro
> - DBIc_SET_ERR_* macros
> - Recording 'success with info' (incl db messages etc) and 'warnings'
> - bind_param() TYPE attribute specification
> - bind_col() TYPE attribute specification
>
> Thanks!
>
> Tim.
Re: Quoted Identiers - problem in DBD::ODBC 0.32
>> INSERT INTO somedb:{comment}table
>> VALUES{}({comment}SET{{comment}1{},{}2{}}OF{}INT{}){};
>>
>> Given that braces enclose comments (but, for example, C-style comments
>> are just a syntax error), it is immediately obvious that SET (and
>> MULTISET and LIST) followed by braces does not mark a comment after all,
>> but a constructor for a SET of INT. Of course, you can use the SQL
>> standard --to-end-of-line comment style between the SET and the opening
>> brace of the constructor. Ugh! You really do not want to mess with
>> this -- I sure as hell don't either, but I'm stuck with it. I have to
>> damn well pre-parse the SQL since I can't get a decent count of the
>> input parameters back from Informix.
>
> I'd appreciate it if, at some point, you could look at the evolving
> preparse() code in DBI.xs and see how it can be extended to cover
> your needs. Don't rush though as preparse() is currently a fairly
> slowly moving target and has a way to go yet before it's ready for
> drivers to use.
..and the code that is in current DBI has changed quite a bit.
--
E-Mail: Scott T. Hildreth <[EMAIL PROTECTED]>
Date: 05-Feb-02
Time: 08:36:46
--
Re: SQL Implementation Specifics
On 25-Jan-02 Jeff Zucker wrote: > Tim Bunce wrote: >> >> p.s. Of course the SQL standards team should be ashamed of creating >> a syntax that risks breakage with things like: >> "update foo set bar=bar-$value" >> (If you can't see it, consider what happens if $value is negative." > > Good point. How will the preparser handle this? It will presumably have > to turn double minus style comments into C-style comments -- It will turn them into what is acceptable. The driver will tell DBI what to translate or leave as a comment style. There is 2 styles for '--', '--' & '-- '(dash dash white space). and therefore > will have to decide if any given double minus sign occuring in a string > is a comment or a minus operator applied to a negative number. I would > guess the best way is to treat "--X", where X is a positive number, as > part of a statement and all other double minuses as comment introducers. I did bring this idea up, Tim thought it was an interesting one yet somehow it was not...wait let me look for his email. okay found it, >Would it be to far fetched to parse '--(digits) ' as not a comment? Interesting but still a fudge. The right fix is to support both DBIpp_cm_dd & DBIpp_cm_dw. ...I don't know what to think. If you are using Oracle(for example) the user has to know that if they have an expression that is '6--5' the '5' will be treated as a comment. I personally would always write the expressions with space in them, 6 - -5, beacause I know Oracle treats -- as a comment. Mysql only allows '-- ' for dash-dash style comments. But to answer your question, currently the preparser will treat '--' as comment and it will return what ever the driver indicates is acceptable. STH -- E-Mail: Scott T. Hildreth <[EMAIL PROTECTED]> Date: 25-Jan-02 Time: 12:59:39 --
