FreeTDS Development Group

["Rainer" <sourceforge AT powered.net>]

>> But now WINE is crashing with the following error:
>>
>> trace:odbc:SQLSetStmtOption
>> trace:odbc:SQLSetStmtOption
>> /opt/cxoffice/bin/wineloader: relocation error:
>> /usr/local/unixodbc/lib/libodbccr.so.1: undefined symbol:
>> __post_internal_error
>
> This looks like a linker problem in your unixodbc installation.


James,

Updating libtool and recompiling unixodbc/freetds solved the problem, thanks.
Since the "No Current Row" error continues, I've decided to do a direct
comparison (which functions are called, when, and what they return)
between the log generated by M$ MDAC (while running this application on
Win2k, not emulated), and the unixODBC log (app emulated with WINE)
Hopefully this could shed some light on the differences between MDAC and
FreeTDs behaviors/functions.

The logs are here, in case you want to examine them further:
http://www.powered.net/rainer/unixodbc-trace-10-07.log
http://www.powered.net/rainer/ms-mdac-trace-10-07.log

In the begining, FreeTDS receives a SQL_ATTR_ODBC_CURSORS, returns "S1C00"
(Driver not capable), sends a SQL_SUCCESS and continues normally.
Apparently the application is trying to use cursors, but since cursors
implementation in FreeTDS isn't complete yet, why does it return
SQL_SUCCESS ? What are the consequences?

At some point, MDAC calls the following functions many times (alternating):
SQL_C_CHAR
SQL_C_SHORT
SQL_C_LONG

FreeTDS, on the other had, does the following replacements:
It calls..
SQL_CHAR instead of SQL_C_CHAR
SQL_SMALLINT instead of SQL_C_SHORT
SQL_INTEGER instead of SQL_C_LONG

After this, FreeTDS does some SQLFETCH, but MDAC issues some functions
before it fetches, which are:
SQL_ATTR_ROW_BIND_TYPE
SQL_ATTR_ROW_ARRAY_SIZE
SQL_ATTR_ROWS_FETCHED_PTR
SQL_ATTR_ROW_BIND_OFFSET_PTR
SQL_ATTR_ROW_STATUS_PTR

After the fetches, they both issue similar functions:
MDAC:
SQL_QUERY_TIMEOUT
SQL_MAX_ROWS
SQL_CONCURRENCY
SQL_CURSOR_TYPE
SQL_ASYNC_ENABLE

FreeTDS:
SQL_ATTR_QUERY_TIMEOUT
SQL_ATTR_MAX_ROWS
SQL_ATTR_CONCURRENCY
SQL_ATTR_CURSOR_TYPE (mdac returns sql_success here, while freetds returns
sql_success_with_info)
SQL_ATTR_ASYNC_ENABLE

Afterwards, they both call the stored procedure spLicenca (i mentioned
this some time ago), but notice the difference:
MDAC:
EXECUTE dbo.spLicenca 'machine-name','809204514','00 E0 7D 88 88
FC','[mrhs{w$6444',3,'','','','', ''
FreeTDS:
EXECUTE dbo.spLicenca 'machine-name','305419896','00 00 00 00 00
00','[mrhs{w$=<',3,'','','','', ''
I'll report this difference in the stored procedure arguments to the
application developers and see what they think.

Before the application (emulated with WINE) crashes with the "no current
row" error, FreeTDS execute those (in this order):
SQL_COLUMN_NULLABLE
SQL_DESC_CONCISE_TYPE
SQL_DESC_UPDATABLE
SQL_DESC_LABEL
SQL_COLUMN_LENGTH
SQL_COLUMN_NAME
SQL_DESC_TABLE_NAME
SQL_DESC_CONCISE_TYPE
SQL_COLUMN_PRECISION
SQL_COLUMN_SCALE
SQL_DESC_FIXED_PREC_SCALE
SQL_CHAR
And then it crashes with a SQL_NO_DATA during SQLExtendedFetch.

On the other hard, MDAC runs those (in this order) and the application
doesn't give any error:
SQL_COLUMN_NULLABLE
SQL_COLUMN_TYPE
SQL_COLUMN_UPDATABLE
SQL_COLUMN_LABEL
SQL_COLUMN_LENGTH
SQL_COLUMN_NAME
SQL_COLUMN_TABLE_NAME
SQL_COLUMN_TYPE
SQL_COLUMN_PRECISION
SQL_COLUMN_SCALE
SQL_COLUMN_MONEY
SQL_C_CHAR

Instead of returning SQL_NO_DATA (like FreeTDs above), the MDAC log
continues and calls:
SQL_FETCH_NEXT
Sends SQLColAttributes (22) and receives SQL_SUCCESS (the mdac log states
this attribute as 'unknown'.. maybe the difference lies right here??...
unimplemented in freetds perhaps?)
SQLDescribeCol (?)
SQL_UNBIND
SQL_ATTR_ROW_BIND_TYPE
SQL_ATTR_ROW_ARRAY_SIZE
SQL_ATTR_ROWS_FETCHED_PTR
SQL_ATTR_ROW_BIND_OFFSET_PTR
SQL_ATTR_ROW_STATUS_PTR
SQL_C_CHAR
SQL_FETCH_NEXT
SQL_DROP
--end--

Regards,
Rainer