On Mon, 15 Mar 1999, Paul DuBois wrote:
> 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.
" Returns the number of rows affected by the last UPDATE, DELETE or
INSERT
query. May be called immediately after
mysql_query() for UPDATE, DELETE or INSERT statements. For SELECT
statements, mysql_affected_rows()
works like mysql_num_rows(). "
I read the documentation wrong. I _assumed_ it could always be called
immediately after mysql_query() for a select call, since I did not parse
the words carefully enough.
>
> 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.
Not exactly. I read this :
"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 did not expect an exact number of rows to be returned. I did expect 0
or non-zero, where 0 would key me to skip trying to do anything.
I found out later that even with 0 rows, you must call mysql_fetch_row()
to get the system to settle down. OH, well.
Other than that, it worked like a charm.
wade
