On Wed, Nov 12, 2003 at 01:48:14PM -0000, Martin J. Evans wrote:
> Tim,
>
> Whilst I'm trying to narrow this issue down to just DBI or DBD::ODBC here is a
> level 2 trace (against the now installed DBD::ODBC 1.06):
>
> [EMAIL PROTECTED] DBD-ODBC-1.06]$ perl -w x.pl
> DBI 1.38-nothread dispatch trace level set to 2
> -> DBI->install_driver(ODBC) for linux perl=5.008 pid=22209 ruid=1000
> euid=1000
> install_driver: DBD::ODBC version 1.06 loaded from
> /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBD/ODBC.pm
> <- install_driver= DBI::dr=HASH(0x81ea584)
> -> data_sources for DBD::ODBC::dr (DBI::dr=HASH(0x81ea584)~0x8242454 undef undef)
> Usage: DBD::ODBC::dr::data_sources(drh, attr = NULL) at
> /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 964.
Okay. The question now is were did the two undefs in the arguments
to $drh->data_sources come from?
Tim.
> >> my @data_sources = DBI->data_sources('ODBC');
> >> print "Data sources:\n\t", join("\n\t",@data_sources),"\n\n";
> >>
> >> [EMAIL PROTECTED] DBD-ODBC-1.06]$ perl x.pl
> >> Usage: DBD::ODBC::dr::data_sources(drh, attr = NULL) at
> >> /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/DBI.pm line 964.
> >
> > sub data_sources {
> > my ($class, $driver, @other) = @_;
> > my $drh = $class->install_driver($driver);
> > my @ds = $drh->data_sources(@other);
> > return @ds;
> > }
> >
> > So $class would be "DBI", $driver would be "ODBC" and @other would be empty.
> > So then data_sources should be called with only the $drh as a parameter
> > and that shouldn't cause an error.
> >
> > Could you post a level 2 trace so we can see what's going on?
> >
> >> perldoc DBI appears to say:
> >> @data_sources = DBI->data_sources($driver_name, \%attr, $dbh);
> >> under SYNOPSIS and:
> >> @ary = DBI->data_sources($driver);
> >> @ary = DBI->data_sources($driver, \%attr);
> >> under "data_sources"
> >>
> >> The above code works fine with DBI 1.13 and DBD::ODBC 0.28.
> >
> > It would be more helpful if you could narrow it down to one changed
> > module instead of two. Also note that although the code that's failing
> > is 'in' the driver, it's actually supplied by the DBI that's installed
> > at the time the driver is compiled and installed.
> >
> > Tim.
>
