While I build a web page in My PHP web application, My Connection works ok but When I want to get the count of rows of the SELECT Statement I used in my query, It gives me -
odbc_num_rows
seems to be reliable for INSERT, UPDATE, and DELETE queries only.
The manual says:
Using odbc_num_rows() to determine the number of rows available after a SELECT will return -1 with many drivers.
one way around this behaviour is to do a COUNT(*)
in SQL instead. See here for an example.
in php.net:
The easy way to count the rows in an odbc resultset where the driver returns -1 is to let SQL do the work:
<?php
$conn = odbc_connect("dsn", "", "");
$rs = odbc_exec($conn, "SELECT Count(*) AS counter FROM tablename WHERE fieldname='" . $value . "'");
$arr = odbc_fetch_array($rs);
echo $arr['counter'];
?>
On what basis, do you expect odbc_num_rows
to return anything other than -1 ?
We have the fact from the manuals, that OBDC does not support @@ROWCOUNT / odbc_num_rows
. So there is no basis for expecting that it "should" return anything other than that which is documented, -1 in all circumstances.
Even if you used Sybase directly (instead of via ODBC), you would have the same "problem".
odbc_num_rows
returns @@ROWCOUNT
, which is the rows inserted/updated/deleted by the immediately preceding command. -1 is the correct, documented value, if the immediately preceding command is not insert/update/delete.
It has nothing to do with rows in a table.
Use another batch, and either one of the documented methods to obtain rows in a table, and load the value into a variable:
Then interrogate the result array, to obtain the variable, not odbc_num_rows
, which will continue returning -1.