Strange Error Message!

[Former Member]

We have what we call an "Executive Summary Report" that has 9 subreports. For over two years, this report has run fine and served us well. However, yesterday a error appeared in this report when we were running it... The error was...

"The page size was not large enough to format the contents of an object in the report. Page header or footer longer than a page."

What made this error so bizarre is that the subreports have NO headers OR footers. Worse still, when we filter the dataset a little bit, the report prints just fine. The dataset has 10,109 records and it seems if we filter any small amount out, the report prints fine - but when we go back to the normal desired full dataset, this error appears yet again.

Can anyone please provide (1) a translation of this error. What does it actually mean by "format the contents of an object" especially when there is no header or footer. And (2) how do we address this? Can it be that there is some 'magical' number of records in a report that just happen to hit something that causes this error???

Help please!!!

[former_member11696 · Accepted solution]

Hi Bruce,

Quick question.... Did your network guys update the printer servers and printer drivers?

Page area's are dependent on the margins, updated drivers may have changed them. It could be the logic in CR and formatting the pages has an issue for your exact set of records but there must have been something local that changed to have suddenly cause CR to through this error message.

Thank you

Don

[Former Member · Accepted solution]

Don,

Thank you for your reply. Unfortunately, no - there is NO change in printer, or printer driver of any kind. The ONLY change that brings on this error is that its a new dataset we are working with and as I mentioned, if I filter a few records out, this problem goes away. Unfortunately, to get the report I want, I cant filter data like that.

I have reviewed many documents on the web now about this problem, with many suggestions - I tried them all from tweaking report margins, to checking and unchecking "Can Grow" and "Underlay section" boxes - nothing works.

I am in a real bind with this one because this is affecting our "Executive Summary Report", viewed by CEO level people, hence a client is waiting for a resolution to this problem.

Since this has been a problem (according to the web documents I viewed) since version 8, and was not addressed in 9, 10, or 11 - I am now running 12 - is there some actual solution available to what is obviously an odd, but long established problem.

Thanks.

[former_member11696 · Accepted solution]

Hi Bruce,

Not sure if you work in Support or if you are a Developer or both but when posting it does make every ones jobs a lot easier if you include all the info, what you tested, what you found, what references you also found, etc. We have assumed in other posts that those people also did their due diligence and searched but as you can see quite often they just post, it's easier for someone else to search for them. So we have to assume you did not search unless you tell us otherwise.

Now that we know this info and that you are using a new dataset it may have something to do with the problem. So when you say you are using a new data set does this mean you have an updated format, new fields etc., or it's the same dataset but with more rows of data? The other info that would help is to know which driver you are using to connect the report to the data set, crdb_adoplus.dll or crdb_xml.dll or crdb_????.

One of the issues CR has with active datasets is the amount of row. 10K rows is considered a lot of rows for the driver to handle. Info behind this is because of Microsoft's dataset technology CR can't get to the actual memory its saved in and the only way to get to it requires a copy. The result is a huge amount of memory being used up. The other problem is if you try to use more than one record set then CR tries to link all fields which also uses up valuable memory space which is why there are limits to using active data record set.

Here's a few suggested work arounds:

Create a Stored Procedure to get the data, Server side data processing is and always will be much more efficient that doing this client side. DB server are optimized to get the data.

Export your DS to XML and then use the ADO.NET XML driver as the report database source or connect directly to the database using OLE DB or ODBC. Others have used temp tables and simply copied the SQL to get the data and using SQL Commands to populate the temp table. Then CR can be set to the temp table.

Another option is to convert your DS to a Command object and use it as your data source.

Bottom line is you are likely hitting a CR and MS limitation using active data sets. I have .NET C# sample code on converting/setting an existing report to a Command Object and/or using the ReplaceConnection methods in RAS to update the report DS data source to xml.... I've posted them already but rather than ask you to search I'll post them in this thread also for you.

Thank you

Don

[Former Member · Accepted solution]

Don...

Fair enough - let me set the record straight... Yes, I have worked support and still do on occasion, although my primary role is Lead Technologist where I do design and development in .NET technologies of all kinds (among others). Fair enough as well - I will mention next time that I have searched the web for solutions before reporting here.

To the meat of the issue...

I acknowledge that this problem likely lies in the dataset - however, if you read my original post, you can see I mentioned that this report has run fine for over two years - to be more specific - it has run on what must be 50 to 100 different datasets. To answer your questions...

NO - this dataset is the EXACT same layout as ALL other datasets - no differences, no new fields, indexes or ANY changes.

YES - it has LESS rows of data. We deal with datasets up to FOUR MILLION records - and in this problem the count is 10,109.

So not MORE data, LESS data.

These reports - ALL our reports - are fed by Stored Procedures (ADO), hence "dataset" is the result of a Stored Proc.

Thank you for your suggestions - however, we have tried exporting the reports - we cant, because things "choke" on Page 3 of the report generation so you never get the opportunity to print or export. Sometimes (however), the report comes up with 15 pages of data and yet when you go through the viewer and try to go from page 3 to 4, BOOM!!! The error message appears.

NOTE - ALL OF OUR REPORTS are viewed NOT printed, due mainly to their length. Some users DO export them, but very few actually print therm. So we designed our software (called "ReportIT") to be a report viewer, fed by stored procedures and reports are displayed with the built-in Crystal Viewer component.

With respect, I HIGHLY doubt we are hitting any MS limitation as once again, this report has run for two years just fine and with some 50-100 different datasets. It is ONLY with this current 10,109 records that this problem occurs and ONLY when the full set (eg, that number) is run.

I am now almost completely baffled by this problem, have tried all of the solutions on the Crystal site (they dont work) and through Googling this problem (they dont work) - so I have one vital client who cant get at their data.

One last item of note - we have had our QA people scan the data looking for possible corruption - but the SQL Storied Proc returns clean, solid data every time.

Thats about all I can tell you at this point - but I sure would love to get this resolved as the pressure is on...

Thanks!

[former_member11696 · Accepted solution]

Hi Bruce,

Thank you for all of the info... The generic 10K row is something we tell all because of course depending on the complexity of the report, groups sorting formatting etc. 10K is a generic upper limit and highly recommend using the server for more. But with your new info it appears you have it all under control.

Data corruption was my next suggestion but you also looked at that so it appears to be something specific to how the report is laid out and with this specific set of data.

Are you able to duplicate the issue locally or is it only at the customers site? If you can dup it locally on your test machines open up the report in CR designer and start adjust, slightly, the various groups and detail sections. By doing this it will tell us, and it should alter the number of records per page so you may have to adjust more to make the effect, if this is a page rendering issue. This affects is almost everything, Groups per page, details per page, summaries etc. If this fixes or moves the problem then we can start to drill into the specific area.

Or if this doesn't affect the output or no one complains then you have the work around. If you want to continue trying to find the actual cause/solution we can.

And if you want to pursue the issue what we'll need you to do is purchase a support case, you will get a refund, this way we have an escalation starting point with more weight behind it. We also have a means to send logs and reports back and forth. Forums doesn't allow this file transfers.

One more suggestion before you log a case. Try these logging options, for others who see this they won't work for CR for Visual Studio 10.2 or 10.5 but will work for all full versions of CR:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\Crystal Reports\Logging]

[HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\Crystal Reports\Logging\crpe.bkgrnd]

"Destinations"=dword:00000003

"Position"=dword:00000003

"LogErrorsOnly"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\Crystal Reports\Logging\crpe.diagnostics]

"Destinations"=dword:00000003

"Position"=dword:00000003

"LogErrorsOnly"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Business Objects\Suite 12.0\Crystal Reports\Logging\crpe.functions]

"Destinations"=dword:00000003

"LogErrorsOnly"=dword:00000000

"Position"=dword:00000003

Copy the above and give the file name a .reg extension to disable logging just set all the values to from 3 to 0 and save it with Off in the name. Double clicking will add the keys or change them.

Run the report until the message comes up and then look at the end of the log to see if there is any info as to the cause.

One more detail I don't see and to verify. Are you using the CrystalDecisions.Windows.Forms as the viewer or is this a WEB app?

Also, you indicated you have read info indicating this being an issue for many versions. Do you have any link I can look at also?

Thanks again

Don

[Former Member · Accepted solution]

Hi Don...

To investigate other versions do a Google search and type in "The page size was not large enough" and you will get a bunch of hits that all relate to this error. In most of those threads (that I read) people are talking about versions 8 and 9, one mentions 10... and well, you will see right away that many have dealt with this issue - problem being that none of the solutions presented have had any affect for us.

Yes, we can duplicate this problem here on our machines and match exactly what our client is seeing. With that in mind, this morning I will take a shot at some of your suggestions and keep you posted as to how they work (or not). I have already played with margins and checkboxes (as suggested on some of those web postings) and these did not resolve anything - but I did not try playing too much with the groupings. I will do that this morning, however in this report there are three grouped bands and two of them get supressed - but I will tinker with the other one and see what I can get for results.

We also are going to try skinnying down the record set slowly. That is, remove 10 records, check results, remove 10 more and so on - that is, we are trying to nail down if this problem is occuring simply because we have hit some magic number of records. Again, reminding you that this report has been running fine for about two years and as its one of our most popular reports we can say pretty accurately that it has to have been run some 50-100 times without a hitch, so that magic number theory holds water for us, but of course, we need to confirm that.

Yes, we use the CrystalDecisions.Windows.Forms viewer - this is NOT a web app - its a VB.NET Windows Forms app and there is no web version or any web related stuff involved as this is an old-fashioned distributed app.

I will keep you posted as to what we discover (or not) today.

Thanks for your assistance!

- Bruce

[Former Member · Accepted solution]

Don...

Problem resolved.

Here is what we did - we "tightened" up the subreport grouping bands, but that did not solve the problem. Fact is, we only had about 1 pixel we could shrink up on the report, so I didnt have a lot of hope that was going to work.

But then on the actual report that contains the 9 subreports, we shrank each subreport 'box' and tightened those group bands and BINGO - report now prints fine with proper paging. That is, seems that after doing that our report went from 13 pages to 15 pages, but thats because Crystal started a couple of the subreports on new pages.

One other thing we did that might have been significant is that we highlighted the boxes for all subreports and then checked the properties - just to make sure all subreports shared the same properties. What was odd there is that when checking each subreport one-by-one they all appeared to have identical "Can Grow" and "Page Break" properties - but when we highlighted them all, those checkboxes we NOT all checked - instead, the boxes appeared in that solid green block as though one (or more) of the reports had different settings. When then just set them all the same as all the same with all selected in one shot.

Then, we printed the report, and it prints fine.

Between the last time I wrote you and now, I also forwarded the 'corrected' report files to my client. Our Professional Services guy is on-site there and he loaded the updated report files, ran the report and same thing - report now prints fine.

Client is happy, pressure is off me so I am happy and we didnt need to go through cutting out records.

Thanks for your suggestion of tweaking the group boxes - but as said, we tried that at the subreport level before and it did not resolve the problem - however, doing it on the full report (that contains all the subreports) DID solve the problem.

Again thanks - and I am marking this resolved.

- Bruce