Re: Re: Column names have spaces in them!!!
use backticks instead of double quotes:
my $sth=$dbh->prepare('select * from taskhours_per_date where `employee
name`=?');
Regards,
Renee
Am 31.01.2006 um 23:58 Uhr haben Sie geschrieben:
> Alexander Foken wrote:
> > You need to pass the quotes to the SQL engine. And by the way, you
> > should either use parameters or the quote function for values:
> >
> > my $sth=$dbh->prepare('select * from taskhours_per_date where
"employee
> > name"=?');
> > $sth->execute('NAME HERE');
> >
> > Maybe MS Acesss has other ways to do this, especially old Access
> > versions have some very strange behaviours.
> >
> > Alexander
>
> Could it be that DBD::ODBC just cannot handle it? I tried it that way,
I
> tried it with brackets, backticks, double quotes, etc. and no go.
>
> I was hoping just to slap a small web frontend to it but I guess I
will
> go the heavier route and move it over into Oracle using my own schema.
>
> Thanks for the replies.
>
> Robert
>
>
>
Re: Column names have spaces in them!!!
Alexander Foken wrote:
You need to pass the quotes to the SQL engine. And by the way, you
should either use parameters or the quote function for values:
my $sth=$dbh->prepare('select * from taskhours_per_date where "employee
name"=?');
$sth->execute('NAME HERE');
Maybe MS Acesss has other ways to do this, especially old Access
versions have some very strange behaviours.
Alexander
Could it be that DBD::ODBC just cannot handle it? I tried it that way, I
tried it with brackets, backticks, double quotes, etc. and no go.
I was hoping just to slap a small web frontend to it but I guess I will
go the heavier route and move it over into Oracle using my own schema.
Thanks for the replies.
Robert
Re: DBD::Oracle / Instant Client segfaults
On Sat, Jan 28, 2006 at 09:48:17PM +0200, Marko Asplund wrote: > hi > > I've been doing some more tests concerning this issue and it seems > that it only appears with the combination of Oracle Instant client > libraries, Perl configured with -Dusemymalloc on RHEL 3. When I > configure Perl without -Dusemymalloc everything works fine. By which I presume you mean it appears to work fine because it doesn't segfault. An underlying problem, such as memory corruption, may still be present, just not causing any visible problem in you application. (Sorry to be pessimistic.) There are memory allocation debugging tools that may help to isolate the original problem and so give some confidence that it's not present in the other configurations. > The issue doesn't appear with Oracle10g full client on RHEL 3 or with > OIC on RHEL 4, Solaris 8 or HP-UX 11i v1. Thanks for doing the legwork to narrow it down. > I've reported this issue to Oracle but does anyone have clues on what > is causing this or suggestions on how to get this fixed on the Perl > side? I'd really need to use -Dusemymalloc and Oracle Instant Client. Why? The Perl -DPERL_POLLUTE_MALLOC option may be of use. But you might just be trading one can of worms for another. Also, try http://www.data-plan.com/public/DBD-Oracle-1.17-RC6.tar.gz I don't think there are any relevant changes but I'd be interested to know if you get similar behaviour on the various systems. Tim.
Re: need DBD-DB2.ppd, DBI.ppd from www.esoftmatic.com, but server is unreachable.
Seems to be working now for me: http://ftp.esoftmatic.com/outgoing/DBI/ Dan On 31-Jan-2006 10:09:34 CET, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hello, > > I need DBI and DBD-DB2 packages for Activeperl, but esoftmatic server is > unreachable. > > Can anybody help me with this problem or send me this files? > > Thanks for any help. > > Kind Regards > > Denis Baumgaertner > System and Network Consultant > __ > SPIRIT/21 AG > Otto-Lilienthal-Strasse 36 > > 71034 Böblingen > > phone: +49 7031 / 714 96 00 > fax: +49 7031 / 714 96 99 > mailto: [EMAIL PROTECTED] > internet: http://www.spirit21.de > >
mod_perl2 DBI handle freshining problem solved "once and for all"...
Apache::DBI and DBI's connect_cached both claim to keep your database
handles fresh and happy, but I've had numerous problems trying to get either
of them to work properly. If a database connection is dropped, sometimes I'd
have to refresh the page two or three times before the "internal server
error" goes away and my webpages are happily reconnected to the database
again.
Part of the problem seems to be that disconnecting a database handle doesn't
always remove it from {CachedKids}. At least, in the case where DBI thinks
it's already disconnected, it doesnt bother removing it.
Anyways, here's what I've done to solve the problem (i'm using postgres):
- always use connect_cached, don't use Apache::DBI
- use this as my PerlPostConfigHandler:
sub PostConfig {
my $drh = DBI->driver("Pg");
my $n = 0;
while(my($k, $v) = each(%{$drh->{CachedKids}})) {
eval { $v->disconnect if $v->{Active} };
delete $drh->{CachedKids}->{$k};
$n++;
}
warn "$$: Cleared $n postgresql database handles before forking.\n" if $n;
return DECLINE_CMD;
}
- use this as my PerlPreConnectionHandler:
sub DisconnectDead {
my $drh = DBI->driver("Pg");
my $n = 0;
while(my($k, $v) = each(%{$drh->{CachedKids}})) {
if(! eval { $v->ping }) {
eval { $v->disconnect if $v->{Active} };
delete $drh->{CachedKids}->{$k};
$n++;
}
}
warn "$$: Cleared $n stale postgresql database handle(s).\n" if $n;
return DECLINE_CMD;
}
This seems reasonably robust, after doing something like:
# ps ax | grep "postmaster: pmx" | grep -v grep | awk '{print $1}' | xargs kill
The first reload is a bit sluggish, but always works.
Cheers,
Tyler
trouble loading DBD::Sybase 1.05 on tiger, MacOSX 10.4.4
Hi, I had trouble loading DBD::Sybase on MacOSx 10.4.4.. Any ideas boehme:~/DBD-Sybase-1.05_02 boehme$ perl Makefile.PL Sybase OpenClient 12.5.1 ASE Edition found. By default DBD::Sybase 1.05 and later use the 'CHAINED' mode (where available) when 'AutoCommit' is turned off. Versions 1.04 and older instead managed the transactions explicitly with a 'BEGIN TRAN' before the first DML statement. Using the 'CHAINED' mode is preferable as it is the way that Sybase implements AutoCommit handling for both its ODBC and JDBC drivers. Use 'CHAINED' mode by default (Y/N) [Y]: n Running in threaded mode - looking for _r libraries... Found -lsybct_r for -lsybct Found -lsybcs_r for -lsybcs Found -lsybtcl_r for -lsybtcl Found -lsybcomn_r for -lsybcomn Found -lsybintl_r for -lsybintl Found -lsybblk_r for -lsybblk Found -lsybsrv_r for -lsybsrv The DBD::Sybase module need access to a Sybase server to run the tests. To clear an entry please enter 'undef' Sybase server to use (default: SYBASE): tatung User ID to log in to Sybase (default: sa): ^C boehme:~/DBD-Sybase-1.05_02 boehme$ perl Makefile.PL Sybase OpenClient 12.5.1 ASE Edition found. By default DBD::Sybase 1.05 and later use the 'CHAINED' mode (where available) when 'AutoCommit' is turned off. Versions 1.04 and older instead managed the transactions explicitly with a 'BEGIN TRAN' before the first DML statement. Using the 'CHAINED' mode is preferable as it is the way that Sybase implements AutoCommit handling for both its ODBC and JDBC drivers. Use 'CHAINED' mode by default (Y/N) [Y]: n Running in threaded mode - looking for _r libraries... Found -lsybct_r for -lsybct Found -lsybcs_r for -lsybcs Found -lsybtcl_r for -lsybtcl Found -lsybcomn_r for -lsybcomn Found -lsybintl_r for -lsybintl Found -lsybblk_r for -lsybblk Found -lsybsrv_r for -lsybsrv The DBD::Sybase module need access to a Sybase server to run the tests. To clear an entry please enter 'undef' Sybase server to use (default: SYBASE): TATUNG User ID to log in to Sybase (default: sa): sa Password (default: undef): redpill Sybase database to use on TATUNG (default: undef): test * Writing login information, including password, to file PWD. Checking if your kit is complete... Looks good Using DBI 1.48 (for perl 5.008006 on darwin-thread-multi-2level) installed in /Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DBI/ Writing Makefile for DBD::Sybase boehme:~/DBD-Sybase-1.05_02 boehme$ make cp dbd-sybase.pod blib/lib/DBD/dbd-sybase.pod cp Sybase.pm blib/lib/DBD/Sybase.pm /usr/bin/perl -p -e "s/~DRIVER~/Sybase/g" /Library/Perl/5.8.6/darwin- thread-multi-2level/auto/DBI//Driver.xst > Sybase.xsi /usr/bin/perl /System/Library/Perl/5.8.6/ExtUtils/xsubpp -typemap / System/Library/Perl/5.8.6/ExtUtils/typemap Sybase.xs > Sybase.xsc && mv Sybase.xsc Sybase.c cc -c -I/Applications/Sybase/System/OCS-12_5/include - DNO_CHAINED_TRAN=1 -I/Library/Perl/5.8.6/darwin-thread-multi-2level/ auto/DBI -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno- strict-aliasing -I/usr/local/include -Os -DVERSION=\"1.05_02\" - DXS_VERSION=\"1.05_02\" "-I/System/Library/Perl/5.8.6/darwin-thread- multi-2level/CORE" Sybase.c cc -c -I/Applications/Sybase/System/OCS-12_5/include - DNO_CHAINED_TRAN=1 -I/Library/Perl/5.8.6/darwin-thread-multi-2level/ auto/DBI -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno- strict-aliasing -I/usr/local/include -Os -DVERSION=\"1.05_02\" - DXS_VERSION=\"1.05_02\" "-I/System/Library/Perl/5.8.6/darwin-thread- multi-2level/CORE" dbdimp.c dbdimp.c: In function '_dbd_rebind_ph': dbdimp.c:4764: warning: passing argument 2 of 'to_binary' from incompatible pointer type Running Mkbootstrap for DBD::Sybase () chmod 644 Sybase.bs rm -f blib/arch/auto/DBD/Sybase/Sybase.bundle LD_RUN_PATH="" env MACOSX_DEPLOYMENT_TARGET=10.3 cc -L/Applications/ Sybase/System/OCS-12_5/lib -bundle -undefined dynamic_lookup -L/usr/ local/lib Sybase.o dbdimp.o -o blib/arch/auto/DBD/Sybase/ Sybase.bundle -L/Applications/Sybase/System/OCS-12_5/lib -lsybct_r - lsybcs_r -lsybtcl_r -lsybcomn_r -lsybintl_r -lsybblk_r -lsybsrv_r - ldl -lm /usr/bin/ld: warning multiple definitions of symbol _dlclose /Applications/Sybase/System/OCS-12_5/lib/libsybtcl_r.a(dlopen.o) definition of _dlclose in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/../../../libdl.dylib (dyldAPIsInLibSystem.o) definition of _dlclose /usr/bin/ld: warning multiple definitions of symbol _dlerror /Applications/Sybase/System/OCS-12_5/lib/libsybtcl_r.a(dlopen.o) definition of _dlerror in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/../../../libdl.dylib (dyldAPIsInLibSystem.o) definition of _dlerror /usr/bin/ld: warning multiple definitions of symbol _dlopen /Applications/Sybase/System/OCS-12_5/lib/libsybtcl_r.a(dlopen.o) definition of _dlopen in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/../../../libdl.dylib (dyldAPIsInLibSystem.o) definition of _dl
Re: Column names have spaces in them!!!
Ugg!!
first coice is to rebuild the table
second choice
I found that wrapping the offending field name in [ ] worked with ODBC and
OLE but I am not sure how this will workd with DBI?
something like this
SELECT * FROM taskhours_per_date WHERE [EMPLOYEE NAME] = 'NAME HERE'
might work
option three
Create a number of select querries on the access DB without the the spaces,
Been years since I did this but I remember it was a very messy solution and
slow.
- Original Message -
From: "Robert Hicks" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, January 31, 2006 11:27 AM
Subject: Column names have spaces in them!!!
> I am using the ODBC module to talk to an Access database. In that
> database some of the column names have spaces in them (something like
> EMPLOYEE NAME).
>
> I have tried a bunch of stuff (backticking, brackets, braces, variables)
> but I cannot seem to do a select on that table.
>
> my $sth = $dbh->prepare("SELECT * FROM taskhours_per_date WHERE
> `EMPLOYEE NAME` = 'NAME HERE'" );
>
> How do I use a column name with spaces in it?!
>
> I cannot change the table name itself.
>
> Robert
>
Re: Column names have spaces in them!!!
You need to pass the quotes to the SQL engine. And by the way, you
should either use parameters or the quote function for values:
my $sth=$dbh->prepare('select * from taskhours_per_date where "employee
name"=?');
$sth->execute('NAME HERE');
Maybe MS Acesss has other ways to do this, especially old Access
versions have some very strange behaviours.
Alexander
Robert Hicks wrote:
I am using the ODBC module to talk to an Access database. In that
database some of the column names have spaces in them (something like
EMPLOYEE NAME).
I have tried a bunch of stuff (backticking, brackets, braces,
variables) but I cannot seem to do a select on that table.
my $sth = $dbh->prepare("SELECT * FROM taskhours_per_date WHERE
`EMPLOYEE NAME` = 'NAME HERE'" );
How do I use a column name with spaces in it?!
I cannot change the table name itself.
Robert
--
Alexander Foken
mailto:[EMAIL PROTECTED] http://www.foken.de/alexander/
Re: Column names have spaces in them!!!
I believe you want square-brackets for Access:
my $sth = $dbh->prepare("SELECT * FROM taskhours_per_date WHERE [EMPLOYEE NAME]
= ?");
Paul
Quoting Robert Hicks <[EMAIL PROTECTED]>:
> I am using the ODBC module to talk to an Access database. In that
> database some of the column names have spaces in them (something like
> EMPLOYEE NAME).
>
> I have tried a bunch of stuff (backticking, brackets, braces, variables)
> but I cannot seem to do a select on that table.
>
> my $sth = $dbh->prepare("SELECT * FROM taskhours_per_date WHERE
> `EMPLOYEE NAME` = 'NAME HERE'" );
>
> How do I use a column name with spaces in it?!
>
> I cannot change the table name itself.
>
> Robert
>
Column names have spaces in them!!!
I am using the ODBC module to talk to an Access database. In that
database some of the column names have spaces in them (something like
EMPLOYEE NAME).
I have tried a bunch of stuff (backticking, brackets, braces, variables)
but I cannot seem to do a select on that table.
my $sth = $dbh->prepare("SELECT * FROM taskhours_per_date WHERE
`EMPLOYEE NAME` = 'NAME HERE'" );
How do I use a column name with spaces in it?!
I cannot change the table name itself.
Robert
Re: searching database on emailaddress field
[EMAIL PROTECTED] wrote: Hi. Hello, Solved after I posted. Surround $email with 's. As in '$email'. Close, but this is a gun pointed at your head :) You either need to $dbh->quote() it or do the bind value/placeholder (see `perldoc DBI` for details of both)
Re: Extracting files using DBI
Sham Prasad wrote:
Hi all,
Hello,
I have a bugzilla database running on mysql. If you are aware of
bugzilla, it has a table called "attachments". what i am trying to do
is get the attachments of all the bugs having attachment/s into a
directory.
for example there is a bug with a attachment named abc.zip. can i
extract this file to a directory on my filesystem? as you have
mentioned the files in mysql table are in BLOB fields. i have written
a script but am not able to copy the file to the filesystem instead i
am able to copy the contents which is not readable.
Contents of the script
#!usr/lib/perl
use strict;
use warnings;
use DBI;
my $dbh =
DBI->connect("DBI:mysql:databse=Pbugs;host=appletest","root","deltazia",{'RaiseError"
=> 1});
my $sth = $dbh->prepare(select thedata from attachments where
attach_id=143") or die "can't prepare statement";
print"Query Results\n";
while(my @row = $sth->fetchrow_array()){
print"@row\n";
}
$sth->execute or die "can't execute statement";
$dbh->disconnect;
Note - thedata in the query represents the contents of the file.
the above script prints the contents of the attachment in a binary
form which is nonreadable.
Actually i want the file completely to be copied to the file system.
how can i do it using DBI?
write @row to a file
perldoc -f open
perldoc -f binmode
Re: Future versions of DBI to require perl >= 5.8
On 2006-01-31 09:40:32 +1100, Ron Savage wrote: > On Mon, 30 Jan 2006 12:55:53 +0100, Peter J. Holzer wrote: > > Redhat EL 2.1 perl 5.6.1 supported until May 2009 > > Redhat EL 3 perl 5.8.0 supported until Oct 2010 > > Oh. I didn't know that. Thanx. > > > So, if Tim wants to support those sysadmins who run distributions > > as long as they are supported, he will have to support 5.6.1 for at > > least 3 more years. > > But this begs the question: What's wrong with the current level of support? > > That is, even if DBI is updated, people aren't forced to install the upgrade, > are they? In every case, they /choose/ to upgrade or not, and each course of > action has its own consequences :-). Normally, don't think this is a problem. Machines with an old distribution are usually stable: They have been installed years ago, they are doing their job, and there isn't much reason to change anything except for the occational security or bug fix. So it doesn't matter that DBI 1.51 needs perl 5.8.1 or whatever, because they have already installed DBI 1.18 and they aren't going to upgrade it. There are two exceptions: * Some shops have a "all servers must have the same version of the same OS" policy. So they may have settled on Redhat EL 2.1 when it was new and they will continue to install new servers with Redhat EL 2.1 until 2008, when they will upgrade all servers to RHEL 7 (or whatever will be current then). So for new applications, they may find that they need a recent version of DBD::foo, which in turn needs a newer version of DBI which needs a newer version of perl. * Occationally, a bug or security hole needs to be fixed and backporting the fix to a very old version is too much effort, so the affected software needs to upgraded to the current version: Then you have the same dependency chain as above. I do agree that these problems are the problems of the sysadmins (and occationally the programmer), and should not unduly hinder the development of DBI. I consider it reasonable if a specific version of a perl module requires a version of perl which is not more than 2.5 resp. 3.5 years[0] older than the module itself. So if Tim wants to require perl 5.8.0 or even 5.8.1 for the next release of DBI, I say go ahead! hp [0] perl 5.8.0 was released on 18 July 2002 (hey, that was my 35th birthday :-). perl 5.8.1 was released on 25 Sept 2003. -- _ | Peter J. Holzer| If I wanted to be "academically correct", |_|_) | Sysadmin WSR | I'd be programming in Java. | | | [EMAIL PROTECTED] | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users pgpi9usygV14v.pgp Description: PGP signature
Extracting files using DBI
Hi all,
I have a bugzilla database running on mysql. If you are aware of
bugzilla, it has a table called "attachments". what i am trying to do
is get the attachments of all the bugs having attachment/s into a
directory.
for example there is a bug with a attachment named abc.zip. can i
extract this file to a directory on my filesystem? as you have
mentioned the files in mysql table are in BLOB fields. i have written
a script but am not able to copy the file to the filesystem instead i
am able to copy the contents which is not readable.
Contents of the script
#!usr/lib/perl
use DBI;
my $dbh =
DBI->connect("DBI:mysql:databse=Pbugs;host=appletest","root","deltazia",{'RaiseError"
=> 1});
my $sth = $dbh->prepare(select thedata from attachments where
attach_id=143") or die "can't prepare statement";
print"Query Results\n";
while(my @row = $sth->fetchrow_array()){
print"@row\n";
}
$sth->execute or die "can't execute statement";
$dbh->disconnect;
Note - thedata in the query represents the contents of the file.
the above script prints the contents of the attachment in a binary
form which is nonreadable.
Actually i want the file completely to be copied to the file system.
how can i do it using DBI?
so please can you help me out?
please mail me if you want more details.
Thanking you
sham
Re: DBD::ASAny
I see no replies to this post, so here goes... On Thu, 26 Jan 2006 15:49:09 +0800, nyem wrote: >I'm using DBD::ASAny on my development machine (win2000) but when I >copied them to the production server (win2003) I got this error: > >install_driver(ASAny) failed: Can't load >'H:/perl/site/lib/auto/DBD/ASAny/ASAny >.dll' for module DBD::ASAny: load_file:The specified module >could not be found at >H:/perl/lib/DynaLoader.pm line 206. >Compilation failed in require at (eval 7) line 3. >Perhaps a required shared library or dll isn't installed >where expected > >Does this means that I need to recompile DBD::ASAny for win2003? Or is >there anything else that I forgot to tweak? It's already a hassle to >install msVC just to compile this module on my machine... No, you appear to just need to copy the associated DLL as well. It needs to go under the root "site/lib/auto", and the DLL you need is "DBD/ASAny/ASAny.dll". While youy're there, look around if you see any other files you may need. -- Bart.
Re: Message from Maintainer to DBD::mysql users, developers
On Monday 30 January 2006 02:24 pm, Patrick Galbraith wrote: > Greetings all! > > I apologise for what might seem somewhat of a bit of neglect on my part > to get some features into DBD::mysql, features such as UTF support, some > bugs in 3.0002_4. I've been super busy on some other projects, but have > finished one of them and have today started to go through my mail in > order to start addressing some needs of DBD::mysql. > > I'm wondering if it might help to discuss within this list what > priorities users would like to see addressed in DBD::mysql, so I could > come out with some sort of road map. > > Just some thoughts, and a note to let all of you know that I'm here! > > Kind regards, > > Patrick Galbraith Welcome back! You may want to check out blobs in 3.0002_4. As I posted several weeks ago they don't work (at least for me); 3.0002 is fine. My message had a small test script that demostrated the failure; if you need it, let me know and I will repost. -- Aloha => Beau;
need DBD-DB2.ppd, DBI.ppd from www.esoftmatic.com, but server is unreachable.
Hello, I need DBI and DBD-DB2 packages for Activeperl, but esoftmatic server is unreachable. Can anybody help me with this problem or send me this files? Thanks for any help. Kind Regards Denis Baumgaertner System and Network Consultant __ SPIRIT/21 AG Otto-Lilienthal-Strasse 36 71034 Böblingen phone: +49 7031 / 714 96 00 fax: +49 7031 / 714 96 99 mailto: [EMAIL PROTECTED] internet: http://www.spirit21.de
RE: [dbi] Message from Maintainer to DBD::mysql users, developers
Patrick,
Welcome back.
I posted the email below back in December (I think). I'm not sure my solution
is correct but it seems to work. I've included Tim's followup since it also
seems relevant.
BTW, DBD::mysql does not compile out of the box with a standards C compiler
due to an incorrect #if and a variable being declared in the code. I think I
posted this last issue to one of the mysql lists but the basic change I needed
was:
bash-2.05$ diff -u dbdimp.c /tmp/dbdimp.c.mysql30002_4
--- dbdimp.cSun Nov 6 21:32:01 2005
+++ /tmp/dbdimp.c.mysql30002_4 Wed Dec 14 11:41:25 2005
@@ -260,7 +260,7 @@
case MYSQL_TYPE_STRING:
case MYSQL_TYPE_BLOB:
case MYSQL_TYPE_TINY_BLOB:
-#ifdef MYSQL_VERSION_ID > NEW_DATATYPE_VERSION
+#if (MYSQL_VERSION_ID > NEW_DATATYPE_VERSION)
case MYSQL_TYPE_GEOMETRY:
#endif
case MYSQL_TYPE_TIMESTAMP:
@@ -2530,7 +2530,9 @@
}
else
{
-/*if (dbis->debug >= 2)
+ int num_fields;
+
+ /*if (dbis->debug >= 2)
PerlIO_printf(DBILOGFP,
" <- dbd_st_more_rows use_mysql_use_result=%d\n",
use_mysql_use_result);
@@ -2570,7 +2572,7 @@
/** Store the result in the current statement handle */
DBIc_ACTIVE_on(imp_sth);
-int num_fields=mysql_num_fields(imp_sth->result);
+num_fields=mysql_num_fields(imp_sth->result);
DBIc_NUM_FIELDS(imp_sth) = num_fields;
==
I colleague of mine has been briefly using DBD::mysql and was getting
a lot of "FREE ERROR BIND!" messages appearing on stderr. I was asked
to take a look and I've reproduced this with the following code
running against DBD::mysql 3.0002_4:
use DBI;
# DBI 1.50
# perl, v5.8.7 built for i686-linux
# mysql 5.0.15
#
my $dbh = DBI->connect('dbi:mysql:database=martin;host=localhost;',
'xxx', 'yyy');
$dbh->do(q/drop table if exists bindissue/);
$dbh->do(q/create table bindissue (a int)/);
my $sql = q/select a from bind where a = ?/;
my @data = $dbh->selectrow_array($sql, undef, 1);
which when run produces:
bash-2.05$ ./bind2.pl
FREE ERROR BIND!bash-2.05$
I presume because the result-set is empty.
This seems to be due to finish in the driver being called twice. I'm
not overly familiar with DBD::mysql but commenting out the finish call
(in dbd_st_fetch) below makes the problem go away:
if ((rc= mysql_stmt_fetch(imp_sth->stmt)))
{
if (rc == 1)
do_error(sth, mysql_stmt_errno(imp_sth->stmt),
mysql_stmt_error(imp_sth->stmt));
if (rc == 100)
{
/* Update row_num to affected_rows value */
imp_sth->row_num= mysql_stmt_affected_rows(imp_sth->stmt);
imp_sth->fetch_done=1;
}
/* MJE
if (!DBIc_COMPAT(imp_sth))
dbd_st_finish(sth, imp_sth);
*/
return Nullav;
}
May be the finish is required if rc == 1 but I've not got the time
right now to look into it. Perhaps someone who knows DBD::mysql better
might want to take a look (I can supply any other info on versions etc
if it helps).
As an aside, what exactly does DBIc_COMPAT do? The DBI::DBD document
refers to its use with "FOR AN OLD PERL INTERFACE" but the reason
was not clear to me.
==
Tim followed up with:
It stems from the days of perl4 db interfaces (oraperl, sybperl etc).
Many drivers, such as DBD::Oracle, shipped with modules that provided
backwards compatibility with the old perl4 APIs (ie Oraperl).
Setting $sth->{Compat} = 1 will make DBIc_COMPAT(imp_sth) true.
So that gives you a pure-perl workaround.
Tim.
p.s. I've no idea why it's used in DBD::mysql in this way.
==
Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com
On 31-Jan-2006 Patrick Galbraith wrote:
> Greetings all!
>
> I apologise for what might seem somewhat of a bit of neglect on my part
> to get some features into DBD::mysql, features such as UTF support, some
> bugs in 3.0002_4. I've been super busy on some other projects, but have
> finished one of them and have today started to go through my mail in
> order to start addressing some needs of DBD::mysql.
>
> I'm wondering if it might help to discuss within this list what
> priorities users would like to see addressed in DBD::mysql, so I could
> come out with some sort of road map.
>
> Just some thoughts, and a note to let all of you know that I'm here!
>
> Kind regards,
>
> Patrick Galbraith
