 | |
SSE 2008: Trigger: Modifying Data to be Written
comp.databases.ms-sqlserver comp.databases.ms-sqlserver
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: SSE 2008: Trigger: Modifying Data to be Written -
04-11-2011
, 01:55 PM
|
On Sun, 10 Apr 2011 08:54:48 -0400, "Bob Barrows" reb01501 (AT) NOSPAMyahoo (DOT) com> wrote: Gene Wirchenko wrote: 2) I think that maintainability was covered by the code I borrowed from. My derivative has select * into #Inserted from Inserted at the beginning and then at the end, writes with insert into Accounts select * from #Inserted You consider this to be a good idea? Despite the number of experts in the field that advise against using selstar (select *)? I won't repeat that advice here: it's very easily found. I will say that I have never seen an expert recommend its use. Saying that something never has a valid use is a very broad statement. It would be very easy for someone, even an expert, to miss edge cases where it would be a good idea. This is definitely a case where one wants all columns. Why make maintenance that much more difficult by insisting on listing all of the columns explicitly? It is not a matter of wanting all the columns. It is a matter of writing |
I disagree that listing all the columns makes code less maintainable.
An example where using selstar caused one of my colleagues to spend an
afternoon trying to fix a "bug" in his application occurred when he created
a view that used it, never expecting that he would have to recompile the
view to get it to return columns added after the initial compilation.
I've tested a trigger that uses selstar to select into a test table and it
does seem to behave as you want it to behave, not needing a recompile after
adding a column to the trigger table, so it should work as you desire
providing you solve the other problems Erland pointed out..
#12
| ||||
| ||||
|
|
It is not a matter of wanting all the columns. It is a matter of writing maintainable code that will not blow up just because a new column is added. |
In your scenario, if a column is added and the trigger is not
modified, the table will not be properly updated because of the
missing column.
In mine, the update will still work.
Quote:
|
I disagree that listing all the columns makes code less maintainable. |
this case, one always wants all columns.
Quote:
|
An example where using selstar caused one of my colleagues to spend an afternoon trying to fix a "bug" in his application occurred when he created a view that used it, never expecting that he would have to recompile the view to get it to return columns added after the initial compilation. |
considering there. I do not disagree that selstar is usually a Bad
Thing, just that it is not always so.
Quote:
|
I've tested a trigger that uses selstar to select into a test table and it does seem to behave as you want it to behave, not needing a recompile after adding a column to the trigger table, so it should work as you desire providing you solve the other problems Erland pointed out.. |
Thanks for your posts even if we are disagreeing somewhat.
Sincerely,
Gene Wirchenko
#13
| |||
| |||
|
|
On Mon, 11 Apr 2011 14:55:38 -0400, "Bob Barrows" reb01501 (AT) NOyahooSPAM (DOT) com> wrote: [snip] It is not a matter of wanting all the columns. It is a matter of writing maintainable code that will not blow up just because a new column is added. Ironic. In your scenario, if a column is added and the trigger is not modified, the table will not be properly updated because of the missing column. But it will be expected. That's the difference. We will know upfront that |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.