Because Sybase does not process the number of returned rows until all rows have been fetched, this function should be avoided if the query returns MANY rows: PHP3 will have to fetch internally all rows coming from the server, keeping results in memory until the result set is fully returned and no more rows are signaled by the SQL Server. If you want to put a limit on the number of rows to really fetch in your application, it will be much faster to first select the count of rows that match the search criters, prior to select effective data. Shame, the current implementation of PHP3 Sybase support functions does not have an option to control whever all rows should be fetched prior to return from the query. More, there's no provision for queries that return multiple results sets, so this function terminates the current query without allowing further results sets to be returned. A good idea would be that this function processes only the current result set, but does not terminate the query, allowing the script to use either a new "sybase_next_result()" or "sybase_free_result()" after processing the current dataset.
The current implementation of this function fetches all pending rows in memory, which updates the counter that is otherwised set up for the sybase_affected_rows(). If you don't call this function, sybase_affected_rows() is not accurate for the current selected result set because all rows have not been internally fetched. If you just want to show the total number of rows displayed on your HTML page, it's a good idea to call it only AFTER all rows have been fetched, because this count is immediately accurate without requiring PHP3 to fetch pending rows and save them in internal memory.