OWB 11.2, ODBC to SQL Server - metadata import problem

Question

Hi All,
We are using Oracle on 64-bin linux and sql server 2000. We also using OWB11.2 both on Windows and Linux.
We installed open source ODBC on linux (freeTDS) and created dblink to sql server – connection works just fine and we can retrieve data from sql server using standard tools like TOAD, SQLDeveloper, or sqlplus. But when I create ODBC module in OWB11.2 and try to import metadata (tables) from sql server I have the following error:
SQL Exception
SQL Exception
Persistent Layer Error:SQL Exception..
Class Name: CacheMediator.
Method Name: getSQLResult.
Persistent Layer Error Message: ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
[FreeTDS][SQL Server]Procedure 'sp_columns' expects parameter '@table_name', which was not supplied. {42000,NativeErr = 201}
ORA-00604: error occurred at recursive SQL level 1
ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
[FreeTDS][SQL Server]Procedure 'sp_columns' expects parameter '@table_name', which was not supplied. {42000,NativeErr = 201}
ORA-06512: at "SYS.HS$_DDTF_SQLCOLUMNS", line 84
ORA-06512: at line 1
ORA-02063: preceding 7 lines from OWB_604
. (etc)
When connected to sql server using the account used in dblink I can execute sp_columns without any trouble so it’s not a security issue.
Did anybody experience the similar problem?
BTW we successfully used similar technique for Sybase as a source and Oracle (10.2) as a target using OWB 10.2 a few years ago.
Any help is appreciated,
Thanks,
Alex

Answer 1

Hi Alex
It may be a problem with the ODBC driver for the queries executed to import the catalog metadata. Sometimes you get drivers that 'seem' to work for querying the data but for access the metadata to reverse engineer problems arise. Are you using the latest greatest version of the ODBC driver? If logging was turned on in the client (see here ) probably would be able to get the last query fired at the gateway and this would be the culprit.
One alternative option is to use a remote database gateway agent (now possible in 11g) on the Windows machine, which you can then access from your linux host.
Cheers
David