[python-sybase] Fix for rowcount

Peter Hopfgartner hopfgartner at rolmail.net
Wed, 28 May 2003 22:02:33 +0200


Shai.Berger@sungard.com wrote:

>I believe the current behavior is correct according to
>the DB API spec, because when a query is executed, but
>no fetch has been performed, the interface cannot determine
>the number of rows produced (second clause, not first).
>  
>
Why? The database APIs that I have worked with give some information 
about the size of the resultset exactly at this stage. There are of  
minor use in a later state.

>    The attribute is -1 in case no executeXXX() has been performed on
>    the cursor or the rowcount of the last operation is not determinable
>    by the interface.[7]
>  
>

Well, I'm using the Sybase mudule since last summer. The behaviour 
changed exactly with the new fetcher classes, which are new to version 
0.36. So, until now, the interface WAS able to determine if there were 
or were not rows.

>Peter's problems with his patch indicate that the Sybase
>module decides on its own when exactly to perform fetches
>(until the time they are actually needed, of course). In
>this case, the consistent behavior of returning -1 until
>the user actually tries to fetch something sounds preferable.
>
>To the best of my knowledge, Sybase libraries do not reliably
>report an empty query until you actually try to fetch something,
>so the problem is not with the Python module.
>
>Peter: If you absolutely need to know the number of rows before
>you try to fetch anything, you can select count(*) with the same
>tables and conditions, before your query. This will always return
>one row... In theory, it could be done in the same query (using
>the Sybase "compute" clause, returning a separate result set), 
>but IIRC the compute results are returned only after the "regular"
>results, so you could only get to the rowcount this way by first
>discarding all the rows.
>  
>
Well, this would blow and uglify the code in an inappropriate way. Being 
forced to fire 2 queries, when only 1 is needed, means that there are 
serious problems in the API. Then it would be preferable to catch the 
appropriate exception.

In any case, I'm still convinced, that this is a minor bug and not a 
fundamental issue, since it worked fine until version 0.36. But, if it 
comes to the Sybase API, I must admit complete ingnorance.

>Hope this helps,
>	Shai.
>
>  
>
Thank you very much for your interest,

Peter