How It Works
Design a Report
Using CSV files
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 ere.pl 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.
- 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.
- 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
- 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.