home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.databases.ms-sqlserver      Notorious Rube Goldberg contraption      19,505 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 18,229 of 19,505   
   Bob Barrows to Gene Wirchenko   
   Re: SSE 2008: Trigger: Modifying Data to   
   11 Apr 11 14:55:38   
   
   XPost: microsoft.public.sqlserver.programming   
   From: reb01501@NOyahooSPAM.com   
      
   Gene Wirchenko wrote:   
   > On Sun, 10 Apr 2011 08:54:48 -0400, "Bob Barrows"   
   >  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   
   maintainable code that will not blow up just because a new column is added.   
   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..   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca