Excel consuming 100% CPU

Hi,
We are using RS Sp2 andExcel XP on the clients.
One report outputs 5000+ rows and are grouped like this:
account group (25 groups)
account (250 groups)
values (4725 rows)
When exported to Excel the XL-file is 11Mb+ !
All groups are collapsed in XL by default, and when trying to work in the
sheet XL consumes all CPU! If all groups are expanded it is possible to work
with the data and there is no unusual CPU consuming.
If collapsing a group again then the CPU consumtion becomes heavy again.
My question, is this a limitation in XL? If it is, does this work better in
XL 2003?
Is there anything we can do to boost performance, as it is now we cant work
in XL...
Any ideas?
/FredrikAt this point this is just an Excel file. It looks like Excel is not
handling that amount of data and that amount of groups very well. You could
ask in Excel newsgroup if XL 2003 might work better for you.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Fredrik" <Fredrik@.discussions.microsoft.com> wrote in message
news:64659432-7804-4443-83D6-454F665C650A@.microsoft.com...
> Hi,
> We are using RS Sp2 andExcel XP on the clients.
> One report outputs 5000+ rows and are grouped like this:
> account group (25 groups)
> account (250 groups)
> values (4725 rows)
> When exported to Excel the XL-file is 11Mb+ !
> All groups are collapsed in XL by default, and when trying to work in the
> sheet XL consumes all CPU! If all groups are expanded it is possible to
> work
> with the data and there is no unusual CPU consuming.
> If collapsing a group again then the CPU consumtion becomes heavy again.
> My question, is this a limitation in XL? If it is, does this work better
> in
> XL 2003?
> Is there anything we can do to boost performance, as it is now we cant
> work
> in XL...
> Any ideas?
> /Fredrik
>|||Tested 2003 but the same problem occured. I would be very happy to now what
the heck is going on in Excel here...
"Bruce L-C [MVP]" wrote:
> At this point this is just an Excel file. It looks like Excel is not
> handling that amount of data and that amount of groups very well. You could
> ask in Excel newsgroup if XL 2003 might work better for you.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Fredrik" <Fredrik@.discussions.microsoft.com> wrote in message
> news:64659432-7804-4443-83D6-454F665C650A@.microsoft.com...
> > Hi,
> > We are using RS Sp2 andExcel XP on the clients.
> > One report outputs 5000+ rows and are grouped like this:
> >
> > account group (25 groups)
> > account (250 groups)
> > values (4725 rows)
> >
> > When exported to Excel the XL-file is 11Mb+ !
> > All groups are collapsed in XL by default, and when trying to work in the
> > sheet XL consumes all CPU! If all groups are expanded it is possible to
> > work
> > with the data and there is no unusual CPU consuming.
> > If collapsing a group again then the CPU consumtion becomes heavy again.
> >
> > My question, is this a limitation in XL? If it is, does this work better
> > in
> > XL 2003?
> > Is there anything we can do to boost performance, as it is now we cant
> > work
> > in XL...
> >
> > Any ideas?
> >
> > /Fredrik
> >
>
>|||The problem may be merged cells or show/hide regions. Excel reports with
thousands of these elements are slow to load because for each new cell they
need to check to see if it intersects with all of the other merged cells.
If you can, removing some of the show/hide elements or other obvious merged
cells and you should see a speed increase in Excel.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Fredrik" <Fredrik@.discussions.microsoft.com> wrote in message
news:3F5CB660-BFB5-4712-A30C-A0081A888A29@.microsoft.com...
> Tested 2003 but the same problem occured. I would be very happy to now
> what
> the heck is going on in Excel here...
> "Bruce L-C [MVP]" wrote:
>> At this point this is just an Excel file. It looks like Excel is not
>> handling that amount of data and that amount of groups very well. You
>> could
>> ask in Excel newsgroup if XL 2003 might work better for you.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Fredrik" <Fredrik@.discussions.microsoft.com> wrote in message
>> news:64659432-7804-4443-83D6-454F665C650A@.microsoft.com...
>> > Hi,
>> > We are using RS Sp2 andExcel XP on the clients.
>> > One report outputs 5000+ rows and are grouped like this:
>> >
>> > account group (25 groups)
>> > account (250 groups)
>> > values (4725 rows)
>> >
>> > When exported to Excel the XL-file is 11Mb+ !
>> > All groups are collapsed in XL by default, and when trying to work in
>> > the
>> > sheet XL consumes all CPU! If all groups are expanded it is possible to
>> > work
>> > with the data and there is no unusual CPU consuming.
>> > If collapsing a group again then the CPU consumtion becomes heavy
>> > again.
>> >
>> > My question, is this a limitation in XL? If it is, does this work
>> > better
>> > in
>> > XL 2003?
>> > Is there anything we can do to boost performance, as it is now we cant
>> > work
>> > in XL...
>> >
>> > Any ideas?
>> >
>> > /Fredrik
>> >
>>

Example code for consuming a SSIS datareader from ASP.net

Hi,
Does anyone have any or know of any demo code that shows how to consume data made available by a SSIS DataReader destination in an ASP.net app.

Thanks in advance.

-Jamie

P.S. Doug if you're reading this, it'd be handy to have some examples such as this in BOL or maybe even something provided with the samples.Re: How do I consume a DataReader Destination in VB.Net? - Microsoft Technical Forums
(http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=64798)

Doug mentions a topic, although I cannot check it right now.|||Cheers Darren.

The link to the article with the code in it is
http://msdn2.microsoft.com/en-us/library/ms215053

-Jamie|||I've struggled with the best description to provide of the issue where you must call DataReader.Read() one last time AFTER the final row of data, to avoid an exception.

Here is the current draft of the text, expanded from the version displayed in the topic that Jamie kind provided the link for:

"The Read method of this implementation of the DataReader returns true one more time after the last row of data has been read. This fact makes it difficult to use the usual code that loops through the DataReader while Read returns true. If your code attempts to close the DataReader or the connection after reading the expected number of rows, without an additional, final call to the Read method, the code will raise an unhandled exception. However if your code attempts to read data on this final iteration through a loop, when Read still returns true but the last row has been passed, the code will raise an unhandled ApplicationException with the message, "The SSIS IDataReader is past the end of the resultset." This behavior is different from that of other DataReader implementations. When using a loop to read through the rows in the DataReader while Read returns true, you need to write code to catch, test, and discard this anticipated ApplicationException on the last successful call to the Read method. Or, if you know in advance the number of rows expected, you can process the rows, then call the Read method one more time before closing the DataReader and the connection."|||Hmm... so much for the MSDN search integrated into BOL. I only have June BOL on hand, and did the online search pick that up, did it hell. Thanks.