First, thanks for making the software change so quick... I do appreciate it.

Just to follow up on the bug/feature issue (which you probably didn't want to hear anyway...) :)

I'll point out the following:

1. The MySQL Reference Manual at "http://www.mysql.com/Manual_chapter/manual_Clients.html#mysql_affected_rows", under mysql_affected_rows(), Return values states:

In my case, I got 0 even though 1 record matched the WHERE clause. If the mysql API call is returning 0, this is a bug in either the documentation of Mysql or in the function call.

When I read the documentation, it says what I want. If the call returns the "number of records changed on disk" instead, this is interesting technically that the file writes were optimized for efficiency but is not intuitive and not of much practical use. If I have an application that updates employee records and the manager says to update all 100 employees. I don't want to report back that I updated 93 or 95 or who knows what. I want to say I updated all 100.

2. My recomendation in the context of DBI would be to make the default for $sth->rows return the true affected rows as you have done with the compile options and provide an alternate "Mysql" specific way of getting the "changed disk records".

Based on the little bit I've read from Tim Bunce, I believe this is in line with the way he thinks $sth->rows should work.

Not only that but it would make mysql based DBI programs more compatible with other DBD implementations such as Oracle, Ingres, DB2, etc.

Let the other, "I believe minority" users that need changed rather than affected, compile with the special flag.

My 0.02. Again, thanks for making the change.

Greg

Jochen Wiedmann wrote:

_____________________________________________________________________