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):
Results:#!/usr/bin/perl use warnings; use strict; # to prevent silly errors use DBI; my $addbh = DBI->connect('dbi:AnyData(RaiseError => 1):'); $addbh->func('mytable', 'CSV', [ <DATA> ], 'ad_catalog'); my $sth = $addbh->prepare( 'select foo, bar, baz from mytable' ); $sth->execute; DBI::dump_results($sth); #$sth->finish; #$addbh->disconnect; __DATA__ foo,bar,baz 1,2,3 4,5,6 7,8,9
I can't seem to suppress or fix the "DBI handle cleared whilst still active" message$ perl anydata.pl '1', '2', '3' '4', '5', '6' '7', '8', '9' 3 rows DBI handle 0x85cecf8 cleared whilst still active, <DATA> line 4. dbih_clearcom (sth 0x85cecf8, com 0x85d1c58, imp DBD::AnyData::st) +: FLAGS 0x182195: COMSET Active Warn RaiseError PrintError PrintW +arn ShowErrorStatement PARENT DBI::db=HASH(0x85cebfc) KIDS 0 (0 Active) IMP_DATA undef NUM_OF_FIELDS 3 NUM_OF_PARAMS 0
Hopefully, jZed can shed more light when he gets a chance.
Update: I am using Debian unstable, all packages up-to-date
In reply to Re: DBD::AnyData completely broken (or is it just me?)
by bmann
in thread DBD::AnyData completely broken (or is it just me?)
by avarus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |