DBResultSet<<size returns -1062

I run a SQL SELECT query on a Sybase SQL Anywhere 5.5.03 database, and get a
DBResultSet in Dolphin.  I am trying to display this result set in a list
view.  However the list view appears to be empty.  Upon further inspection I
can see that the query certainly does contain records.  When I send size to
it it returns -1062.  I think this is preventing the list view from
displaying it.  I looked at the DBResultSet<<size comments regarding the
handling of a -1 value.  I wonder if the test should be < 0 rather than
== -1?  A further interesting point is that it seems that there are 1062
records in the result set.  So it seems to be returning the correct number,
but is negating it.  Does any one have any thoughts as to why this may be
occurring, or how I might most easily rectify it?

Thanks,

Chris

Chris

You wrote in message news:a51nk7$42ri5$[hidden email]...
> I run a SQL SELECT query on a Sybase SQL Anywhere 5.5.03 database, and get
a
> DBResultSet in Dolphin.  I am trying to display this result set in a list
> view.  However the list view appears to be empty.  Upon further inspection
I
> can see that the query certainly does contain records.  When I send size
to
> it it returns -1062.  I think this is preventing the list view from
> displaying it.  I looked at the DBResultSet<<size comments regarding the
> handling of a -1 value.  I wonder if the test should be < 0 rather than
> == -1?

The ODBC spec. does explicity state that if the number of rows is not known,
then -1 should be returned, otherwise the number of rows should be returned.
Returning the number of rows affected is mandatory for statements that
modify rows, but optional for SELECT statements. It is quite common to find,
for example, that an ODBC driver is able to return the number of rows in a
result set when an entire table is selected, so this can be a useful.

It would seem that the driver in question is not implementing the spec.
correctly. However I think it would be OK to change the test to < 0 to catch
this particular foible.

>...A further interesting point is that it seems that there are 1062
> records in the result set.  So it seems to be returning the correct
number,
> but is negating it.  Does any one have any thoughts as to why this may be
> occurring, or how I might most easily rectify it?

No. I would think this is some mistake on the part of the driver writer, and
I think they should be told :-)

Regards

Blair

Blair McGlashan <[hidden email]> wrote in message
news:a52h9q$4063g$[hidden email]...

> The ODBC spec. does explicity state that if the number of rows is not
known,
> then -1 should be returned, otherwise the number of rows should be
returned.
> Returning the number of rows affected is mandatory for statements that
> modify rows, but optional for SELECT statements. It is quite common to
find,
> for example, that an ODBC driver is able to return the number of rows in a
> result set when an entire table is selected, so this can be a useful.

I did some more digging on the web, and I found this link:
http://faqchest.dynhost.com/prgm/dbi-l/dbi-99/dbi-9904/dbi-990400/dbi9904011
5_25050.html
It seems to shed some light on what Sybase was thinking (perhaps they were
being too creative).  It essentially says that the driver may define the
return value for SELECT and other statements.  Apparently Sybase is
providing an estimate of the number of rows.  SQLRowCount returns a negative
size to indicate that it is an estimate.

> It would seem that the driver in question is not implementing the spec.
> correctly. However I think it would be OK to change the test to < 0 to
catch
> this particular foible.

Yes, I could do that.  Or knowing what I now know perhaps I could return the
absolute value of the size.  The only issue is that I am not sure how
comfortable I am with the notion of an estimate from Sybase.  Either it
knows the size, or  it doesn't! ;)  I guess I will go with the < 0.

> > but is negating it.  Does any one have any thoughts as to why this may
be
> > occurring, or how I might most easily rectify it?
>
> No. I would think this is some mistake on the part of the driver writer,
and
> I think they should be told :-)

I am interfacing with a third party product that happens to use this
particular driver, and I think it may be a little old besides.

Thanks for your response,
Chris