On 4/5/06 14:07, "Jonathan Mangin" <[EMAIL PROTECTED]> wrote:
> > ----- Original Message ----- > From: "Dr.Ruud" <[EMAIL PROTECTED]> > To: <dbi-users@perl.org> > Sent: Wednesday, April 05, 2006 11:53 AM > Subject: Re: Not exactly a dbi question > > >> Paul DuBois schreef: >> >>> UPDATE tbl_name SET col_name = 0 WHERE col_name = 0; >>> >>> If you've selected the rows-changed count, $sth->rows() will always >>> return 0, because the statement doesn't actually change any col_name >>> value from its current value. >> >> That would be an odd optimization. The update should take place, even if >> the value wouldn't seem to change anything. Hidden fields like "record >> last updated", or triggers, could depend on this. >> >> -- >> Affijn, Ruud >> >> "Gewoon is een tijger." >> > > mySql made this change approx. 3 years ago(?), so it's an old > discussion that I missed. Apparently the whole world agrees > with you. I simply didn't want to populate an application's > change_log with an event that didn't happen. Hence my need > for the old behaviour. > --Jon Well, no. The underlying basis for this behavior is whether you pass the CLIENT_FOUND_ROWS flag to the mysql_real_connect() C API call. This flag has been around for many years (since 3.21); it's nothing new. That's just a point of trivia, though. DBD::mysql lets you select either behavior, so you can have whichever one you want.
