vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Hi, Does anyone know of a simple way to do this? I want to create an insert trigger for a table and if the record already exists based on some criteria, I want to update the table with the values that are passed in via the insert trigger without having to use all the 'set' statements for each field (so if we add fields in the future I won't have to update the trigger). In other words, I want the trigger code to look something like this: if exists (select * from TableA where Fld1 = inserted.Fld1) then //don't do insert, do an update instead (would i want to rollback here? and will I have access to the 'inserted' table still?) Update TableA Set TableA.<all the fields> = Inserted.<all the fields> where Fld1 = inserted.Fld1 end if Any help or ideas would be appreciated. Thanks, Teresa |
| |||
| UPDATE requires that you specify the columns by name. It's best practice to do so in an INSERT statement too. Always specify the column names. In the long run this will improve reliability and save you development time. -- David Portas SQL Server MVP -- |
| |||
| takilroy@yahoo.com wrote: > Hi, > > Does anyone know of a simple way to do this? I want to create an > insert trigger for a table and if the record already exists based on > some criteria, I want to update the table with the values that are > passed in via the insert trigger without having to use all the 'set' > statements for each field (so if we add fields in the future I won't > have to update the trigger). In other words, I want the trigger code > to look something like this: > > if exists (select * from TableA where Fld1 = inserted.Fld1) then > //don't do insert, do an update instead (would i want to rollback here? > and will I have access to the 'inserted' table still?) > Update TableA > Set TableA.<all the fields> = Inserted.<all the fields> > where Fld1 = inserted.Fld1 > end if > > Any help or ideas would be appreciated. > Thanks, > Teresa Nice hack. A rollback is no good because you'd lose the update as well. But you could delete the inserted row. You may also have issues with primary keys and other constraints. If a constraint fires before the trigger, your insert will fail on a pk constraint and your clever trigger will never fire. Finally, the performance issue is real. Doing the insert, deleting it, and then updating causes only one real write to the table that has to be committed, but carries three complete journal writes. An update only carries two discreet write. It might be worthwhile to pump a few million operations in each combination so you can at least speak knowledgeably about what the real performance price is. -- Kenneth Downs Secure Data Software, Inc. (Ken)nneth@(Sec)ure(Dat)a(.com) |
| ||||
| On 12 May 2005 08:50:10 -0700, takilroy@yahoo.com wrote: >Hi, > >Does anyone know of a simple way to do this? I want to create an >insert trigger for a table and if the record already exists based on >some criteria, I want to update the table with the values that are >passed in via the insert trigger without having to use all the 'set' >statements for each field (so if we add fields in the future I won't >have to update the trigger). In other words, I want the trigger code >to look something like this: > >if exists (select * from TableA where Fld1 = inserted.Fld1) then >//don't do insert, do an update instead (would i want to rollback here? >and will I have access to the 'inserted' table still?) > Update TableA > Set TableA.<all the fields> = Inserted.<all the fields> > where Fld1 = inserted.Fld1 >end if > >Any help or ideas would be appreciated. >Thanks, >Teresa Hi Teresa, There is no way to avoid listing the columns in an UPDATE statement. If there were, I'd recommend against it (just as I recommend against using SELECT * or INSERT without column-list in production code). Also, your trigger's pseudo-code will do an update for all rows that were inserted if at least one of them exists in TableA. You could remove the existance check; the effect will be the same (rows that are not in TableA won't be changed, rows that are will be - and if no row in inserted is also in TableA, nothing changes in TableA), but it will somewhat improve performance. Also, Kenneth is correct - constraints are checked before the trigger is executed. The only way around that is to use an INSTEAD OF trigger that updates rows that are already present and inserts rows that are not yet present. If you need help transforming this to an INSTEAD OF trigger, just holler. Best, Hugo -- (Remove _NO_ and _SPAM_ to get my e-mail address) |