Design Slow

I'm building a report with dozens of grids and around 8 columns per grid with
3-4 groups each. The report runs fine (slow because of the amount of data
but that's expected). When I am in the report designer editing the report,
simply trying to widen a column, change a label, add a text box or move a
grid is UNBELIEVABLY slow.
Can this be fixed? My guess is Visual Studio is "memorizing" the action
being performed as a type of macro to enable "undos" and based on the volume
of grids, text boxes, etc... it take a long time to do this.How much RAM do you have on your PC?
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Scott" <Scott@.discussions.microsoft.com> wrote in message
news:8673FAFC-37CF-452B-B916-7F5917EDF506@.microsoft.com...
> I'm building a report with dozens of grids and around 8 columns per grid
> with
> 3-4 groups each. The report runs fine (slow because of the amount of data
> but that's expected). When I am in the report designer editing the
> report,
> simply trying to widen a column, change a label, add a text box or move a
> grid is UNBELIEVABLY slow.
> Can this be fixed? My guess is Visual Studio is "memorizing" the action
> being performed as a type of macro to enable "undos" and based on the
> volume
> of grids, text boxes, etc... it take a long time to do this.|||2 gigs. I'm maxed out and it shows a gig free. DEVENV shows using about
132mb when working on just this .rdl report.
"Bruce L-C [MVP]" wrote:
> How much RAM do you have on your PC?
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Scott" <Scott@.discussions.microsoft.com> wrote in message
> news:8673FAFC-37CF-452B-B916-7F5917EDF506@.microsoft.com...
> > I'm building a report with dozens of grids and around 8 columns per grid
> > with
> > 3-4 groups each. The report runs fine (slow because of the amount of data
> > but that's expected). When I am in the report designer editing the
> > report,
> > simply trying to widen a column, change a label, add a text box or move a
> > grid is UNBELIEVABLY slow.
> >
> > Can this be fixed? My guess is Visual Studio is "memorizing" the action
> > being performed as a type of macro to enable "undos" and based on the
> > volume
> > of grids, text boxes, etc... it take a long time to do this.
>
>|||My guess is that you are hitting some sort of resource problem (not a ram
problem however).
Dozens of grids is pretty unusual. One thing you might consider is that
instead of having all these grids on one report is to have a report with
multiple subreports. I hide the subreports in listview so the user does not
see it (that is a property of the report you can get to with report
manager). This enables you to test each subreport independently. Then you
drag and drop subreport onto the main report, hook up the parameters and
away you go.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Scott" <Scott@.discussions.microsoft.com> wrote in message
news:BEC46453-4262-442D-BC5A-0235C7DB5890@.microsoft.com...
>2 gigs. I'm maxed out and it shows a gig free. DEVENV shows using about
> 132mb when working on just this .rdl report.
> "Bruce L-C [MVP]" wrote:
>> How much RAM do you have on your PC?
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Scott" <Scott@.discussions.microsoft.com> wrote in message
>> news:8673FAFC-37CF-452B-B916-7F5917EDF506@.microsoft.com...
>> > I'm building a report with dozens of grids and around 8 columns per
>> > grid
>> > with
>> > 3-4 groups each. The report runs fine (slow because of the amount of
>> > data
>> > but that's expected). When I am in the report designer editing the
>> > report,
>> > simply trying to widen a column, change a label, add a text box or move
>> > a
>> > grid is UNBELIEVABLY slow.
>> >
>> > Can this be fixed? My guess is Visual Studio is "memorizing" the
>> > action
>> > being performed as a type of macro to enable "undos" and based on the
>> > volume
>> > of grids, text boxes, etc... it take a long time to do this.
>>|||Ok, I'm expirementing with the sub report route and design seems faster if I
can work out my layout issues. Each subreport will be calling the same 4
store procs, each of which is a MONSTER. So, my question is if I use
subreports, am I hammering the SQL Server more by calling each ofthese 4
procs "repetitively" for each sub report, rather than a single call to each
proc from a single monster report with dozens of grids.
"Bruce L-C [MVP]" wrote:
> My guess is that you are hitting some sort of resource problem (not a ram
> problem however).
> Dozens of grids is pretty unusual. One thing you might consider is that
> instead of having all these grids on one report is to have a report with
> multiple subreports. I hide the subreports in listview so the user does not
> see it (that is a property of the report you can get to with report
> manager). This enables you to test each subreport independently. Then you
> drag and drop subreport onto the main report, hook up the parameters and
> away you go.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Scott" <Scott@.discussions.microsoft.com> wrote in message
> news:BEC46453-4262-442D-BC5A-0235C7DB5890@.microsoft.com...
> >2 gigs. I'm maxed out and it shows a gig free. DEVENV shows using about
> > 132mb when working on just this .rdl report.
> >
> > "Bruce L-C [MVP]" wrote:
> >
> >> How much RAM do you have on your PC?
> >>
> >>
> >> --
> >> Bruce Loehle-Conger
> >> MVP SQL Server Reporting Services
> >>
> >> "Scott" <Scott@.discussions.microsoft.com> wrote in message
> >> news:8673FAFC-37CF-452B-B916-7F5917EDF506@.microsoft.com...
> >> > I'm building a report with dozens of grids and around 8 columns per
> >> > grid
> >> > with
> >> > 3-4 groups each. The report runs fine (slow because of the amount of
> >> > data
> >> > but that's expected). When I am in the report designer editing the
> >> > report,
> >> > simply trying to widen a column, change a label, add a text box or move
> >> > a
> >> > grid is UNBELIEVABLY slow.
> >> >
> >> > Can this be fixed? My guess is Visual Studio is "memorizing" the
> >> > action
> >> > being performed as a type of macro to enable "undos" and based on the
> >> > volume
> >> > of grids, text boxes, etc... it take a long time to do this.
> >>
> >>
> >>
>
>|||Hmmm, so your grids are tied to the same dataset(s). I.e. in the monster
report you have only 4 datasets for all the grids?
Well, then the answer is yes you will be calling it once for each subreport.
If it would work for you to have 4 subreports where each subreport has all
the grids for one dataset. Then you main report does nothing other than host
the four subreports.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Scott" <Scott@.discussions.microsoft.com> wrote in message
news:1F36FDE2-0CA5-4017-BA68-CF385753A3C0@.microsoft.com...
> Ok, I'm expirementing with the sub report route and design seems faster if
> I
> can work out my layout issues. Each subreport will be calling the same 4
> store procs, each of which is a MONSTER. So, my question is if I use
> subreports, am I hammering the SQL Server more by calling each ofthese 4
> procs "repetitively" for each sub report, rather than a single call to
> each
> proc from a single monster report with dozens of grids.
> "Bruce L-C [MVP]" wrote:
>> My guess is that you are hitting some sort of resource problem (not a ram
>> problem however).
>> Dozens of grids is pretty unusual. One thing you might consider is that
>> instead of having all these grids on one report is to have a report with
>> multiple subreports. I hide the subreports in listview so the user does
>> not
>> see it (that is a property of the report you can get to with report
>> manager). This enables you to test each subreport independently. Then you
>> drag and drop subreport onto the main report, hook up the parameters and
>> away you go.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Scott" <Scott@.discussions.microsoft.com> wrote in message
>> news:BEC46453-4262-442D-BC5A-0235C7DB5890@.microsoft.com...
>> >2 gigs. I'm maxed out and it shows a gig free. DEVENV shows using
>> >about
>> > 132mb when working on just this .rdl report.
>> >
>> > "Bruce L-C [MVP]" wrote:
>> >
>> >> How much RAM do you have on your PC?
>> >>
>> >>
>> >> --
>> >> Bruce Loehle-Conger
>> >> MVP SQL Server Reporting Services
>> >>
>> >> "Scott" <Scott@.discussions.microsoft.com> wrote in message
>> >> news:8673FAFC-37CF-452B-B916-7F5917EDF506@.microsoft.com...
>> >> > I'm building a report with dozens of grids and around 8 columns per
>> >> > grid
>> >> > with
>> >> > 3-4 groups each. The report runs fine (slow because of the amount
>> >> > of
>> >> > data
>> >> > but that's expected). When I am in the report designer editing the
>> >> > report,
>> >> > simply trying to widen a column, change a label, add a text box or
>> >> > move
>> >> > a
>> >> > grid is UNBELIEVABLY slow.
>> >> >
>> >> > Can this be fixed? My guess is Visual Studio is "memorizing" the
>> >> > action
>> >> > being performed as a type of macro to enable "undos" and based on
>> >> > the
>> >> > volume
>> >> > of grids, text boxes, etc... it take a long time to do this.
>> >>
>> >>
>> >>
>>|||Yes, I did some profiling and unfortunately, based on the complexity of the
underlying stored procs, I don't think I can justify calling them each
multiple times in production just speed design/development. I will try to
achieve something similar to what you are saying by trying to use a List
Boxes for a repeated groups...this may cut down on the number of grids and
help me.
Thanks for all your input.
"Bruce L-C [MVP]" wrote:
> Hmmm, so your grids are tied to the same dataset(s). I.e. in the monster
> report you have only 4 datasets for all the grids?
> Well, then the answer is yes you will be calling it once for each subreport.
> If it would work for you to have 4 subreports where each subreport has all
> the grids for one dataset. Then you main report does nothing other than host
> the four subreports.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Scott" <Scott@.discussions.microsoft.com> wrote in message
> news:1F36FDE2-0CA5-4017-BA68-CF385753A3C0@.microsoft.com...
> > Ok, I'm expirementing with the sub report route and design seems faster if
> > I
> > can work out my layout issues. Each subreport will be calling the same 4
> > store procs, each of which is a MONSTER. So, my question is if I use
> > subreports, am I hammering the SQL Server more by calling each ofthese 4
> > procs "repetitively" for each sub report, rather than a single call to
> > each
> > proc from a single monster report with dozens of grids.
> >
> > "Bruce L-C [MVP]" wrote:
> >
> >> My guess is that you are hitting some sort of resource problem (not a ram
> >> problem however).
> >>
> >> Dozens of grids is pretty unusual. One thing you might consider is that
> >> instead of having all these grids on one report is to have a report with
> >> multiple subreports. I hide the subreports in listview so the user does
> >> not
> >> see it (that is a property of the report you can get to with report
> >> manager). This enables you to test each subreport independently. Then you
> >> drag and drop subreport onto the main report, hook up the parameters and
> >> away you go.
> >>
> >>
> >> --
> >> Bruce Loehle-Conger
> >> MVP SQL Server Reporting Services
> >>
> >> "Scott" <Scott@.discussions.microsoft.com> wrote in message
> >> news:BEC46453-4262-442D-BC5A-0235C7DB5890@.microsoft.com...
> >> >2 gigs. I'm maxed out and it shows a gig free. DEVENV shows using
> >> >about
> >> > 132mb when working on just this .rdl report.
> >> >
> >> > "Bruce L-C [MVP]" wrote:
> >> >
> >> >> How much RAM do you have on your PC?
> >> >>
> >> >>
> >> >> --
> >> >> Bruce Loehle-Conger
> >> >> MVP SQL Server Reporting Services
> >> >>
> >> >> "Scott" <Scott@.discussions.microsoft.com> wrote in message
> >> >> news:8673FAFC-37CF-452B-B916-7F5917EDF506@.microsoft.com...
> >> >> > I'm building a report with dozens of grids and around 8 columns per
> >> >> > grid
> >> >> > with
> >> >> > 3-4 groups each. The report runs fine (slow because of the amount
> >> >> > of
> >> >> > data
> >> >> > but that's expected). When I am in the report designer editing the
> >> >> > report,
> >> >> > simply trying to widen a column, change a label, add a text box or
> >> >> > move
> >> >> > a
> >> >> > grid is UNBELIEVABLY slow.
> >> >> >
> >> >> > Can this be fixed? My guess is Visual Studio is "memorizing" the
> >> >> > action
> >> >> > being performed as a type of macro to enable "undos" and based on
> >> >> > the
> >> >> > volume
> >> >> > of grids, text boxes, etc... it take a long time to do this.
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>