Jarod is right, the primary key is NOT included in the update! I just looked at a generated DAO to confirm this. What I was thinking of was another column that we have set up which is a GUID column but is not the primary key, and I knew for a fact that it was being updated. I forgot that this isn't our primary key though, we have a standard int auto-increment primary key.
On 12/13/06, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote:
As far as I know, Reactor doesn't up date the primary key value of a table. This would render it mostly ineffective, particularly in SQL Server, which restricts write access to the keys of a table unless you tell it to turn the restriction off. J ------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion "That which does not kill me makes me stranger." - Yonah Schmeidler On Dec 13, 2006, at 12:23 AM, Eivind Kjorstad wrote: Brian Kotek wrote: On the last point, you're misunderstanding me. Reactor isn't trying to INSERT the same row with the same primary key twice. It is UPDATING the same row. But when Reactor does the update via a DAO, it updates ALL the columns. Reactor has no way of knowing which columns have changed so it assumes that they all have potentially changed, and creates the update statement accordingly. Some of the columns may contain the same values that are already in the table (like the primary key) but they are still included in the update statement.� It is true that Reactor *does* this -- but that doesn't mean it makes sense. Given a simple table: table: test ------------ ID primary-key, int data text .save() on a dirty testRecord creates SQL equivalent to: update test set ID=#ID#, data=#data" where ID=#ID# Including the primary-key in the set-statements is not merely *sometimes* updating to the same value that was already stored -- it *ALWAYS* updates ID to have the value it already had, the where-statement ensures that. No matter the value of old and new ID, including the primary-key in the columns to be updated is superfluous. Better would be: update test set data=#data" where ID=#ID# i.e. include all fields EXCEPT the primary-key. (or those that are part of the primary-key in the case of multiple fields forming the primary-key) Unless I'm mistaken, this would break nothing, potentially make things sligthly faster, and make non-updatable primary-keys (like the rowguidcols) automagically work. Eivind Kj�rstad -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
