Re: Odd "rows affected" values using DBI on MySQL

Replies are listed 'Best First'.
Re^2: Odd "rows affected" values using DBI on MySQL by LassiLantar (Monk) on Jul 24, 2004 at 20:08 UTC
Changed my query to `$rows_affected = $dbh->do("UPDATE meters SET description=? WHERE name= + ? and description <> ? ", undef, $info, $meter, $info);` [download] And started getting "0E0" as my return value for rows affected instead of 1. Anyone know why not just 0? Is that just "Zero to the Zero"? In any case, it'll do =) Thanks etcshadow! Peace, LassiLantar P.S. Your signature is brilliant. Every vi user should see that.	[reply] [d/l]
Re^3: Odd "rows affected" values using DBI on MySQL by ercparker (Hermit) on Jul 24, 2004 at 20:41 UTC
"do" returns "0E0" if no rows are affected. This will get your zero: `$rows_affected += 0;` [download]	[reply] [d/l]
Re^4: Odd "rows affected" values using DBI on MySQL by LassiLantar (Monk) on Jul 24, 2004 at 20:46 UTC
Okey dokey. Thanks! (/me smacks himself for not remembering that if you treat it like a number it behaves like a number. I love Perl) LassiLantar	[reply]
Re^3: Odd "rows affected" values using DBI on MySQL by heroin_bob (Sexton) on Jul 25, 2004 at 00:21 UTC
The DBI documentation on cpan might help. It returns the number of rows affected on a successful query, and undef in the event of an error. If there are zero affected rows it returns "0E0", thus returning true for all successful queries. I snagged this off the documentation, which it says the default do method is logically similar to: `sub do { my($dbh, $statement, $attr, @bind_values) = @_; my $sth = $dbh->prepare($statement, $attr) or return undef; $sth->execute(@bind_values) or return undef; my $rows = $sth->rows; ($rows == 0) ? "0E0" : $rows; # always return true if no error }` [download] Hope this helps... ~hb	[reply] [d/l]
Re^3: Odd "rows affected" values using DBI on MySQL by grantm (Parson) on Jul 24, 2004 at 21:49 UTC
'0E0' is zero in scientific notation (ie: 0 * 10^0) but it's special in Perl because in a boolean context it evaluates to True (whereas 0 would obviously be false). This allows you to do something like ... `$dbh->do($sql) or die "Update failed"` ... and it would not call die even if no rows were affected. In practice though when you're using DBI it's simpler and safer to enable RaiseError and use eval to catch the errors.	[reply] [d/l]
Re^4: Odd "rows affected" values using DBI on MySQL by tilly (Archbishop) on Jul 24, 2004 at 21:56 UTC
"0E0" is one of several ways of achieving that effect. "0.0" also comes to mind. And then there is the venerable hack that keeps "0 but true" from generating a warning in numerical context. (Clearly this hack was written and propagated before anyone noticed that there was no need for it...)	[reply]
Re^2: Odd "rows affected" values using DBI on MySQL by CountZero (Bishop) on Jul 24, 2004 at 22:01 UTC
I think that deep down somewhere in the MySQL docs there is a mention that updating an existing record with the same data it already contains, get optimized away (and hence does not trigger an update of the TIMESTAMP field). CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply]