Report Lifecycle

A converted report has three independent things to validate: the data supplied by the application, the calculations and layout performed by the engine, and the way the output is delivered and released. A correct preview alone does not establish safe behavior under repeated or concurrent use.

From report request to released resources

1. RequestInputs + report definitionActive
2. Prepare dataRows, variables, schema
3. RenderGroups, formulas, pages
4. DeliverPreview / print / export
5. ReleaseObjects, files, cache

Step 1 of 5Select the adapter

The report request selects a supported definition and adapter. Validate parameters and establish the caller’s authorization.

Allocated: request + definition

A conceptual sequence, not a live runtime trace. Playback advances every four seconds. The full explanation follows below.

Request and Prepare

Select the supported adapter and matching converted report definition. Keep related schemas, images, fonts, and runtime dependencies with the deployment. Establish the input values and the user's right to view the underlying data before generating an export.

PPJ's reporting integration drives the report messages and data binding expected by the adapter. Trace the relevant SAM_Report* handling against the original application. Do not assume every engine fetches the next record at exactly the point its preview displays the next page: an adapter can materialize source data before rendering.

The List & Label integration's XSD contract, for example, describes inputs and report variables; the schema itself does not contain the values. Keep names, types, nulls, and binary fields consistent between the schema and supplied data.

Render

The engine applies formulas, grouping, pagination, and layout to the prepared input. Compare sorted records and group boundaries before diagnosing a total or page-break difference as a rendering defect. Distinguish the unrounded numeric value from its formatted display.

Use a fixed test dataset containing:

• No rows and one row.
• Two groups, including a group spanning a page boundary.
• Null, zero, negative, and fractional values.
• A long text value, Unicode text, and an image.
• Enough rows to exercise multiple pages and a realistic large report.

Save expected totals, group counts, record counts, and representative output pages. Compare each output format actually used; a PDF export and an interactive viewer can take different paths.

Preview, Print, and Export

For desktop preview, the viewer can retain the report while the user navigates pages. For Web, viewer state or an exported document can remain needed after the generating request returns. Disposing everything immediately after starting delivery can break later reads; never disposing it can accumulate memory and files.

Choose the supported ownership contract for the installed engine and adapter. Distinguish server-side printing from a browser print action, and verify printer names, fonts, permissions, and paper settings on the machine that actually renders or prints.

Treat each generated output as one request's result. Use unique temporary names and authorized retrieval. A failed generation must not return a previous request's file simply because the same path already exists.

Measure Memory by Phase

Phase	Resources that may still be live	Useful measurement
Data preparation	Rows, DataSet tables, strings, images, schema and variables.	Row count, image sizes, preparation duration, process/private memory.
Rendering	Source data plus engine objects, layout state and rendered pages.	Peak memory, page count, render duration, page-cache disk use.
Export / preview	Data/pages plus export buffers or viewer state.	Export duration, peak memory, output size, active viewers/reports.
Cleanup	Resources waiting for disposal or cache expiry.	Open handles, remaining files, and memory trend across repeated runs.

Page caching moves some rendered-page pressure to disk; it does not remove the source DataSet. A web viewer cache and a report engine's page cache can also be separate systems. See Stimulsoft Cache Mode.

Measure several concurrent reports under representative load. Do not estimate production capacity by dividing installed memory by one small report's final file size. Managed memory may not fall immediately after disposal, so look for a stable repeated-run trend alongside handle and temporary-file counts.

Finish, Cancel, or Fail

On success, retain only the output and metadata the application intends to keep. Release owned report objects when the consumer is finished, using the adapter's supported close/disposal path. Remove temporary data and cache files according to the engine's lifecycle and your expiry policy.

On cancellation or failure, record the outcome and clean up partially created resources. Test failure while preparing data, during rendering, and during export. If the browser closes without completing a download, a bounded cleanup policy must eventually reclaim abandoned files.

Configure shared engine defaults during application initialization. Changing a static adapter or cache setting for one request can alter another user's report. See Custom Implementations for the reporting abstraction and the limits of direct engine access.

Acceptance Record

For each representative report, record the adapter/engine version, definition revision, dataset identity, culture/fonts, row/group/page totals, outputs tested, timing, peak memory, and cleanup results. Add the record to the application compatibility evidence. This makes an engine upgrade a repeatable comparison rather than a visual guess.