Martin, Is this really a necessary/useful SQLGetInfo for DBI? I don't seem to think so, other than, possibly, to prevent calling it incorrectly and return undef.
Jeff [snip] > > FYI: My script > > > > <http:[EMAIL PROTECTED]/msg00882.html> > > > > still dumps for some info types, e.g.: > > > > SQL_DRIVER_HSTMT > > SQL_DRIVER_HDESC > > > > DBD::ODBC does not print an error. Thus, it seems this occurs > > in the ODBC driver itself (MS Access). > > Well, I think these info types are not very useful for DBI anyway. > > For now, I simple skip these info types: > > > > next if /^SQL_DRIVER_H/; > > I would guess this happens because unlike the other SQLGetInfo > identifiers, > SQL_DRIVER_HSTMT and SQL_DRIVER_HDESC are INPUT values as well as > OUTPUT ones > i.e. you don't get anything out of SQLGetInfo(.., SQL_DRIVER_HSTMT, > InfoValuePtr, ..) unless *InfoValuePtr is initialised first. > > The ODBC docs say: > > ========== > If the InfoType argument is SQL_DRIVER_HDESC or SQL_DRIVER_HSTMT, the > InfoValuePtr argument is both input and output. (See the > SQL_DRIVER_HDESC or > SQL_DRIVER_HSTMT descriptors later in this function description for more > information.) > > SQL_DRIVER_HSTMT > > (ODBC 1.0)An SQLUINTEGER value, the driver's statement handle > determined by > the Driver Manager statement handle, which must be passed on input in > *InfoValuePtr from the application. Note that in > this case, InfoValuePtr is both an input and an output argument. > The input > statement handle passed in *InfoValuePtr must have been allocated on the > argument ConnectionHandle. > > The application should make a copy of the Driver Manager's > statement handle > before calling SQLGetInfo with this information type, to ensure > that the handle > is not overwritten on output. > > This information type is implemented by the Driver Manager alone. > ========== > > Martin > -- > Martin J. Evans > Easysoft Ltd, UK > Development > >
