File not found

Symptoms

The report generates a "File not found" error message.

Possible solutions

This error message usually indicates an error in the programming of the report. Check for messages generated when the task ran in the Background Task History form, or check the reports error log (TaskMan_Path\Report\Errors\userID). Either of these might give more information about the problem.

It is also possible that the computer responsible for running reports has not been configured properly.

There are a number of things that can cause this error:

  • Check the Background Task History form to make sure there are no uninterpreted V(…) or P(…) keywords in the parameters.

    Finally, sub-reports are linked to the main report by parameters on the subreport. When Notes sub-reports are linked in, the ShowInternal, ShowExternal, Rowpointer, and pConnectionString subreport parameters must be linked back to the appropriate main report fields (typically, two main report parameters).

    In addition to these four parameters, any other parameters used in the sub-report must also be linked in the properties. Finally, the parameters linked in the properties should allow null values or have Null as their default values.

    If this is not done, the system expects these values to be passed from the originating form. If the wrong types of values are passed, the system generates an error. If no values are passed, the report usually "hangs" when run through TaskMan, while the report engine tries to prompt for these values on the TaskMan machine.

  • The parameters passed by the report form are in the wrong order or are of the wrong data type, which can produce a T-SQL error.

    For example, if a string or date parameter is plugged into an integer parameter, SQL generates an exception. Following the remedial steps in the next option catches these errors as well.

  • A Transact-SQL error occurred in the stored procedure.

    To get a more meaningful error message for a T-SQL error, run the report stored procedure through the SQL Server Management Studio. The easiest way to do this is to print the report and copy the report parameters from the Background Task History form. Paste these in as the parameters for the report stored procedure in SQL Server Management Studio, making these changes:

    • Enclose character and date parameters in single quotes.
    • Replace empty parameters with NULL.

    If there is a T-SQL error, this will give a line number and error description. The most common SQL errors in report stored procedures are data truncation errors. Many report stored procedures use temporary tables created using SQL data types. These tables are often populated from variables declared with user-defined data types. The lengths of many of these UDFs have been increased (for example, address fields for an internationalized site ID). This can cause a SQL exception by executing INSERT or UPDATE statements against the temporary tables using these variables, or applying the CONVERT function to them.

  • The report's stored procedure was changed, but the report definition file was not resynchronized with the stored procedure.
  • The stored procedure makes a call to RaiseErrorSp or raiserrorsp. RaiseErrorSp and raiserrorsp are used to generate a SQL exception with a user-specified error message. Neither of these two stored procedures should be used in report stored procedures.
  • The computer responsible for running reports must have:
    • Access to the TaskMan folder (where TaskMan.exe and RunReport.exe are installed) on the server where TaskMan is running; OR
    • The TaskMan URL, if previewing over the Internet.

    The easiest way to check this is to select Run from the Windows Start menu and try to run a report.

  • In rare cases, this error occurs if the RunReport.exe has become corrupted.

    If this is the case, running the report through TaskMan produces an error code of -1,073,741,819 and the report fails.