Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Row-By-Row Processing Without Cursor Expand / Collapse
Author
Message
Posted Sunday, December 3, 2006 7:02 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, December 26, 2006 12:11 PM
Points: 7, Visits: 1
Comments posted here are about the content posted at temp
Post #327280
Posted Thursday, December 7, 2006 12:52 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, June 27, 2007 8:31 AM
Points: 1, Visits: 1
Just wondering: How fast is string-processing really in SQL Server (2005)? If I inserted 5000 records at once, would building up this string really be faster than just using a cursor?
Post #328652
Posted Thursday, December 7, 2006 1:49 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 1:44 AM
Points: 162, Visits: 520

I don't think that this row by row operation could really help some one ..
because this code does not give the clear view of row by row operation ...

Instand of using this thing u can use the Table variable while loop which help lot compare to Cursor...

Here is the Logic.....
--Create a Table Variable and Variable Counter

DECLARE @InitialTable TABLE(RowNo INT IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, Field1 int, Field2 Int)
DECLARE @IncrementalCounter INT        'This variable is declare for Loop

--All values are inserted into Your Table Variable ........
Insert into @InitialTable (field1, Feld2)                                              
Select A1, A2 from Your_Table Where  Your_Condition
----------------------------------------------------------
--Initialize the Counter
SET @IncrementalCounter = 1
--Condition of Checking the No of records to be traverse
while @IncrementalCounter <= ISNULL((SELECT COUNT(RowNo) FROM @InitialTable),0)
BEGIN
--Here we set the variable value to the @variable
SELECT @Variable = Field1 FROM @InitalTable where RowNo = @IncrementalCounter

SET @IncrementalCounter = @incrementalCounter +1
END

Post #328661
Posted Thursday, December 7, 2006 2:49 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, December 5, 2013 4:35 AM
Points: 31, Visits: 79
Better still, rewrite usp_Process to optionally accept tabular data, either via a table variable or XML. Okay, not always possible, but when it is it will be far more efficient than repeated calls to the stored procedure


Post #328668
Posted Thursday, December 7, 2006 3:54 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 18, 2007 11:14 PM
Points: 1, Visits: 1
How can it work on the Select?
There's no any trigger to proccess SELECTs.
Post #328675
Posted Thursday, December 7, 2006 5:27 AM


Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, August 11, 2014 3:17 PM
Points: 6, Visits: 23
Of course, dynamic SQL assumes a level of security that we may not want to enable.

The alternative is a traditional procedural while loop, when set operations can not be designed up front.
Post #328696
Posted Thursday, December 7, 2006 5:47 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, June 12, 2009 7:37 AM
Points: 125, Visits: 115
Anyone know if SQL Server plans on designing triggers in the future to include the FOR EACH ROW clause like they do in Oracle that allows you to treat your trigger as if you are dealing with atomic values, rather than a data set?
Post #328701
Posted Thursday, December 7, 2006 6:07 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, May 17, 2011 7:05 AM
Points: 5, Visits: 16
Another "we all hate cursors" article... I have to agree with Martijn's post on this one. Cursors, table variables, temporary tables, and so on... they are tools to be used on certain situations. We shouldn't disregard an option because "it's just bad". Cursors have their use, even if it is to write a non-critical, very small (in terms of data processing) procedure easily.
Post #328707
Posted Thursday, December 7, 2006 6:33 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, June 12, 2009 7:37 AM
Points: 125, Visits: 115
I agree with that.  We use cursors a lot, not for iterating through result sets and performing operations on the data with normal cursors, but for executing business rules.  Here is an article some may find interesting that details how we execute dynamic business rules...   http://articles.techrepublic.com.com/5100-9592_11-6123199.html
Post #328720
Posted Thursday, December 7, 2006 7:04 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, December 5, 2013 4:35 AM
Points: 31, Visits: 79
> Another "we all hate cursors" article

Not necessarilly. I'm not disputing that cursors have their uses, and when you need one then you need one. However it's certainly worth being aware of the cost, and particularly so when writing a trigger. I don't think I'd recommend the route that the author described, as I think it could hide the fact that the real cost is in executing a complex operation n seperate times, and the cost of the cursor is small in comparison. I've certainly come across code like that. However if it's in a time critical piece of code (and unless I knew unequivocably otherwise I'd automatically assume this applied to a trigger) I'd devote some effort to making the stored procedure (to use the example in the article) accept a set of input items and process them in a single pass.



Post #328735
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse