On 16/11/14 23:59, Kurt Starsinic wrote:
Hi all,
I've been using DBI with DBD::Sybase and SQL Server, and discovered a
couple of issues. I will be happy to offer a patch if I can get some
consensus on what the correct resolutions are:
The DBI docs say that foreign_key_info() can take from 3 to 7
arguments, but the code demands 6 or 7 (even though many of the
arguments can be undef). My opinion is that the docs are good and the
code is broken. Any objections on this point?
The docs say:
$sth = $dbh->foreign_key_info( $pk_catalog, $pk_schema, $pk_table
, $fk_catalog, $fk_schema, $fk_table );
Perhaps you are referring to "If both PKT and FKT are given" or the examples:
$sth = $dbh->foreign_key_info( undef, $user, 'master');
$sth = $dbh->foreign_key_info( undef, undef, undef , undef, $user,
'detail');
$sth = $dbh->foreign_key_info( undef, $user, 'master', undef, $user,
'detail');
The addition of \%attr on the end of foreign_key_info is probably what is
dictating the minimum of 6 so I think the example with 3 arguments is probably
wrong. Also the ODBC API for SQLForeignKeys takes the same 6 arguments.
Also, at least with SQL Server, foreign_key_info() returns columns
named [FP]KTABLE_OWNER and [FP]KTABLE_QUALIFIER instead of
[FP]KTABLE_SCHEMA and [FP]KTABLE_CAT. I think the driver should
rewrite the column names. Does anybody disagree?
They are the old ODBC 2 names for the columns. You can certainly get those with
DBD::ODBC with very old drivers. The ODBC docs say:
"The following columns have been renamed for ODBC 3.x. The column name changes do
not affect backward compatibility because applications bind by column number."
As the DBD::ODBC maintainer I would prefer not to have to map ODBC 2 names to 3
- it would set a precedent that would lead to many other changes.
Thanks, Kurt Starsinic
Martin
