FreeTDS Development Group

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

James and Freddy,

After comparing the log gererated by the M$ libraries, I think I've
figured out the problem which is causing the 'no current row' error on
wine: the missing function SQL_FETCH_NEXT.

This makes sense: the application is trying to fetch the next rowset, but
since FreeTDS doesn't return it, it crashes with the 'no current row'
error. (please correct if I'm wrong here).
There is a "TODO comment" related to SQL_FD_FETCH_NEXT (and other
SQL_FETCH_DIRECTION functions) in src/odbc/odbc.c:4001.

Are there plans to implement this function?

Regards,
Rainer Alves


** FREETDS / UNIXODBC **
[ODBC][12911][SQLExtendedFetch.c][152]
                Entry:
                        Statement = 0x8163fb0
                        Fetch Type = 2
                        Row =
                        PcRow = 0x421a6e30
                        Row Status = 0x421a3380
[ODBC][12911][SQLExtendedFetch.c][323]
                Exit:[SQL_NO_DATA]
## crashes here

´´´´´´´´´´´´´´

** M$ / MDAC **

Intrsine        784-18c ENTER SQLExtendedFetch
                HSTMT               01C32988
                UWORD                        1 <SQL_FETCH_NEXT>
                SQLLEN                     1
                SQLULEN *           0x0139BE60
                UWORD *             0x0139C178

Intrsine        784-18c ENTER SQLNumResultCols
                HSTMT               01C32988
                SWORD *             0x0139C832
## continues...




--------------------------------------------------
> 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