Tracing 'Invalid Number Error' from millions of rows using a large, complicated query

Question

Background
I am working on fixing a large query that I inherited. The query consists of over 200 lines of DML statements.

The search queries the database restricting the data to a single month. Most months work just fine, but there are a few months that generate an ORA-01722: Invalid Number error.

I suspect the problem is one of the following:

1. a column defined as VARCHAR contains alpha characters but is being used where a number is required
2. a column is null and is being used where a number is required

If I can find the row that is causing the problem, I can change the query to handle said data appropriately. However, I don't know how I can isolate that row. I have attempted to break the query into parts and see where null values are being generated, but the entire query is dependent on a number of outer joins. I have been able to isolate the range to few days, but that doesn't allow me to isolate the row in question.

Also, the query has been defined as a stored procedure. At the end of the procedure I have defined an error handler to catch all errors and display a message:

EXCEPTION
    WHEN OTHERS THEN
        RAISE_APPLICATION_ERROR(-20001, error_message || parameter_string_values, TRUE);

However, the procedure raises the Invalid Number error and does not get trapped by the error handler at the bottom.

Questions

1. Are there any methods or database variables that I can set to help isolate this error?
2. Why isn't the ORA-01722: Invalid Number error being trapped by the error handler?

Answer 1

Your suspect #2 cannot be true because null values do not cause ORA-01722.

Q1: You might try

Decode (Translate (AlphanumericColumn, 'x0123456789', 'x'),
  Null, To_Number (AlphanumericColumn),
  SomeIdentifyingNumericReplacementValueForNonNumericContent
)

on all the alphanumeric columns whereever any one is used as a numeric value and later scan for the identifying numeric replacement value, which might even be null if still identifying, in the output to spot the offending rows.

Q2: It might be that the offending conversion occurs outside the error handling block, particularly in one of the initializers in the declare part before the begin or in another exception handler immediately before your When Others. If true, you should wrap the existing code into another inner declare-begin-end block while keeping your exception handler at the outermost level.