On Mon, Feb 11, 2002 at 12:36:59PM +0100, Steffen Goeldner wrote:
> Tim Bunce wrote:
> >
>
> > p.s. Steffen, any chance you could produce a chunk of code that'll
> > connect to a DSN (specified on the command line), query all the
> > get_info values and dump the results to stdout as a DBD::<foo>::GetInfo
> > module? Shouldn't be a big modification from the scripts you've
> > obviously developed already. It would obviously be a big help
> > to many driver authors.
>
> Here is my current test script:
>
> use DBI();
> use DBI::Const();
>
> $\ = "\n";
> $, = ": ";
>
> my $dbh = DBI->connect or die $DBI::errstr;
> $dbh->{ RaiseError } = 1;
> $dbh->{ PrintError } = 1;
>
> for ( @ARGV ? @ARGV : sort keys %DBI::Const::GetInfo )
> {
> my $Val = $dbh->get_info( $DBI::Const::GetInfo{$_} );
> printf " %-35s%s\n", $_, $Val if defined $Val;
> }
>
> Indeed, a small modification should do it. But
>
> 1) The script dumps if I use DBD::ODBC.
> I think it has to do with:
>
> /* Fancy logic here to determine if result is a string or int */
> (dbdimp.c) ...
Which probably shows up a bug in that logic that needs fixing.
What info type and return value is it failing on?
["Paging Mr Urlwin!"]
> 2) DBI::Const::GetInfo isn't part of DBI.
> Maybe we give it a second chance as SQL::CLI::GetInfo
> or something like that?
Seems like a reasonable idea. Though since it's primary role in
life will be just to hold constants rather than actually _get_ the
info, perhaps SQL::CLI::GetInfoConst, or similar, might be better.
It could also hold all the definitions for the constants associated
with the return values (if it doesn't already, I've not looked),
plus the functions to format them.
Tim.
