May 2, 2008 at 10:32 am
Jeff Moden (4/30/2008)
See the following URL... almost identical situation...http://www.sqlservercentral.com/Forums/Topic491969-149-1.aspx#bm492576
Jeff:
FYI, the "Post #" links like this do not seem to be working, they just take to the beginning of the Topic. When I use the Post-links on the lower left-hand side of the posts, it gives me something like this: http://www.sqlservercentral.com/Forums/FindPost492576.aspx which seems to work better.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
May 2, 2008 at 6:52 pm
Funny, they work fine for me... they take me right to the post I wanted.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2008 at 6:54 pm
poornima.s_pdi (5/1/2008)
Hi Jeff,Thanks a lot for ur reply.I learnt more from ur sites.very good snd useful forum...
Thank you for the feed back, Poornima... are you all set now?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2008 at 1:06 am
Hi,
Your post satisfied my need.Once again 'Thank u' for ur timely help.
May 4, 2008 at 1:21 pm
Jeff Moden (5/2/2008)
Funny, they work fine for me... they take me right to the post I wanted.
I think that it has to do with paging. Anchors, like page#postnumber won't work if the topic spans multiple pages and the target post is not on the first page. Since "Posts per Page" is customizable, it might be paging differently for us.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
September 2, 2008 at 3:12 pm
Jeff Moden (1/2/2008)
The real point here is that you should not be using any form of RBAR in a trigger... no matter how you do it, calling a RBAR proc from a trigger is an insane thing to do... the proc should be rewritten to handle sets of data instead of the slothful agony of single row processing. 😉
Jumping in here way late, but there is no doubt that RBAR processing whether a cursor or while loop in a trigger is a very bad idea. You are better off staging the data and processing it in a separate process whether that's Service Broker or another option.
Something I do not recall seeing mentioned is that you can do a Select Into temp_table from inserted\deleted then access that temp table in a stored procedure called from the trigger where you can do some set-based processing, of course that's only necessary if you want to encapsulate the code so you can re-use it because you can process it the same way in the trigger.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
September 12, 2009 at 3:52 pm
Interesting... it'd be easier if SQL Server implemented triggers in the same way Oracle did.
September 12, 2009 at 4:41 pm
Roy Oliver (9/12/2009)
Interesting... it'd be easier if SQL Server implemented triggers in the same way Oracle did.
Why? They are inherently RBAR. "For Each Row".
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2009 at 8:18 am
Jeff Moden (9/12/2009)
Roy Oliver (9/12/2009)
Interesting... it'd be easier if SQL Server implemented triggers in the same way Oracle did.Why? They are inherently RBAR. "For Each Row".
True, yet isn't the performance faster than the SQL Server Cursor?
September 14, 2009 at 9:05 pm
Roy Oliver (9/14/2009)
Jeff Moden (9/12/2009)
Roy Oliver (9/12/2009)
Interesting... it'd be easier if SQL Server implemented triggers in the same way Oracle did.Why? They are inherently RBAR. "For Each Row".
True, yet isn't the performance faster than the SQL Server Cursor?
I don't know, Roy. Comparing anything in Oracle with SQL Server is pretty hard to do. A better question might be, are they faster than an Oracle Cursor? ... and the answer is "I don't know for sure in Oracle" because I've never tested triggers vs set-based code in Oracle, but I don't believe so. I can say I have tested Cursors vs Set-Based in Oracle... properly written set-based code blows cursors away even in Oracle. It's pretty much a myth that Oracle has been "optimized" for cursors so far as speed is concerned.
Most RDBMS's work best with Set-Based code... it would be a real shame if they changed the current set-based mechanism built into SQL Server triggers into similar RBAR code as they did in Oracle if for no other reason other than to simply NOT get into the habit of writting RBAR anywhere.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 15, 2009 at 7:29 am
Jeff Moden (9/14/2009)
Roy Oliver (9/14/2009)
Jeff Moden (9/12/2009)
Roy Oliver (9/12/2009)
Interesting... it'd be easier if SQL Server implemented triggers in the same way Oracle did.Why? They are inherently RBAR. "For Each Row".
True, yet isn't the performance faster than the SQL Server Cursor?
I don't know, Roy. Comparing anything in Oracle with SQL Server is pretty hard to do. A better question might be, are they faster than an Oracle Cursor? ... and the answer is "I don't know for sure in Oracle" because I've never tested triggers vs set-based code in Oracle, but I don't believe so. I can say I have tested Cursors vs Set-Based in Oracle... properly written set-based code blows cursors away even in Oracle. It's pretty much a myth that Oracle has been "optimized" for cursors so far as speed is concerned.
Most RDBMS's work best with Set-Based code... it would be a real shame if they changed the current set-based mechanism built into SQL Server triggers into similar RBAR code as they did in Oracle if for no other reason other than to simply NOT get into the habit of writting RBAR anywhere.
Yeah, that's a good point.
Thanks
Viewing 11 posts - 61 through 70 (of 70 total)
You must be logged in to reply to this topic. Login to reply