18.08.2013 Views

CE10WIN_EN_SP6

CE10WIN_EN_SP6

CE10WIN_EN_SP6

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>CE10WIN</strong>_<strong>EN</strong>_SP3<br />

Server functionality<br />

ADAPT00368809 Patch ID: 36968477<br />

Description:<br />

Scheduled or recurring instances that are created when instances fail will not be processed when file events are used. This is because<br />

retry values have been set.<br />

New Behavior:<br />

This problem is resolved.<br />

The problem was due to file event dependencies that are enforced for the recurring or scheduled instance that was created due to retry<br />

values. Changes were made so the scheduled or recurring instances that are created due to a retry will not require the file event as a<br />

dependency.<br />

ADAPT00381529 Patch ID: 37010604<br />

Description:<br />

On the Job Server, users have no option to select the custom paper size for the RAS server.<br />

New Behavior:<br />

This problem is resolved.<br />

Known Limitations:<br />

To print and export reports, the custom paper size that is defined through RAS may truncate contents on the page. To avoid that<br />

problem, when users modify a report through RAS, they must work to the paper size that is defined in Crystal Reports.<br />

ADAPT00396820 Patch ID: 37199589<br />

Description:<br />

In Crystal Enterprise, successfully scheduled instances of a report cannot be viewed if the report contains multiple group levels and a<br />

subreport with shared variables. In that case, the following error message appears: "Information is needed before this report can be<br />

processed."<br />

The cause of the problem is that the subreport instance tries to access the database, but fails under those circumstances.<br />

New Behavior:<br />

To enable scheduled instances of reports to be viewed, scheduled reports that contain multiple group levels and subreports with<br />

shared variables do not try to access the database. Reports no longer try to access the database when users drill down on subreports<br />

of scheduled reports that are designed as follows:<br />

- The report has multiple group levels a higher group level has some shared variables or contains subreports that have shared<br />

variables.<br />

- The report has a lower group level that contains multiple subreports that may or may not contain shared variables.<br />

- The report has multiple group levels, with a lower group level that contains a subreport with linked parameters and shared<br />

variables. Users can drill down on a higher group level and then preview that subreport in the lower level.<br />

Known Limitations:<br />

Incorrect behaviour may occur if multiple subreport instances use the same linked parameter values but use different shared variable<br />

values. In that case, the report may attempt to access the database.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!