Tim Bunce wrote: > > On Mon, Nov 26, 2001 at 09:21:49PM +0000, Tim Bunce wrote: > > On Mon, Nov 26, 2001 at 04:25:16PM +0100, Steffen Goeldner wrote: > > > > On reflection I agree that DBI attributes should be consistently > > fetched by name, not a numeric value. > > I'm having second thoughts about this. > > > The $h->get_info method is still open to question. Since we have > > to provide a name to number mapping anyway then we could define the > > $h->get_info method to support either. > > I think a name to number mapping could be optional. > > If we drop the use of handle-attributes as a way to access SQLGetInfo()
No problem. For DBI.pm, we only have to provide another documentation (see attachment). > values and just provide a $dbh->get_info($) method then that method > would naturally take a number, as per SQLGetInfo() in ODBC & SQL/CLI. > > Then it's up to the developer to either pass a numeric value > > $rollback_behaviour = $dbh->get_info(24); # 24=SQL_CURSOR_ROLLBACK_BEHAVIOR > > or make use of an optional name to number mapping that the DBI can > provide (but not use internally): > > use DBI qw(:get_info); > $rollback_behaviour = $dbh->get_info(SQL_CURSOR_ROLLBACK_BEHAVIOR); Exporting these symbols depends on the implementation of the get_info constants. If you accepted DBI::Const - see: http:[EMAIL PROTECTED]/msg00559.html - then DBI.pm will need it's own import() routine, e.g.: sub import { my $class = shift; my $caller = caller; my @exports = (); for my $tag ( @_ ) { if ( $tag eq ':get_info') { require DBI::Const; while ( my ( $key, $val ) = each %DBI::Const::GetInfo ) { *{ $caller . '::' . $key } = sub () { $val }; } } else { push @exports, $tag; } } $class->export( $caller, @exports ); } Steffen
*** DBI-1.20.orig/DBI.pm Sat Aug 25 01:33:52 2001 --- DBI.pm Wed Jan 09 20:11:54 2002 *************** *** 2625,2630 **** --- 2625,2657 ---- Apache::DBI module for one example usage. + =item C<get_info> I<NEW> + + B<Warning:> This method is experimental and may change. + + $value = $dbh->get_info( $info_type ); + + Returns information about the implementation, i.e. driver and data source + capabilities, restrictions etc. + + For more detailed information about the information types and their + meanings, you can refer to: + + http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqlgetinfo.asp + + If that URL ceases to work then use the MSDN search facility at: + + http://search.microsoft.com/us/dev/ + + and search for C<SQLGetInfo returns> using the exact phrase option. + The link you want will probably just be called C<SQLGetInfo> and will + be part of the Data Access SDK. + + See also pages 95, 226, 328 of the current SQL/CLI Working Draft: + + +http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/DF86E81BE70151D58525699800643F56/$FILE/32N0595T.PDF + + =item C<table_info> I<NEW> B<Warning:> This method is experimental and may change.