Oracle 18.104.22.168 on Enterprise Linux Enterprise Linux Server release 5.4 (Carthage).
Using FreeTDS unixODBC Driver to connect to a MS SQL-Server 2008 R2 SP1database. (RPM package freetds-0.64-1.el5.rf.x86_64 reported by yum whatprovides for ODBC FreeTDS .so).
ODBC isql connectivity works and SQL select Col1 from Schema.Table is successfully executed against DSN, and returns rows/data (not real names).
Same SQL in Oracle, select "Col1" from "Schema"."Table"@dblink fails (using the same ODBC DSN as isql test cor connectivity), via sqlplus.
Debug trace (HS_FDS_TRACE_LEVEL=debug) reports:
Exiting hgopars, rc=28500 at 2013/06/19-14:12:08 with error ptr FILE:hgopars.c LINE:570 FUNCTION:hgopars() ID:SELECT list of size 0 is not valid
Have enabled/disabled numerous combinations of odbc.ini and init.ora parameters such QuotedId, HS_FDS_SQLLEN_INTERPRETATION, HS_FDS_SUPPORT_STATISTICS and so on. Also tried using DBMS_HS_PASSTHROUGH, instead of native SQL via sqlplus. Same error, consistently.
Interestingly, the desc "Schema"."Table"@dblink call works fine in sqlplus - but according to the debug trace it lets the ODBC driver deal with it - it does not craft a SQL and pass this to the ODBC driver, according to the debug trace. Instead an ODBC interface call is used to describe the object.
So, ODBC driver seems perfectly fine. Oracle can successfully use it as the desc command proved. Except that SQL statements (from Oracle) via the driver fails.
Any ideas as to what the problem can be?
Yes, thanks Mike.
Ran into a brick wall troubleshooting, have developers and project managers doing what seems to be an ugly dance (think that is what they are doing with the up and down jumping movements).
With no responses to my posting here, and my dislike of bad dancing, went the SR route instead.
Appreciate you looking at the posting though. Makes me feel less alone in a world of bad dancers...
Oh yes - did figure out why hgopars throws that error. Seems like a problematic ODBC call sequence that causes SQLNumResultsCols.c (in the driver) to return 0 as the col count for the statement's projection.
Changing to latest stable FreetTDS changed the problem, so now I have the joy of troubleshooting a brand new issue using a driver interface I dislike, connecting to an inferior database product, from a company I have no respect for.
What? Me whine?? Never!