Re: DBD::foo::GetInfo generator
Steffen Goeldner wrote:
The order of options for SQL_SQL92_PREDICATES and for
SQL_STRING_FUNCTIONS (not SQL92_STRING...) are different in your Local
directory than they are in the MSDN ODBC docs.
Do you mean the order in the output of GetInfoAll.pl? E.g.:
SQL_FN_STR_CONCAT | SQL_FN_STR_LEFT | SQL_FN_STR_LTRIM ...
No, I mean the order (and values) of the bitmask.
You have:
$ReturnValues{SQL_SQL92_PREDICATES} =
{
SQL_SP_EXISTS = 0x0001
, SQL_SP_ISNOTNULL = 0x0002
, SQL_SP_ISNULL = 0x0004
, SQL_SP_MATCH_FULL = 0x0008
}
The ODBC docs have:
SQL_SP_BETWEEN
SQL_SP_COMPARISON
SQL_SP_EXISTS
SQL_SP_IN
...
Which I assumed means
SQL_SP_BETWEEN= 0x0001
SQL_SP_COMPARISON = 0x0002
SQL_SP_EXISTS = 0x0004
SQL_SP_IN = 0x0008
...
Perhaps I am mistaken when I assume that the order in the docs is the
bitmask order (the docs become pretty useless otherwise). If so, then
where is the bitmask order listed?
Should I sort by value, i.e. by key of $ReturnValues{...} ?
That's how the ODBC docs have them (alphabetical by key), but that's
just cosmetic. I'm getting fouled up on the actual values since if I
assume that SP_BETWEEN is 1 and SP_COMPARISON 2, then my bitmask is
quite different than using the values in your hash.
--
Jeff
Re: DBD::foo::GetInfo generator
Steffen Goeldner wrote: I used the C header files (sql.h and sqlext.h) from the MDAC SDK 2.6: Ok, thanks, I've got those header files and will use them. Silly of me to assume that the docs would be useful :-(. On another issue ... I have a bit of a complex situation with three different DBDs taking most of their GetInfo information from SQL::Statement and two radically different versions of SQL::Statement. So this is how I have the namespace set up: DBD::CSV::get_info() --++- SQL::Statement::GetInfo.pm || DBD::AnyData::get_info() --++ || DBD::Excel::get_info() ++- SQL::Statement::GetInfo_XS.pm I changed the hard-coded driver-specific information to subs (e.g. changed $sql_driver_ver to \sql_driver_ver) so I could get that info from the DBDs without storing anything specific to a given DBD in the GetInfo .pms. There will be no DBD::CSV::GetInfo.pm or DBD::AnyData::GetInfo.pm. What this means is that when I add support e.g. for column alias to SQL::Statement and the user upgrades Statement but not their DBD, the DBD's get_info() will show the correct value for column alias. Does that all sound ok? -- Jeff
Re: DBD::foo::GetInfo generator
Hi Steffen, I've used your fine scripts to create and test $dbh-get_info() via DBD::CSV. It works great. I've noticed two minor discrepencies between the documentation I have and the way the script operates. The order of options for SQL_SQL92_PREDICATES and for SQL_STRING_FUNCTIONS (not SQL92_STRING...) are different in your Local directory than they are in the MSDN ODBC docs. This leads to discrepencies when building the bitmasks. Please check out both of those out here or at the MSDN url it points to: http://www.vpservices.com/jeff/programs/SQL/docs/odbc-getinfo-msdn.html Thanks! -- Jeff
Re: DBD::foo::GetInfo generator (was: quoted_identifier and get_info)
On Fri, Feb 15, 2002 at 06:24:13PM +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 a first cut; Thanks. test it, stress it, tell me what you think! This means YOU! (as in, all driver authors reading this) Tim.
