The issue is that the code doesn't know (and doesn't care) if the data
is actually being changed, it's just accepting the posted form data,
compiling it, and updating the record. It uses the return value (number
of rows updated) to make sure there wasn't a problem updating the
record. However
I'm not following why you need to force an update? You mentioned a row
refresh, but I'm not sure in what context. If you are looking to find
out if a row has changed since you last read it, then you should have a
timestamp field. The first timestamp field is always updated when data
changes in
At 14:49 -0500 9/20/04, Jeff Demel wrote:
That's what I was afraid of.
Now I have to add a bunch of code to check the data before sending
(pull the record, compare the data, then decide to run the update or
not). How efficient is that, I wonder?
Is there any way to force it to update the row?
I'
That's what I was afraid of.
Now I have to add a bunch of code to check the data before sending (pull
the record, compare the data, then decide to run the update or not).
How efficient is that, I wonder?
Is there any way to force it to update the row?
I'm thinking a workaround might be to add a
No, MySQL will indicate if anything in the row has changed. If you are
updating with the same data, than nothing changes and MySQL doesn't
waste the time to lock the table, write the data and update the
indexes. It's much more efficient this way.
On Sep 20, 2004, at 3:22 PM, Jeff Demel wrote:
I
I'm seeing some odd behavior when I run an UPDATE query, and need to
know if this is something that MySQL does. It could be something the
MySQLDirect .NET provider is doing, and to cover that possibility I've
sent an email to their support team.
So anyway, here's the scenario.
If I run an UPDA
