varlena ere: Debugging




How It Works

Design Structure


Design a Report


Built-in Arguments


Using CSV files



Reports Home

Use the debug file

While you are developing a report it is recommended that you set the debug level to 2 or as high as 4 to enable a debug file. (Also See Built-in Arguments )
	perl report debug=2 > report.html

Where is the debug file?

The location of the debug file depends on whether the variables $rootdir and $debugdir are set. The default is that they are not set, so the debug file should land in your current directory if you are running ere from a shell. If you cannot find the debug file, check the HTML output of the report run. In comments at the top it shows the path to the debug file as well as any error it had in accessing it.

The following table shows where your file will be based on whether or not $rootdir and $debugdir are set.


HTML output hints

The comments in the HTML output show you the parameters the report was passed and the location of the debug file. The comments also show starts and ends of repeated areas.

Run the report from the command line

Even if you have a report running application or script, while you are developing, run the report from the command line, redirecting the output to a file. You can have a browser open the file directly to view the output.

If your reports are running from a web application and produce a blank page and no debug report, there were some problems executing the ere script. Run it from the shell. If it runs re-evaluate the web application environment, e.g. check the PATH.

Reading the debug file

ere runs in two phases, compilation of the report .xml file and then the runtime execution of the report. The messages prior to the "RUN" debug message are applicable to the parsing of the report. The messages after the "RUN" debug message are applicable to the runtime of the report.

One of the most useful elements of the debug file is the recorded SQL statements. To verify your SQL statement, you can extract the SQL from the debug file and run it by hand. The SQL in the debug file has variables substituted and is exactly what was sent to the server. Look for 'Exec' in the debug file. Other helpful messages show the evaluation of variables and columns. This enables you to find unexpected evaluations.

Many of the other messages track the progress of the break area repetitions. When you have a problem which you cannot figure out, send the debug file for assistance.

Common problems

  • Missing column or variable values. Check your variable and column name spelling. Verify parameters were passed in as you expected on the command line by checking the debug or HTML file. Look at the SQL executed by extracting it from the debug file to be sure that the variables and values are correctly defined and evaluated. Make sure that your SQL target list matches your TargetList list.
  • order by clause does not match your BreakList. This causes missing data or extra repetition and apparently random breaks.
  • Permission problems writing the debug or stdout redirection. Check the location of the debug file listed in the HTML output. Check the permissions and spelling on the directories. If you are running ere from a web application, the directory should be under htdocs.

Errors Messages

  • Bad datastream name in area or table 'areaname'.
    • This usually means you have mistyped the name of the datastream attribute in the area or table tag named 'areaname';
  • Break column 'break' not in TargetList for DataStream 'dsname'.
    • You have probably mistyped the name of a break attribute in the <BreakList> attribute. The break names must be elements of the target list.
  • Could not find matching end of table or area level(n). Check your report .xml file for mismatched tables and areas."
    • This means that there is a <TABLE> or <area> which does not have a matching </TABLE> or </area>. The level number indicates the nesting level of the table or area. For example, table one inside of table two would have a level of 2. An area A inside of area B inside of area C in table D would have a level of 4. The level is meant to help you find the mismatch.
  • ERROR: No valid data returned for query.
    • This might not really be an error. It simply means what it says, that the query produced no results. If this is not what you expected, extract the SQL from the debug file and run it by hand. The SQL in the debug file has variables substituted and is exactly what was sent to the server. Look for 'Exec' in the debug file.
  • INTERNAL ERROR: any text.
    • This is a bug in ere. Please report the bug by sending the complete debug file. If it is possible, re-run the report with debug=5 in order to provide the most information possible.
  • Connection Failure: message
    • This is a failure to connect to PostgreSQL. The accompanying message should explain the cause. You may have to set the PG environment variables or set the database name, port, user, etc. in the report itself. See Tags for more information on how to do this.
  • SQL ERROR: message
    • An SQL error ocurred. The text of the SQL message from PostgreSQL should be displayed. It is recommened that you extract the SQL from the debug file and run it by hand. The SQL in the debug file has variables substituted and is exactly what was sent to the server. Look for 'Exec' in the debug file.
  • Cannot open CSV file: 'file'
    • Check the value of csvdir that you should have passed into the program in order to specify the directory where CVS files may be written. (See Built-in Arguments ). Check the spelling of the directory name in the parameter list. Check the permissions on the directory. The process running ere must be able to write to the file.
  • Missing Report Name Definition.
    • The Report Definition tag <ReportName> is missing or does not include the internal report name. The internal report name is used for error messages and to create csv output files as necessary.

Copyright 2003 through 2009 A. Elein Mustain, Varlena, LLC