Re: Problem retrieveing results from a query with an IMAGE field

In the attached mail you answered me 3 points:

1) Informed me about the existance of cursor6. => Thanks, I'll look at it

2) You think its strange that I had problems with the underlaying TDS
mechanism even after closing the statement and openning another => I'll
check it again. If I find I'm not wrong I'll send the simplest program
possible that produces the error.

3) You're supporting SQL_POSITION in SetPos() and in my previous mail I
said it was not supported => Ugh!! I looked at the wrong bit when I
analyzed the result of SQLGetInfo. Sory.

4) Simple question: I have a query that returns 21 rows and I'm using a
rowset size of 20. I open the query and do SQLFetchScroll(hStmt,
SQL_FETCH_LAST, 0) to retrieve the last 20 rows, rows 2-21 are
returned. Then I do SQLFetchScroll(hStmt, SQL_FETCH_RELATIVE, -20) to
retrieve the previous 20 rows. As there is only one left I would expect
to get a status of SQL_ROW_NOROW in all rows in the rowset except for
the first, but I get rows 1-20. Is there any way of knowing that the
returned rows ar not the the "previous 20 rows" but the "first 20
rows"?


Bye,


                                      Daniel



>>
>> 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!
>>
>
> I wrote a test (cursor6) and the fix. See
> http://freetds.sourceforge.net/ for post 0.82 fixes
>
>> 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.
>>
>
> Quite strange, a cancel should be issued and connection should be
> reset...
>
>> 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).
>>
>
> ??? 0.82 should report a value if cursors are supported (currently
> using
> mssql)
> I have to review the SQL_POSITION part. Currently it tells the server
> which row we want... I never though about SQLGetData and
> SQL_POSITION...
> the problem here is:
> - fetch n rows (where N > 1) with some unbinded columns
> - use SQL_POSITION
> - get data with SQLGetData
> questions:
> - does client send some commands during SQL_POSITION or only if cursor
> name is set ?
> - SQLGetData gets correct data?
>
>> 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. :)
>>
>
> freddy77
>