18.08.2013 Views

Service Pack Readme (Adapt)

Service Pack Readme (Adapt)

Service Pack Readme (Adapt)

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CE10WIN_EN_SP3<br />

Server functionality<br />

ADAPT00368809<br />

Description:<br />

Patch ID: 36968477<br />

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

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 values.<br />

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

ADAPT00381529<br />

Description:<br />

Patch ID: 37010604<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 problem, when<br />

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

ADAPT00396820<br />

Description:<br />

Patch ID: 37199589<br />

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

with shared variables. In that case, the following error message appears: "Information is needed before this report can be 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 shared variables<br />

do not try to access the database. Reports no longer try to access the database when users drill down on subreports of scheduled reports that are<br />

designed as follows:<br />

- The report has multiple group levels a higher group level has some shared variables or contains subreports that have shared 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 variables. Users can<br />

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 values. In<br />

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!