[Phplib-trackers] [ phplib-Bugs-478978 ] function affected_rows() and ODBC

[<no...@so...>]

Bugs item #478978, was opened at 2001-11-07 14:47
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=478978&group_id=31885

Category: DB_SQL
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Richard Archer (richardarcher)
Summary: function affected_rows() and ODBC

Initial Comment:
If you say "Many ODBC drivers don't support 
odbc_num_rows() on SELECT statements" -msaccess97 is 
one- why you use this function to set affected_rows()??
Will be better use your class function num_rows()?

----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-07-12 09:25

Message:
Logged In: YES 
user_id=279311

I've just merged in changes to db_odbc.inc which fixes
num_rows(). It will now return the number of rows from a
select. It does this by counting the number of results if
odbc_num_rows() fails.

affected_rows() however is more problematic. If the data
source doesn't return this value to PHP, then there is no
way to calculate it. You can't walk the result set because
there isn't one.

Closing this one.

----------------------------------------------------------------------

Comment By: Chris Johnson (chaska)
Date: 2002-07-04 06:34

Message:
Logged In: YES 
user_id=279065

Sounds like he says phplib is using odbc_num_rows() to 
set affected_rows().  If so, that's not right.  Need to 
double-check the code.  In my somewhat older than 
current CVS version, this is in fact in error.  From 
db_odbc.inc:

function affected_rows() {
    return odbc_num_rows($this->Query_ID);
}

Unless, of course, PHP does something funky with 
odbc_num_rows() which results in correct behavior after 
an INSERT, UPDATE or DELETE.  Here's what 
www.php.net says on the subject:

odbc_num_rows() will return the number of rows in an 
ODBC result. This function will return -1 on error. For 
INSERT, UPDATE and DELETE statements odbc_num_rows
() returns the number of rows affected. For a SELECT 
clause this can be the number of rows available. 

Note: Using odbc_num_rows() to determine the number of 
rows available after a SELECT will return -1 with many 
drivers. 


So, I'd say this is NOT a bug.  Anyone have an ODBC 
driver to test it with?

..chris

----------------------------------------------------------------------

Comment By: nathan hruby (nhruby)
Date: 2002-07-03 05:14

Message:
Logged In: YES 
user_id=19736

Err.. I don't get it?

affected_rows() returns the number of rows changed by an
UPDATE, INSERT or DELETE statement

num_rows() returns the number of rows from a SELECT statement.  

The phplib num_rows is a thin wrapper around the php
function for the specific database you are using, it doesn't
create a num_rows in php.  A php version could be written;
however it would suffer horrible memory issues and would not
perform well on large queries.

The warning in the documentation I belive is there to make
the users aware that this specific fucntion isn't generally
well implemented by the udnerlying ODBC drivers, and
therefore isn't always availible.

Isn't there also a warning for async db's (like oracle) to
emulate this by getting the count of the intended query? 
Would this also work for the ODBC drivers as well?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403611&aid=478978&group_id=31885