Viracocha

I have been trying to figure this out for a while and can't find anyone that has encountered a similar problem.

I have a VERY simple report with just one table. The table lists user information. The report viewer control says that there are 38 total pages in the report. I can navigate all the way to page 38. The problem occurs when I try to export the report to either excel or pdf.

Excel throws an error that it found Unreadable Content and Reader says that the pdf has become corrupt. If I change the SPROC to allow only the TOP 100, 200, etc. records to be returned, the export works fine. But as soon as I reach a certain number of returned records, I get the error. It also seems as though though the number of returned records that it will allow decreases as the length of each row in the report table increases.

I've opened up the "Unreadable" excel file in Notepad and it looks as though the data had been cut off before it finished.

Is this some sort of memory error I've run out of ideas on work-arounds. Any help would be greatly appreaciated!

Thanks,

Jason



Re: Visual Studio Report Controls Export to Excel or PDF fails from Report Viewer

Lisa Nicholls

>> as though the data had been cut off

It sounds like maybe you're hitting a character that's throwing the renderers.

Is the "certain number of returned records" always exactly the same Does it change if you change the ORDER BY clause in the sproc

>L<






Re: Visual Studio Report Controls Export to Excel or PDF fails from Report Viewer

Viracocha

The number of returned records seems to lessen as I add more columns to each returned row.

e.g.

(first name, last name, email)

will return more than

(first name, last name, email, zipcode)

But, both will not return the entire report. Any ideas

Thanks!

Jason





Re: Visual Studio Report Controls Export to Excel or PDF fails from Report Viewer

Lisa Nicholls

Wow. I still think this might be a red herring, though... did you try the ORDER BY change that I suggested as a test

Note: I am not saying this is a resolution. It is a just for the test. I am trying to figure out if there are some records with some characters in them that are throwing off the renderers. If the number of records returned (with the same number of fields) is always exactly the same, but that number changes with a different ORDER BY clause, then it's pretty certain that we have an issue with a particular character set or piece of data that is making the renderer barf.

Is there anything you want to tell me about the data set that might be pertinent If the number of records returned is always the same (with the same ORDER BY, and with a particular # of columns), have you identified the record on which failure occurs Ideally we'd want to look at the data for the record with the failure, the one before that and the one after that -- plus any grouping expressions that might be evaluating this data, any report expressions associated with it.

I guess -- just in case -- you should also tell us what fonts you're using. Are they unicode, or not That type of thing. I do know that the default renderer is handling the full dataset but the problem is that the pdf renderer may be picking a different variant of that font to optimize for printing.

>L<






Re: Visual Studio Report Controls Export to Excel or PDF fails from Report Viewer

Viracocha

With the current settings, it will export to excel correctly as long as I select only the Top 404 records. I looked at the 405th record and it doesn't have anything other than numbers, letters and an @ symbol. I changed to query to just return that one record for the report and it worked!

Is there maybe some IIS setting that could be prematurely termintating the process I am using .rdlc.

404 record:

[22peapods
] [Sue]
[Jones] [

405 record:

[absher56] [Debbie] [Absher] [lucybell42@domain.com]

The report is using Arial font. Basically, I created an rdlc, added a table to it and dragged and dropped columns from an existing dataset. The columns listed above are the only columns in the report.

I did try order by a different column and that did cause it to throw the error at a lessor return number. But, learning what I learned above, I'm not sure what it means.

Thanks for your help!

Jason





Re: Visual Studio Report Controls Export to Excel or PDF fails from Report Viewer

Lisa Nicholls

>>

I did try order by a different column and that did cause it to throw the error at a lessor return number.

<<

Well, maybe this is going to help. Here's the thing: when you have the order set differently what is the LAST record it shows, what is the record after that and what is the record before that

I'm sorry that this is such a fishing expedition! I could try looking at your report but not sure I would see anything, given your explanation.

Re IIS settings, that would only come into it if it was a server mode report. You say you are using an RDLC. So I'm not sure I understand the question -- -- oh wait, I guess you are using webforms.reportviewer control, right So you mean your iis server, not report services.

Well, I guess that could be it. It could be a timeout. When you do the "regular" view of the report, you're in a kind of "paged" view. So it's maybe not pulling so much down at a time compared to the Excel and PDF. Do you think that might be it in your case

>L<






Re: Visual Studio Report Controls Export to Excel or PDF fails from Report Viewer

Viracocha

Yeah, I'm using the webforms.reportviewer control. But I can't imagine that it would bomb out after only 404 records I wrote another rdlc for another website on a different server that returns over 5000 records. I also set the timeout value in the web.config to a very high number. But, I guess I was just wondering if there was something else that could be happening in IIS, especially because it is also happening in Acrobat Reader.

I'll take a look at the records when I re-order it, but I'm guessing it will be the same as records 404 and 405 in my previous post (i.e. no abnormal characters).

No worries for the fishing. I really appreciate the help because this is maddening.

Thanks,

Jason