SyteLine 'An error has occurred during report processing': how to find the real cause

Step 1: Get the whole error

The first line tells you almost nothing. The useful part is further down:

1. Open Background Task History, filter to the user and the report's task, and open the failed record. Read the full message, including any inner error.
2. If it's still generic, check the SSRS execution log on the report server. Look in the ExecutionLog3 view of the ReportServer database for the time of the failure, or in the report server's log files.
3. Note exactly what the user entered: every parameter, including blanks.

Typical inner messages look like "Cannot create a connection to data source", "Query execution failed for dataset", "The value provided for the report parameter is not valid", or a SQL error number. Each points at one of the groups below.

Step 2: Match the cause

1. "Cannot create a connection to data source"

The report can't reach the database. Common reasons:

• The shared data source on the report server has the wrong server or database name, which often happens after a server move, restore or upgrade.
• The stored credentials expired or the password changed.
• A test environment's reports still point at production, or the other way round.

Fix: open the data source on the report server, correct the connection, and use Test Connection. Check every SyteLine data source, not just one.

2. "Query execution failed for dataset"

The report connected, but its query or stored procedure failed. The inner message usually names a SQL error.

Fix: find the stored procedure behind the report (see Background Task Definitions), run it in SQL Server Management Studio on a test copy with the same parameters, and read the real SQL error. Typical culprits are an invalid column after an upgrade, a divide-by-zero on unusual data, a conversion error from bad data in one record, or a timeout on a very large range.

3. Parameter errors

Messages like "The value provided for the report parameter is not valid" or "parameter is missing a value" mean the report form passed something the report didn't expect.

Fix: compare the parameters the form sends with the ones the report file defines. This breaks most often when someone adds a parameter to a custom report but not to its form, or the reverse. Blank date ranges and unexpected nulls are the next most common.

4. The report file no longer matches its data

After an upgrade, or after someone edits a custom report, the layout can reference a field the dataset no longer returns, or a dataset whose shape changed.

Fix: open the report file in the report designer, refresh the dataset fields against the current procedure, and fix any expressions that reference missing fields. Work on a copy, keep the original, and compare output before and after.

5. Permissions

The account the report runs under can't execute the procedure, read a table, or write output.

Fix: check what the data source's account can execute on the SyteLine database, and check the report output folder's permissions for the TaskMan service account. See SyteLine report stuck in WAITING, or no PDF.

Step 3: The one-minute isolation test

Run the report's stored procedure directly with the user's parameters:

• Procedure fails: it's a data or SQL problem. Fix the procedure, or the bad record, in a copy.
• Procedure works, report fails: it's the data source, the report file, parameters or permissions.
• Procedure works and the report works for you but not the user: it's that user's parameters, Report Options or permissions.

This one test usually halves the time to a fix.

It only fails for one user, or one range

That points at data, not configuration. Narrow the range until it works, then widen it until it fails. The record at the boundary usually has something unusual: a null where a value is expected, a zero divisor, a very long text field, or a character the report can't render.

Prevent repeats

• Use the execution log for patterns, not just one failure. Monthly, list the reports that fail most and the slowest ones, and where their time goes (data retrieval, processing or rendering). See SyteLine SSRS reports: reading the execution log.

• Know where SSRS is heading. Infor now describes custom SSRS reports as deprecated (still supported) and recommends Report-type forms or DataView-based reports for new custom reports. When a broken SSRS report needs a major rework anyway, consider rebuilding it that way. See SyteLine reporting options.

• Never edit Infor's standard reports directly. Copy them, and keep custom reports and procedures named with a prefix.

• Re-test every custom report after an upgrade or service pack. Keep a list of them with a sample parameter set.
• Document data sources and their accounts, and update them as part of any server move.
• Add guard logic in custom procedures for zero divisors and nulls on fields that can be empty.

On multi-tenant cloud

You can't see the report server or its logs in multi-tenant CloudSuite Industrial. Read the full message in Background Task History, test with a narrower range, and if a standard report fails, open a case with Infor with the task number, the parameters and the message. Infor's own guidance for newer releases is to build new reports as Report-type forms or DataView-based reports rather than SSRS. See Reporting in CloudSuite Industrial without direct SQL.

FAQ

What does "An error has occurred during report processing" mean in SyteLine?

It's a generic SSRS wrapper. The real cause is in the inner message in Background Task History or the SSRS execution log.

Why does my SyteLine report fail only for some date ranges?

Usually one record in that range has unexpected data, like a null or a zero divisor. Narrow the range to find it.

Why did my custom SyteLine report break after an upgrade?

The data it relies on changed, so the report's dataset or procedure references something that no longer exists. Refresh the dataset against the current procedure and re-test.

How do I find the stored procedure behind a SyteLine report?

Look up the report's task on the Background Task Definitions form, then find its data source in the report file.