FreeTDS Development Group

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

Thank you Frediano! With the information provided I managed to overcome
the problem :). I recoded the application to avoid fetching columns I'm
not planning to bind and its working fine now!

Even though its solved for me, I decided to look into the problem
again. It may seem a bit masochist, but when I'm using something free I
have a feeling of beeing in debt with the people that worked in that.
Perhaps, I can help ...

To tell you the truth, what I dislike the most about this issue is that
it hangs the underlaying TDS mechanism. When I didn'k know anything
about what caused the problem, one of my first attempts to recover from
the error was closing the statement and openning another. The new
allocated statement failed when I tried to use it! So I believe
something has to be done when unbinding a socket, perhaps "discarding
unprocessed results" or something alike.

Then I decided to browse the web to see what other drivers did when
reaching columns that are not bound in a non-unitary rowset fetch. As
far as I could research there are two cases:

1) Drivers that support SetPos: They cache data, as the user can "move"
the pointer using SQLSetPos option SQL_POSITION to any row in the
rowset. This is not the case, at least at this point, of TDS ODBC
driver, as it clearly reports SQL_CA1_POS_XXXX bits clear in a call to
SQLGetInfo(SQL_XXXX_CURSOR_ATTRIBUTES1).

2) Drivers that do not support SetPos: As far as I could research, I
believe it might be convenient to change the concept of "stopping at
the first unbound column" by "stopping at the first unbound column OF
THE LAST ROW RETURNED". This would be compatible with single-row
rowsets
and permit retrieveing multiple rows without having to bind them all. I
found Postgresql driver for linux is in this second group, so I did a
couple of small programs and verified it behaves this way. What do you
think?

PS: If you, as the project leaders, think this is a minor problem and
preffer to leave it as it is, just let me know. I won't bother you any
more with mails. :)





> Il giorno mer, 04/06/2008 alle 15.05 -0300, Daniel A. Veiga ha scritto:
>> This is the TDSDUMP log generated for the same program I sent the
>> unixODBC log file for. I hope it helps ...
>>
>>                               Daniel
>>
>
> it helps, it helps :)
>
> The code which cause the problem is in _SQLFetch
>
>
> /* TODO change when we code cursors support... */
> /* stop looping, forward cursor support only one row */
> num_rows = 1;
>
> well.. this tell to stop processing rows if an unbinded column is
> found.
> This is done to allow getting results using SQLGetData however we send
> a
> cursor fetch for 20 rows so in this case we have still to read 19 rows
> when SQLFetchScroll returns :(
>
> Well... for forward only cursors this is correct for perhaps for
> cursors
> is not... I think the correct processing should be fetch all 20 rows or
> request only a row (I think the last is the most probable)... I'll have
> to test.
>
> freddy77
>
>