12 messages in com.mysql.lists.perlRe: Drivers giving different results| From | Sent On | Attachments |
|---|---|---|
| Jochen Wiedmann | 25 May 1999 11:10 | |
| Vivek Khera | 25 May 1999 12:01 | |
| Jochen Wiedmann | 25 May 1999 13:18 | |
| Tim Bunce | 25 May 1999 15:10 | |
| Dan Busarow | 28 May 1999 14:25 | |
| Jochen Wiedmann | 29 May 1999 01:36 | |
| Michael Widenius | 31 May 1999 03:25 | |
| Tim Bunce | 02 Jun 1999 03:04 | |
| Michael Widenius | 02 Jun 1999 13:52 | |
| Tim Bunce | 02 Jun 1999 19:24 | |
| Michael Widenius | 03 Jun 1999 06:27 | |
| Tim Bunce | 03 Jun 1999 07:15 |
| Subject: | Re: Drivers giving different results![]() |
|---|---|
| From: | Tim Bunce (Tim....@ig.co.uk) |
| Date: | 06/03/1999 07:15:07 AM |
| List: | com.mysql.lists.perl |
On Thu, Jun 03, 1999 at 04:28:16PM +0300, Michael Widenius wrote:
I can however understand that some applications may want to check the result from the above query (Thats why I added CLIENT_FOUND_ROWS in the first place).
On the other hand, I can also think of applications that really want to know if the status really did change (as this may indicate that some other client did change the status first). This is actually VERY useful and it's a pity that most other databases doesn't support this!
I can see that.
Tim> Assuming it's made an option then the fix for the rare soul who Tim> actually wants a 'physically modified' count will be trivial.
I agree.
I hope Jochen does.
Tim> Meanwhile, I'll leave you with this rather sad bit of code I found in Tim> the Catalog.pm support modules:
Tim> my $affected = $stmt->execute() or ... Tim> # Tim> # Return 1 if update occured at least on a row, even Tim> # if nothing was modified in that row. Tim> # Tim> $ret = 1 unless $affected == 0 and $stmt->{info} =~ /matched: 0 /;
I agree that the above is very sad! It will only work if you are using MySQL with the English language file!
It should be:
$ret = 1 unless $affected == 0 and $stmt->{info} =~ /^[^:]: 0 /;
Almost right. I'll change it to /^[^:]+: 0 / :-)
I think the arguments you've made for the utility of both kinds of counts and the current need to deal with connect-time options and/or parse strings to get them, suggests to me that both values should be available as integers via API functions.
Tim.




