MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Paul DuBois Date:March 16 1999 4:37am
Subject:Re: Info about retrieving in C api. Possible bug?
View as plain text  
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


    `my_ulonglong mysql_num_rows(MYSQL_RES *result)'


    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:
Madison Black Wolf:
Info about retrieving in C api. Possible bug?Wade Maxfield16 Mar
  • Re: Info about retrieving in C api. Possible bug?Paul DuBois16 Mar
    • Re: Info about retrieving in C api. Possible bug?Paul DuBois16 Mar
    • Re: Info about retrieving in C api. Possible bug?Wade Maxfield16 Mar