At 10:24 PM -0600 3/15/1999, Wade Maxfield wrote:
> OK. I've got compile and link with mysql. I connected to the database.
>
> if you use mysql_affected_rows(&mysql) after a select, it returns a
>non-zero value even if 0 rows were returned.
>
> You actually have to try to fetch the row before you find out no data
>was selected. The documentation says you find the number of rows
>retrieved by the select. I think this is a bug.
It depends, and it's difficult to say without seeing your code. However,
if you're using mysql_use_result() as you describe below, it's not a
bug, for the reason given below.
> If you use mysql_store_result(), you can use mysql_num_rows() and find
>out no rows were affected.
>
> However, if you use mysql_num_rows() before calling mysql_use_result()
>you get a segmentation fault. This was not mentioned in the documentation
>as causing a segmentation fault.
No, but it does say you can't call mysql_num_rows() before calling
mysql_use_result:
`mysql_num_rows()'
------------------
`my_ulonglong mysql_num_rows(MYSQL_RES *result)'
Description
...........
Returns the number of rows in the result set.
The use of `mysql_num_rows()' depends on whether you use
`mysql_store_result()' or `mysql_use_result()' to return the result
set. If you use `mysql_store_result()', `mysql_num_rows()' may be
called immediately. If you use `mysql_use_result()',
`mysql_num_rows()' will not return the correct value until all the rows
in the result set have been retrieved.
I guess it would be friendlier not to segfault, but you're still
violating the documented behavior.
When you use mysql_use_result(), you *cannot* find out how many rows
were selected, without actually fetching them:
An advantage of `mysql_use_result()' is that the client requires less
memory for the result set since it maintains only one row at a time (and
since there is less allocation overhead, `mysql_use_result()' can be
faster). Disadvantages are that you must process each row quickly to
avoid tying up the server, you don't have random access to rows within
the result set (you can only access rows sequentially), and you don't
know how many rows are in the result set until you have retrieved them
all. Furthermore, you *must* retrieve all the rows even if you
determine in mid-retrieval that you've found the information you were
looking for.
I'm curious; is there something in the manual that led you to expect
you'd be able to get the row count with mysql_use_result() without
fetching the rows? If so, that needs to be fixed.
--
Paul DuBois, paul@stripped
Northern League Chronicles: http://www.snake.net/nl/
Madison Black Wolf: http://www.primate.wisc.edu/people/dubois/blackwolf/