Question about optimization

Hi All,
I know that SQL server cursors are general a bad idea and the first thing to
go when optimizing. They're heavy and slow and generally avoidable. On
occasion it can happen that you get stuck with an SP that you need to
optimize and moving it to dynamic SQL is not an option (even though speed
wise it would be better). So here's my question for all those DB experts.
I have logic that requires me to get a list of rows from one table and take
each row and execute another SP using that rows data. Which is faster
1. FAST_FORWARD CURSOR
OR
2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A SELECT
TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
The cursor is easier to understand code and seems like less queries but it's
a dreaded evil cursor. My test db is small so it's hard for me to see major
performance differences so I'm hoping somebody knows the answer already. Even
with my small data, once I got the endless recursion solved, it seems like
the while loop might actually be faster (hard to tell though).
Is there a 3 way to achieve this functionality?
Oh yeah and I can't use the query analyzer to analyze the performance since
some of my inner sp's use temp tables (to avoid using CURSORS).
No one will be able to say for sure... This is one of those things you'll
have to test... If cursors work better, then use them...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"lee" <lee@.discussions.microsoft.com> wrote in message
news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> Hi All,
> I know that SQL server cursors are general a bad idea and the first thing
> to
> go when optimizing. They're heavy and slow and generally avoidable. On
> occasion it can happen that you get stuck with an SP that you need to
> optimize and moving it to dynamic SQL is not an option (even though speed
> wise it would be better). So here's my question for all those DB experts.
> I have logic that requires me to get a list of rows from one table and
> take
> each row and execute another SP using that rows data. Which is faster
> 1. FAST_FORWARD CURSOR
> OR
> 2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A
> SELECT
> TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
> The cursor is easier to understand code and seems like less queries but
> it's
> a dreaded evil cursor. My test db is small so it's hard for me to see
> major
> performance differences so I'm hoping somebody knows the answer already.
> Even
> with my small data, once I got the endless recursion solved, it seems like
> the while loop might actually be faster (hard to tell though).
> Is there a 3 way to achieve this functionality?
> Oh yeah and I can't use the query analyzer to analyze the performance
> since
> some of my inner sp's use temp tables (to avoid using CURSORS).
>
|||"lee" <lee@.discussions.microsoft.com> wrote in message
news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> Hi All,
> I know that SQL server cursors are general a bad idea and the first thing
to
> go when optimizing. They're heavy and slow and generally avoidable. On
> occasion it can happen that you get stuck with an SP that you need to
> optimize and moving it to dynamic SQL is not an option (even though speed
> wise it would be better). So here's my question for all those DB experts.
> I have logic that requires me to get a list of rows from one table and
take
> each row and execute another SP using that rows data. Which is faster
> 1. FAST_FORWARD CURSOR
> OR
> 2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A
SELECT
> TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
> The cursor is easier to understand code and seems like less queries but
it's
> a dreaded evil cursor. My test db is small so it's hard for me to see
major
> performance differences so I'm hoping somebody knows the answer already.
Even
> with my small data, once I got the endless recursion solved, it seems like
> the while loop might actually be faster (hard to tell though).
> Is there a 3 way to achieve this functionality?
> Oh yeah and I can't use the query analyzer to analyze the performance
since
> some of my inner sp's use temp tables (to avoid using CURSORS).
>
Instead of doing a TOP 1 and then deleting, you could create an IDENTITY
column and skip the delete. It will probably be faster than doing the
deletes on a large lookup table.
DECLARE @.tmp TABLE (IDCol IDENTITY(1,1), SomeValue nvarchar(100))
DECLARE @.i int
DECLARE @.Lookup nvarchar(100)
INSERT @.tmp (SomeValue)
SELECT Value FROM LookupTable
SELECT @.i = COUNT(*) FROM @.tmp
WHILE @.i > 0
BEGIN
-- Get lookup value from temp table
SELECT @.Lookup = Value FROM @.tmp WHERE @.tmp.IDCol = @.i
-- Process
EXEC SomeProc @.Lookup
SET @.i = @.i - 1
END
Rick Sawtell
MCT, MCSD, MCDBA
|||As I was reviewing my SPs, I realized that and implemented something similar.
Speed increase when I did that was minimal but any speed increase is welcomed
at this stage.
I've just done what I didn't want to do. I've started grouping a lot of the
SP's into single large SPs that can handle some of the load in batch queries.
Speed increase is dramatic when doing this.
I've gone from 23 seconds (on my dev machine with no indexes) to traverse
20000 records in 16 tables to about 11 seconds. Speed is better but the
maintenance team is going to hate me for this.
FYI: From my tests the FAST_FOWARD cursor is faster then the While loop.
I've left the While loop in places with Large amount of rows and Cursor in
places with small amount of rows. Seems to be the best of both worlds so far.
"Rick Sawtell" wrote:

> "lee" <lee@.discussions.microsoft.com> wrote in message
> news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> to
> take
> SELECT
> it's
> major
> Even
> since
> Instead of doing a TOP 1 and then deleting, you could create an IDENTITY
> column and skip the delete. It will probably be faster than doing the
> deletes on a large lookup table.
> DECLARE @.tmp TABLE (IDCol IDENTITY(1,1), SomeValue nvarchar(100))
> DECLARE @.i int
> DECLARE @.Lookup nvarchar(100)
>
> INSERT @.tmp (SomeValue)
> SELECT Value FROM LookupTable
> SELECT @.i = COUNT(*) FROM @.tmp
> WHILE @.i > 0
> BEGIN
> -- Get lookup value from temp table
> SELECT @.Lookup = Value FROM @.tmp WHERE @.tmp.IDCol = @.i
> -- Process
> EXEC SomeProc @.Lookup
> SET @.i = @.i - 1
> END
>
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
>
>
>

Question about optimization

Hi All,
I know that SQL server cursors are general a bad idea and the first thing to
go when optimizing. They're heavy and slow and generally avoidable. On
occasion it can happen that you get stuck with an SP that you need to
optimize and moving it to dynamic SQL is not an option (even though speed
wise it would be better). So here's my question for all those DB experts.
I have logic that requires me to get a list of rows from one table and take
each row and execute another SP using that rows data. Which is faster
1. FAST_FORWARD CURSOR
OR
2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A SELECT
TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
The cursor is easier to understand code and seems like less queries but it's
a dreaded evil cursor. My test db is small so it's hard for me to see major
performance differences so I'm hoping somebody knows the answer already. Eve
n
with my small data, once I got the endless recursion solved, it seems like
the while loop might actually be faster (hard to tell though).
Is there a 3 way to achieve this functionality?
Oh yeah and I can't use the query analyzer to analyze the performance since
some of my inner sp's use temp tables (to avoid using CURSORS).No one will be able to say for sure... This is one of those things you'll
have to test... If cursors work better, then use them...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"lee" <lee@.discussions.microsoft.com> wrote in message
news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> Hi All,
> I know that SQL server cursors are general a bad idea and the first thing
> to
> go when optimizing. They're heavy and slow and generally avoidable. On
> occasion it can happen that you get stuck with an SP that you need to
> optimize and moving it to dynamic SQL is not an option (even though speed
> wise it would be better). So here's my question for all those DB experts.
> I have logic that requires me to get a list of rows from one table and
> take
> each row and execute another SP using that rows data. Which is faster
> 1. FAST_FORWARD CURSOR
> OR
> 2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A
> SELECT
> TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
> The cursor is easier to understand code and seems like less queries but
> it's
> a dreaded evil cursor. My test db is small so it's hard for me to see
> major
> performance differences so I'm hoping somebody knows the answer already.
> Even
> with my small data, once I got the endless recursion solved, it seems like
> the while loop might actually be faster (hard to tell though).
> Is there a 3 way to achieve this functionality?
> Oh yeah and I can't use the query analyzer to analyze the performance
> since
> some of my inner sp's use temp tables (to avoid using CURSORS).
>|||"lee" <lee@.discussions.microsoft.com> wrote in message
news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> Hi All,
> I know that SQL server cursors are general a bad idea and the first thing
to
> go when optimizing. They're heavy and slow and generally avoidable. On
> occasion it can happen that you get stuck with an SP that you need to
> optimize and moving it to dynamic SQL is not an option (even though speed
> wise it would be better). So here's my question for all those DB experts.
> I have logic that requires me to get a list of rows from one table and
take
> each row and execute another SP using that rows data. Which is faster
> 1. FAST_FORWARD CURSOR
> OR
> 2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A
SELECT
> TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
> The cursor is easier to understand code and seems like less queries but
it's
> a dreaded evil cursor. My test db is small so it's hard for me to see
major
> performance differences so I'm hoping somebody knows the answer already.
Even
> with my small data, once I got the endless recursion solved, it seems like
> the while loop might actually be faster (hard to tell though).
> Is there a 3 way to achieve this functionality?
> Oh yeah and I can't use the query analyzer to analyze the performance
since
> some of my inner sp's use temp tables (to avoid using CURSORS).
>
Instead of doing a TOP 1 and then deleting, you could create an IDENTITY
column and skip the delete. It will probably be faster than doing the
deletes on a large lookup table.
DECLARE @.tmp TABLE (IDCol IDENTITY(1,1), SomeValue nvarchar(100))
DECLARE @.i int
DECLARE @.Lookup nvarchar(100)
INSERT @.tmp (SomeValue)
SELECT Value FROM LookupTable
SELECT @.i = COUNT(*) FROM @.tmp
WHILE @.i > 0
BEGIN
-- Get lookup value from temp table
SELECT @.Lookup = Value FROM @.tmp WHERE @.tmp.IDCol = @.i
-- Process
EXEC SomeProc @.Lookup
SET @.i = @.i - 1
END
Rick Sawtell
MCT, MCSD, MCDBA|||As I was reviewing my SPs, I realized that and implemented something similar
.
Speed increase when I did that was minimal but any speed increase is welcome
d
at this stage.
I've just done what I didn't want to do. I've started grouping a lot of the
SP's into single large SPs that can handle some of the load in batch queries
.
Speed increase is dramatic when doing this.
I've gone from 23 seconds (on my dev machine with no indexes) to traverse
20000 records in 16 tables to about 11 seconds. Speed is better but the
maintenance team is going to hate me for this.
FYI: From my tests the FAST_FOWARD cursor is faster then the While loop.
I've left the While loop in places with Large amount of rows and Cursor in
places with small amount of rows. Seems to be the best of both worlds so far
.
"Rick Sawtell" wrote:

> "lee" <lee@.discussions.microsoft.com> wrote in message
> news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> to
> take
> SELECT
> it's
> major
> Even
> since
> Instead of doing a TOP 1 and then deleting, you could create an IDENTITY
> column and skip the delete. It will probably be faster than doing the
> deletes on a large lookup table.
> DECLARE @.tmp TABLE (IDCol IDENTITY(1,1), SomeValue nvarchar(100))
> DECLARE @.i int
> DECLARE @.Lookup nvarchar(100)
>
> INSERT @.tmp (SomeValue)
> SELECT Value FROM LookupTable
> SELECT @.i = COUNT(*) FROM @.tmp
> WHILE @.i > 0
> BEGIN
> -- Get lookup value from temp table
> SELECT @.Lookup = Value FROM @.tmp WHERE @.tmp.IDCol = @.i
> -- Process
> EXEC SomeProc @.Lookup
> SET @.i = @.i - 1
> END
>
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
>
>
>sql

Question about optimization

Hi All,
I know that SQL server cursors are general a bad idea and the first thing to
go when optimizing. They're heavy and slow and generally avoidable. On
occasion it can happen that you get stuck with an SP that you need to
optimize and moving it to dynamic SQL is not an option (even though speed
wise it would be better). So here's my question for all those DB experts.
I have logic that requires me to get a list of rows from one table and take
each row and execute another SP using that rows data. Which is faster
1. FAST_FORWARD CURSOR
OR
2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A SELECT
TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
The cursor is easier to understand code and seems like less queries but it's
a dreaded evil cursor. My test db is small so it's hard for me to see major
performance differences so I'm hoping somebody knows the answer already. Even
with my small data, once I got the endless recursion solved, it seems like
the while loop might actually be faster (hard to tell though).
Is there a 3 way to achieve this functionality?
Oh yeah and I can't use the query analyzer to analyze the performance since
some of my inner sp's use temp tables (to avoid using CURSORS).No one will be able to say for sure... This is one of those things you'll
have to test... If cursors work better, then use them...
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"lee" <lee@.discussions.microsoft.com> wrote in message
news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> Hi All,
> I know that SQL server cursors are general a bad idea and the first thing
> to
> go when optimizing. They're heavy and slow and generally avoidable. On
> occasion it can happen that you get stuck with an SP that you need to
> optimize and moving it to dynamic SQL is not an option (even though speed
> wise it would be better). So here's my question for all those DB experts.
> I have logic that requires me to get a list of rows from one table and
> take
> each row and execute another SP using that rows data. Which is faster
> 1. FAST_FORWARD CURSOR
> OR
> 2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A
> SELECT
> TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
> The cursor is easier to understand code and seems like less queries but
> it's
> a dreaded evil cursor. My test db is small so it's hard for me to see
> major
> performance differences so I'm hoping somebody knows the answer already.
> Even
> with my small data, once I got the endless recursion solved, it seems like
> the while loop might actually be faster (hard to tell though).
> Is there a 3 way to achieve this functionality?
> Oh yeah and I can't use the query analyzer to analyze the performance
> since
> some of my inner sp's use temp tables (to avoid using CURSORS).
>|||"lee" <lee@.discussions.microsoft.com> wrote in message
news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> Hi All,
> I know that SQL server cursors are general a bad idea and the first thing
to
> go when optimizing. They're heavy and slow and generally avoidable. On
> occasion it can happen that you get stuck with an SP that you need to
> optimize and moving it to dynamic SQL is not an option (even though speed
> wise it would be better). So here's my question for all those DB experts.
> I have logic that requires me to get a list of rows from one table and
take
> each row and execute another SP using that rows data. Which is faster
> 1. FAST_FORWARD CURSOR
> OR
> 2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A
SELECT
> TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
> The cursor is easier to understand code and seems like less queries but
it's
> a dreaded evil cursor. My test db is small so it's hard for me to see
major
> performance differences so I'm hoping somebody knows the answer already.
Even
> with my small data, once I got the endless recursion solved, it seems like
> the while loop might actually be faster (hard to tell though).
> Is there a 3 way to achieve this functionality?
> Oh yeah and I can't use the query analyzer to analyze the performance
since
> some of my inner sp's use temp tables (to avoid using CURSORS).
>
Instead of doing a TOP 1 and then deleting, you could create an IDENTITY
column and skip the delete. It will probably be faster than doing the
deletes on a large lookup table.
DECLARE @.tmp TABLE (IDCol IDENTITY(1,1), SomeValue nvarchar(100))
DECLARE @.i int
DECLARE @.Lookup nvarchar(100)
INSERT @.tmp (SomeValue)
SELECT Value FROM LookupTable
SELECT @.i = COUNT(*) FROM @.tmp
WHILE @.i > 0
BEGIN
-- Get lookup value from temp table
SELECT @.Lookup = Value FROM @.tmp WHERE @.tmp.IDCol = @.i
-- Process
EXEC SomeProc @.Lookup
SET @.i = @.i - 1
END
Rick Sawtell
MCT, MCSD, MCDBA|||As I was reviewing my SPs, I realized that and implemented something similar.
Speed increase when I did that was minimal but any speed increase is welcomed
at this stage.
I've just done what I didn't want to do. I've started grouping a lot of the
SP's into single large SPs that can handle some of the load in batch queries.
Speed increase is dramatic when doing this.
I've gone from 23 seconds (on my dev machine with no indexes) to traverse
20000 records in 16 tables to about 11 seconds. Speed is better but the
maintenance team is going to hate me for this.
FYI: From my tests the FAST_FOWARD cursor is faster then the While loop.
I've left the While loop in places with Large amount of rows and Cursor in
places with small amount of rows. Seems to be the best of both worlds so far.
"Rick Sawtell" wrote:
> "lee" <lee@.discussions.microsoft.com> wrote in message
> news:64E22F44-072E-44E5-AA43-EE7EE5398F5C@.microsoft.com...
> > Hi All,
> >
> > I know that SQL server cursors are general a bad idea and the first thing
> to
> > go when optimizing. They're heavy and slow and generally avoidable. On
> > occasion it can happen that you get stuck with an SP that you need to
> > optimize and moving it to dynamic SQL is not an option (even though speed
> > wise it would be better). So here's my question for all those DB experts.
> >
> > I have logic that requires me to get a list of rows from one table and
> take
> > each row and execute another SP using that rows data. Which is faster
> >
> > 1. FAST_FORWARD CURSOR
> > OR
> > 2. WHILE LOOP THAT CHECKS TILL COUNT = 0 AND INSIDE THE LOOP DOING A
> SELECT
> > TOP 1 TO GET MY ROW DATA AND REMOVING THE ROW FROM THE TEMP TABLE
> >
> > The cursor is easier to understand code and seems like less queries but
> it's
> > a dreaded evil cursor. My test db is small so it's hard for me to see
> major
> > performance differences so I'm hoping somebody knows the answer already.
> Even
> > with my small data, once I got the endless recursion solved, it seems like
> > the while loop might actually be faster (hard to tell though).
> >
> > Is there a 3 way to achieve this functionality?
> >
> > Oh yeah and I can't use the query analyzer to analyze the performance
> since
> > some of my inner sp's use temp tables (to avoid using CURSORS).
> >
> >
> Instead of doing a TOP 1 and then deleting, you could create an IDENTITY
> column and skip the delete. It will probably be faster than doing the
> deletes on a large lookup table.
> DECLARE @.tmp TABLE (IDCol IDENTITY(1,1), SomeValue nvarchar(100))
> DECLARE @.i int
> DECLARE @.Lookup nvarchar(100)
>
> INSERT @.tmp (SomeValue)
> SELECT Value FROM LookupTable
> SELECT @.i = COUNT(*) FROM @.tmp
> WHILE @.i > 0
> BEGIN
> -- Get lookup value from temp table
> SELECT @.Lookup = Value FROM @.tmp WHERE @.tmp.IDCol = @.i
> -- Process
> EXEC SomeProc @.Lookup
> SET @.i = @.i - 1
> END
>
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
>
>
>

Question about dataasource and the .rdl file and the .rdl.data

Hi !

Maybe the only one who can answer this question is people from Microsoft but if someone have an idea just tell me ^_^ i really need a solution.

We have over 500 Access reports. I have imported all those reports but since there is some difference between Access and reportServer we have to make some changes on the reports.

Since i'll be too long to change all the reports one by one. I've created un program in .NET that open all the .rdl file. Those files are in XML so it's pretty easy to change all the things that doesn't work in ReportServer. So i've tried my program and everything is working fine except for the DataSource. When i look at the tag DataSource generated in the .rdl it seems that when we databind the report with the datasource it adds a Unique DataSource ID and also a new file .rdl.data
I've binded 2 reports with the same datasource and notice that the datasource ID is always different.

What i want to know is since all our report will use the same datasource (Shared). Can i use the same datasource ID for all the report and just copy one of those .rdl.date files for each report ?

I really need an answer because i'm afraid to have to changed all those reports one by one -_-

Thank a lot and Sorry about my english.

If the data sources are all the same, you can use a single shared data source.

The rdl.data file is used only by Report Designer. When you go live and publish the reports, you will not need the rdl.data files to view the reports. If you are using Access as the data source , you will need to have a path to the file all users can reach.

|||Thank for your answer!

I have already declare a shared datasource in our reportServer project. My problem is when i imported our access report in reportsercer the datasource set in the report is not the shared datasource. So i've tried to change in the XML code the tDatasource tag to bind our shared datasource but it doesn't work because i don't have an ID (i think).
I tried to bind 2 reports using visual studio to the shared datasource and notice that when you bind the report to the datasource a Datasource ID is added to the xml file. It seems that this ID is unique (Something like c5wcw-6fjhwj3-dwqw-ds2d2). So can i use the same id for all my reports?
|||I took a look at my current sub-project, 3 of 4 reports had exactly the same ID for the shared Datasource and one had another ID, so I copied the ID of the 3 others into that rdl and everything was still working.. I don't know how MS generates that IDs and what they are good for, but it seems you can use the same ID in all reports.. In my case neither the ID of the 3reports nor the ID for the last report matched the ID in the rds-File for the Datasource, so
just try to use the same <Datasources>...</Datasources> for all Reports..
|||

ok ! Thanks! I'll try this today and i'll post if it work or not.

Thanks !

|||

Everything is working fine !!!

Thank a lot !