How to catch BCD_OVERFLOW error in open cursor?

[former_member579170]

Hi Guys,

I am trying to execute a filter query like:

OPEN CURSOR WITH HOLD c1
    FOR SELECT (COL_STR)
        FROM (JOIN_STR)
        UP TO ROWCOUNT ROWS
        WHERE (WHERESTR)
        GROUP BY (GROUPSTR)
        HAVING (HAVESTR)
        ORDER BY (ORDERSTR).
DO.
  FETCH NEXT CURSOR c1 INTO TABLE <DYN_TAB_RESULT> PACKAGE SIZE PKGSIZE.
  IF sy-subrc <> 0.
    CLOSE CURSOR c1.
    EXIT.
  ELSE.
    PERFORM PROCESS_DATA USING PROCESS_STATUS.
    IF PROCESS_STATUS NE 0.
      RETURN.
    ENDIF.
  ENDIF.
ENDDO.

Here in "WHERESTR" i have zint8 = '9223372036854775808'.

And the field zint8 is INT8 type, here i know the INT8 can have max value like 9223372036854775807. In this case i want to throw some exception for boundary values. But in this case my program is not throwing any exception or any value, it is directly terminating. Here i know it should throw the BCD_OVERFLOW exception, but instead of throwing any exception or any value it is directly terminating.

[matt]

When you post code, please put it into a code block using the "code" button on the editor. I've done it for you this time.

Also, I note that you've tagged this question with ABAP 7.5, yet you're using PERFORM which is certainly obsolete in that version and should not be used.

[former_member579170]

Thank's buddy,
But my problem is with cursor, it is not throwing any exception in any of sap system, it is just crashing the system and getting terminated the program, so the calling program will be waiting for some response for infinite time.

I am calling some function module from java program and that function module is calling this program, this program sends data to java program via http send, but if this program crash due to above mentioned problem then in this case my java program will be waiting for response for infinite time.

[matt]

I understand perfectly what your question is about, and was not attempting to answer it. I was just pointing out that it has deficiencies in it, and requesting you to ensure that when you post code, you put it into a code block.

[raymond_giuseppi]

Which of the allowed Open SQL - Exceptions (eg. in CX_SY_DYNAMIC_OSQL_SYNTAX or CX_SY_DYNAMIC_OSQL_SEMANTICS) did you already handle in your actual code?

[former_member579170]

Yes, I have already tried these also, even i have tried with the root class of exception . But the thing is It is not throwing any exception it is directly getting terminated.

[raymond_giuseppi]

Did you trace or debug execution?

[former_member579170]

Yes buddy i tried to debug also.

[Sandra_Rossi]

Why don't you test the boundaries at the place you build the WHERESTR variable, instead of trying to handle the error at SELECT time as it seems to be impossible to handle it anyway ?

UPDATE: sorry, it seems that it's sometimes catchable, it depends on old or strict Open SQL used, and type of database used.

[horst_keller]

BCD_OVERFLOW is not a SQL but an ABAP exception that happens if you assign a too large value to a type p field. The corresponding exception class can be found here: https://help.sap.com/http.svc/rc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abenueb-abfb-sysex... . It cannot be handled when wrapped in old Open SQL.

So, your problem is on the ABAP side in the INTO clause of the FETCH statement. Provide a correct target work area and everything is fine.

[Sandra_Rossi]

But BCD_OVERFLOW (so, CX_SY_ARITHMETIC_OVERFLOW) can't be handled when it's triggered internally inside Open SQL. Because the OP has tried to handle all exceptions with "CATCH CX_ROOT" (comment to Raymond's answer).

[horst_keller]

That's correct. The OP must Work with a target variable with a sufficient value Range.

"If exceptions occur during an assignment, whether they can be handled or not depends on the operand and the operand position."

[Sandra_Rossi]

In 7.52 (HANA), this code:
" Old Open SQL
DATA price TYPE p LENGTH 1.
TRY.
    SELECT SINGLE price FROM sflight INTO price WHERE price >= 10.
  CATCH cx_root INTO DATA(lx_root).
ENDTRY.
" Now in Strict Open SQL
TRY.
    SELECT SINGLE price FROM sflight INTO @price WHERE price >= 10.
  CATCH cx_root INTO DATA(lx_root).
ENDTRY.

Both "old Open SQL" and "Strict Open SQL" statements generate a catchable CX_SY_SQL_ERROR with SQLCODE = 10811- and SQLMSG = "Numeric overflow for parameter/column (1) source type DECIMAL, target type DECIMAL, value 'unknown'"

So, it seems that it also depends on the database.

[horst_keller]

Try to enforce the new SQL parser by using @ in front of variables and comma separated lists. The new parser checks stricter and you might get your exceptions.

[former_member579170]

Actually I have to make use of cursor only. And in cursor we can't use "INTO @any_variable".

[horst_keller]

"And in cursor we can't use "INTO @any_variable"." Wrong, see example under

https://help.sap.com/http.svc/rc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abapfetch.htm