avarus has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I know that Jeff Zucker often appears on these forums, so I'm hoping he'll see this but any thoughts would be appreciated. I have some code which uses DBD::AnyData and it has suddenly (ie in the past couple of months) stopped working. It appears that DBD::AnyData does not work at all any more, due to upgrades on Debian.

I made the following test: 

#!/usr/bin/perl
#/home/tbooth/perl/testanydata.perl - created Mon Jun 27 13:57:06 2005

use warnings;

use DBI;

my $addbh = DBI->connect('dbi:AnyData(RaiseError=>1):');
$addbh->func('import', 'CSV', [<DATA>], 'ad_import');


__DATA__
foo,bar,baz
1,2,3
4,5,6

[download]

Result is: 
Can't call method "fetchrow_array" on unblessed reference at /usr/shar
+e/perl5/SQL/Statement/Functions.pm line 560, <DATA> line 3.

[download]


Surely that should work? If I use 'ad_catalog' instead of 'ad_import' it throws the same error on the first attempt to select.

Current module versions are: 
libxml-twig-perl 3.17-1
libanydata-perl 0.10-4
libtext-csv-perl 0.23-5
libdbd-csv-perl 0.2100-2
libdbd-anydata-perl 0.08-2
libsql-statement-perl 1.14-1

[download]


I really don't want to have to re-write all my code to use another module. I'm prepared to downgrade something to make this work, but with so many dependencies I don't know where to start. Any help would be most appreciated.

Thanks - TIM
--
#Tip: use 'no strict' to make those nasty errors vanish.

Replies are listed 'Best First'.
Re: DBD::AnyData completely broken (or is it just me?)
by bmann (Priest) on Jun 29, 2005 at 07:49 UTC
    It's just you ;) (just kidding, it looks like a documentation bug at the very least.)

    Change the name of your table from 'import' to 'mytable', and it works.

    It isn't documented, but using 'import' as the table name causes SQL::Statement to try to call SQL::Statement::Functions::SQL_FUNCTION_IMPORT() with the wrong parameters - it expects a statement handle, which it doesn't get. Using the debugger, I verified that SQL_FUNCTION_IMPORT is not called wrongly when the table is named differently.

    Here's an example using ad_catalog (I get the same results with ad_import):

    Read more... (2 kB)

    Hopefully, jZed can shed more light when he gets a chance.

    Update: I am using Debian unstable, all packages up-to-date

[reply]
[d/l]
[select]
      Thankyou so much! That was one slippery bug.

      For anyone who finds this thread and wants to know how to suppress the warnings, here is one solution:

      #!/usr/bin/perl
#/home/tbooth/perl/testanydata.perl - created Mon Jun 27 13:57:06 2005

use strict;
use warnings;
use Data::Dumper;

use Carp;
$Carp::Verbose = 1;
$SIG{__DIE__} = \&croak;

# I was having issues with DBD::AnyData.  Here is a test.
use DBI;
require DBD::AnyData;
if(DBD::AnyData->VERSION eq '0.08')
{ eval
  '
    package DBD::AnyData::st;
    no warnings;

    sub DESTROY ($) { $_[0]->SUPER::DESTROY(@_) }
    sub finish ($) { $_[0]->SUPER::finish(@_) }
  ';
}

my $addbh = DBI->connect('dbi:AnyData(RaiseError=>1):');


$addbh->func('myimport', 'CSV', [<DATA>], 'ad_import');

print Dumper($addbh->selectall_hashref("SELECT * FROM myimport", 'foo'
+));
print "\n";

__DATA__
foo,bar,baz
1,2,3
4,5,6

      [download]

      --
      #Tip: use 'no strict' to make those nasty errors vanish.
[reply]
[d/l]

Back to Seekers of Perl Wisdom