FreeTDS Development Group

["Daniel A. Veiga" <dveiga AT advtechnology.com.ar>]

It's true, I get similar results when running under MS-SQL Server
Windows ODBC driver. But there I have the the possibility of avoiding 
the error. Before calling SQLFetchScroll I call SQLGetStmtAttr
(SQL_ATTR_ROW_NUMBER). If the row number is less than the rowset size, 
instead of retrieving the full rowset I retrieve only the number of 
records left. I tried the same under TDS odbc, but SQLGetStmtAttr
(SQL_ATTR_ROW_NUMBER) always returns 0 (unknown) and I find no solution
to the problem.
I modified cursor7 again, where you can see the difference:)
Bye,


                              Daniel




>> Should I have known you were going to make it part of the project I
would have been more carefull with the comments, name of the created
temp table, etc. To tell you the truth I only sent it as part of the
bug report, as it was an easy way of showing that some records are
returned twice.
>> Bye,
>>                                     Daniel
>
> CVS does not mean that are set on stone :)
> I tried with ms odbc and give same results with a small difference.
Overlapping is detected and a warning is returned. Note however that
there is no way to detect how many rows overlapped. It seems that
sp_cursorfetch returns 2 to say success but overlapped.
>
> freddy77
>
>
>> > Daniel A. Veiga wrote:
>> >> I modified one of the cursor test
>> >> programs to show the problem. I attack it to this mail.
>> >
>> > Applied to CVS.  Thanks!
>> >
>> > --jkl
>> >
>> _______________________________________________
>> FreeTDS mailing list
>> FreeTDS AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>

Attachment: cursor7.c
Description: Binary data