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.c    Sun 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

Reply via email to