Ravi Kongara wrote:
No need to know abt err 65285, Silvio. Here are the steps
to make table_info( ) work correct for Oracle 7.3.4 server.
1. Copy the entire code of table_info( ) sub into ur program.
The code 'll be residing in
$perl_home_dir/site_perl/5.6.1/sun4-solaris-64int/DBD/Oracle.pm module,
if u r on Solaris or search for Oracle.pm in $perl_home_dir.
2. Name the subroutine as DBD::Oracle::db::table_info.
3. Add 'use DBD::Oracle' to ur program.
4. In the copied code,go to last SELECT stmt block and replace NULL (
for TABLE_CAT) to some dummy value. I'm afraid
'' (space) may not work. I used V$DATABASE.NAME.
5. Same trick can be applied to other catalog methods column_info(),
primary_key_info() etc.
Ravi
Thanx for you help, I hope the next DBD-Oracle release will include
according changes. I was unsteady if there is a general incompatibility
problem. Nevertheless remains it unintelligibly that thes ame SQL
code works with 7.* and 8.0.* clients + 7.3.4 server and also with
7.* and 8.* clients + 8.* server but not between a 8.1.* client and a
7.3.4 server.
Normally I can't use your code replacement, because $dbh->tables will
be called by DBIx::Database. I must changes it there, but
1. I'm not the maintainer
2. the usage of $dbh->tables in DBIx::Database may be a good choice
for other DBD drivers but not for Oracle (without a table filter
argument, it reads and caches the meta data of all objects returned
by tables(), this slow down the startup extremly if the Oracle
instance contains many users and because DBIx::Database caches
the meta data without the schema prefix we had already conflicts)
However I must already patch the DBIx::Recordset code, because tables()
of newer DBD::Oracle releases returns quoted id's like
'SCOTT'.'TEST1'
and this kills some features of DBIx::Recordset (also during test). I
will post my changes in some days and hope it will be integrated in
the next DBIx::Recordset release.
Silvio
