Every BI Publisher report author has experienced the frustration when a report fails or returns inconsistent results. Silent errors, where an error is suppressed but data issues occur, are particularly vexing, as are layout-level glitches and SQL-driven anomalies.
If you often face silent issues, learning how to debug Oracle BI Publisher error can save hours of troubleshooting.
Sometimes, a report runs successfully yet delivers inaccurate, duplicated, or missing data. Most often, the root cause lurks in the underlying SQL, and this should be the primary focus when debugging.
This guide explains how to activate debug mode, locate crucial log files, and clear the cache to ensure reliable diagnosis, drawing on proven Oracle best practices.
Why Does Debugging Matter?
Oracle BI Publisher sits between the Fusion UI, BI Server, and the database so that errors can arise from multiple layers. While the Fusion UI and BI Server rarely cause issues worth tracing here, SQL errors within the data model are by far the most common culprits.
Developers frequently need to debug Oracle BI Publisher error cases caused by SQL or data model faults.
The UI may display nothing, yet if records are missing, duplicated, or show incorrect cells, the cause is almost always buried within SQL. Typical failure scenarios include:
- Program errors without output due to ORA-xxx SQL faults
- Expected records not appearing
- Duplicate rows appear in the output
- Incorrect cell values pop up within a record
Also Read: End-to-End Oracle Fusion Data Migration Reconciliation in Oracle Fusion
Enable Debug Mode in BI Publisher
Enabling debug mode in BI Publisher is essential for investigating issues that standard error messages can’t explain. It enables developers to capture detailed logs that reveal hidden errors in data models or reports, making troubleshooting significantly faster and more effective. In this section, two debug modes are covered.
To effectively debug Oracle BI Publisher error, enabling debug mode is always the first step.
WebLogic Method
Step 1: Log into WebLogic Enterprise Manager.
Step 2: Navigate: Application Deployments → BI publisher
Step 3: Click on My Profile → Administration

Step 4: Set Reload log Configuration to Trace.
Step 5: Log out and log in to the BI publisher to activate detailed logging

Runtime Data Model Debugging
Step 1: Log in Oracle Fusion Bi publisher as an administrator.
Step 2: Click on Manage Publisher under Publisher

Step 3: Under Runtime Configuration, Click on Properties

Step 4: Set “Enable Data Model Diagnostic” to True.

Tip: Always restart servers after changing logging settings to ensure changes take effect
Locate BI Publisher Log Files
Logs are accessible via Fusion Middleware Control, navigate to BI Publisher deployment and choose “View Log Messages.” Major log files include:
Log in to Fusion Middleware Control via a URL like https://<your-instance>/em
| Presentation Services: sawlog<n>.log |
| BI Server: obis<n>_query.log, nqserver<n>.log, nqsadmintool.log |
| JavaHost: jh.log |
| Scheduler: nqscheduler.log |
| Cluster Controller: nqcluster.log |
| BI JEE logs: AdminServer-diagnostic.log, bi_server1-diagnostic.log |
Checking logs is one of the most reliable methods to debug Oracle BI Publisher error in complex reports.
Tip: For SQL and data troubleshooting, always consult both the BI Publisher logs and the corresponding BI Server logs for a complete view.
You Must Read: Complete Guide to Oracle BI Publisher Performance Tuning for Fusion Applications
Clear or Disable BI Publisher Cache
UI Method
- Go to BI Publisher Administration → Reload Files and Metadata. This removes stored report definitions, data, and outputs.

Fusion-Specific
- In Presentation Services Admin: Manage Sessions

- Scroll down to Cursor Cache → Close All Cursors

Clearing caches regularly is another way to debug Oracle BI Publisher error and avoid stale report outputs.
Tip: Regularly clear caches after making SQL or layout changes to avoid stale results.
Sample Debug Workflow
- Enable Trace logging, then restart.
- Clear all BI Publisher and BI Server caches.
- Reproduce the report issue.
- Inspect logs for SQL errors, matching timestamps and user context.
How to Debug SQL Issues Effectively?
Most issues developers encounter in Oracle involve data models or custom SQL code. In theory, Oracle’s error codes and descriptions should make troubleshooting straightforward.
However, when working with large and complex SQL statements, this process becomes much more challenging.
At Datafusing, we know that our developers often handle SQL scripts with 500+ lines, where even a small mistake, such as a missing comma or bracket, can be challenging to track down.
To simplify the process, we recommend the following six-step approach to identifying and resolving the root cause of SQL errors.

Tip: Always compare the outputs before and after SQL changes to ensure there are no unintended side effects. Use the log viewer in Fusion Middleware Control to filter by date, severity, and module.
You Can’t Ignore: Building a Custom Report Using Reporting Tools in Oracle Fusion
Debugging Common SQL Error Messages
When an error occurs, Oracle returns an error message along with a unique error code in the format ORA-XXXXX. These codes can be referenced in Oracle’s documentation to help identify the root cause.
While many error messages are descriptive, some can be vague or even misleading. Below are two common error messages along with approaches to diagnose and resolve their root causes.
ORA-01427- Single Row Subquery Returns More than One Row
This error occurs when a subquery that is expected to return only one row instead returns multiple rows. There are two types of subqueries:
- Multi-row subqueries: These are usually found in the FROM clause or preceded by operators such as IN.
- Single-row subqueries: These are usually found in the SELECT clause or preceded by operators that expect a single value, such as =, >, <, etc.
The ORA-01427 error happens only with Type 2 (single-row) subqueries.
Troubleshooting Steps
- Identify all single-row subqueries in your SQL.
- Iteratively add ROWNUM = 1 to these subqueries until the error disappears.
- The last subquery modified is the one causing the issue.
- Fix the logic by either:
- Adjusting it to handle multiple records correctly, or
- Restricting it so that it reliably returns only one record.
Pro Tip: Avoid using DISTINCT to force a single record. It may reduce duplicates, but it does not guarantee a single-row result.
ORA-01722-Invalid Number
This error occurs when the SQL engine attempts to convert a character value into a number, but the value is non-numeric. There are two common scenarios where this happens:
- Explicit Conversion: It occurs when a character is explicitly converted to a number using functions like TO_NUMBER.
- Implicit Conversion: It occurs when the SQL engine automatically tries to convert a character to a number, such as:
- Comparing a character with a numeric value in the WHERE clause.
- Passing a non-numeric character into a function that expects a number.
Example 1: NVL(20, ‘A’) will trigger this error because ‘A’ is not a valid number.
Example 2: NVL(20, ‘A’) will trigger this error because ‘A’ is not a valid number.
Troubleshooting Steps
- Reproduce the issue with a single record.
- Inspect all explicit conversions (e.g., TO_NUMBER). Ensure only valid numeric values are being passed. A quick test is to remove the conversion and see if the error disappears temporarily.
- Review all WHERE clauses and joins. Look for conditions where a character is compared with a numeric value. In such cases, the SQL engine tries to cast the character to a number. To fix this, explicitly convert the value to a character (e.g., wrap with TO_CHAR) so the comparison is handled correctly.
- Examine all function calls (NVL, PL/SQL functions, etc.). Iteratively comment them out to isolate the issue. Pay close attention to the parameters inside these.
- Functions, as a non-numeric value passed where a number is expected, can trigger the error.
- Check return values from functions. If a non-numeric value is returned into a numeric field, it will cause this error.
- If you are using set operations (UNION, INTERSECT, etc.), compare the SELECT clauses across all SQL blocks. A numeric in one query and a non-numeric in another will result in this error.
SQL-related faults are often the hardest to debug Oracle BI Publisher error, especially in large queries.
Whether you are running your first SQL or working with 500+ line queries, debugging requires a structured approach.
Must Read: Complete Guide to Oracle Fusion Custom Report Builder and CloudSQL Advantages
How CloudSQL Can Help to Debug SQL Code?
With CloudSQL, you don’t need to spend hours debugging. CloudSQL’s AI-driven Fix feature makes it easier to debug Oracle BI Publisher error by automatically correcting SQL issues. Using the Fix with AI feature powered by the LLM Engine, you can instantly get suggestions to resolve SQL errors and optimize your queries.

The LLM engine analyzes errors and generates corrected SQL statements with clear explanations. In our testing, AI-driven SQL correction has shown an accuracy rate of 60% to 90%, depending on the type of error.
It performs exceptionally well in detecting and fixing pure SQL syntax issues, though it is less effective with Oracle Fusion schema-related errors. Overall, this feature serves as a powerful debugging companion for Oracle developers.

Many developers face BI Publisher issues after report deployment or Oracle Fusion data migration, so structured debugging becomes essential.
Professional Tips for BI Publisher Debugging
- Always start with SQL review; most BI Publisher errors can be traced to data model design or query logic.
- Use the Template Viewer for tracing layout-level issues, and insert diagnostic print statements (<?$varTest?>) with color for quick checks.
- Regularly clear caches when testing changes to ensure accuracy and prevent false negatives.
- Do not overlook out-of-memory or stuck job scenarios; consult JVM and server logs for resource root causes before escalating to Oracle support.
- Document every debugging step and code change for traceability.
Following these tips ensures you can debug Oracle BI Publisher error faster and with accuracy.
You May Like: How to Create a BI Publisher Report in Oracle Fusion?
Frequently Asked Questions (FAQs)
How do I enable debug mode in BI Publisher?
Log into WebLogic → Log Configuration → Set Oracle.xdo = Trace:32 and restart servers.
Where are BI Publisher log files located?
In BI_DOMAIN/…/servers/…/logs, including sawlog.log, nqserver.log, jh.log, and more.
How can I clear BI Publisher cache?
Use the UI under Manage Cache or programmatically with SAPurgeAllCache() and nqcmd.