Catch SAPSQL_DATA_LOSSCatch multiple exceptions at once?The case against checked exceptionsGlobally catch exceptions in a WPF application?Why catch and rethrow an exception in C#?Why should I not wrap every block in “try”-“catch”?Can I catch multiple Java exceptions in the same catch clause?Catch multiple exceptions in one line (except block)Try-catch speeding up my code?How do you implement a re-try-catch?Catching ifstream exception in main
Everything Bob says is false. How does he get people to trust him?
Failed to fetch jessie backports repository
Implement the Thanos sorting algorithm
Time travel short story where a man arrives in the late 19th century in a time machine and then sends the machine back into the past
Is exact Kanji stroke length important?
The baby cries all morning
How can I get through very long and very dry, but also very useful technical documents when learning a new tool?
Can a monster with multiattack use this ability if they are missing a limb?
What to do with wrong results in talks?
What does this 7 mean above the f flat
Is there any reason not to eat food that's been dropped on the surface of the moon?
What would happen if the UK refused to take part in EU Parliamentary elections?
Short story about space worker geeks who zone out by 'listening' to radiation from stars
Teaching indefinite integrals that require special-casing
Can I use my Chinese passport to enter China after I acquired another citizenship?
Increase performance creating Mandelbrot set in python
Tiptoe or tiphoof? Adjusting words to better fit fantasy races
What is the opposite of 'gravitas'?
Can criminal fraud exist without damages?
Go Pregnant or Go Home
How will losing mobility of one hand affect my career as a programmer?
Is there a good way to store credentials outside of a password manager?
when is out of tune ok?
What is difference between behavior and behaviour
Catch SAPSQL_DATA_LOSS
Catch multiple exceptions at once?The case against checked exceptionsGlobally catch exceptions in a WPF application?Why catch and rethrow an exception in C#?Why should I not wrap every block in “try”-“catch”?Can I catch multiple Java exceptions in the same catch clause?Catch multiple exceptions in one line (except block)Try-catch speeding up my code?How do you implement a re-try-catch?Catching ifstream exception in main
I want to catch and handle SAPSQL_DATA_LOSS
in my ABAP code.
I tried this:
try.
SELECT *
FROM (rtab_name) AS rtab
WHERE (sub_condition)
into table @<sub_result>
.
catch SAPSQL_DATA_LOSS into error.
...
endtry.
But above code is not valid. I get this message:
Type "SAPSQL_DATA_LOSS" is not valid
And I tried this:
catch SYSTEM-EXCEPTIONS SAPSQL_DATA_LOSS = 123.
SELECT *
...
.
endcatch.
if sy-subrc = 123.
...
endif.
But above code gives me:
Instead of "SAPSQL_DATA_LOSS" expected "system-exception" (translated from german to english by me)
How to catch SAPSQL_DATA_LOSS
?
This question is not about "why does this exception happen?". This is already solved. My code should handle the exception.
exception try-catch abap
|
show 6 more comments
I want to catch and handle SAPSQL_DATA_LOSS
in my ABAP code.
I tried this:
try.
SELECT *
FROM (rtab_name) AS rtab
WHERE (sub_condition)
into table @<sub_result>
.
catch SAPSQL_DATA_LOSS into error.
...
endtry.
But above code is not valid. I get this message:
Type "SAPSQL_DATA_LOSS" is not valid
And I tried this:
catch SYSTEM-EXCEPTIONS SAPSQL_DATA_LOSS = 123.
SELECT *
...
.
endcatch.
if sy-subrc = 123.
...
endif.
But above code gives me:
Instead of "SAPSQL_DATA_LOSS" expected "system-exception" (translated from german to english by me)
How to catch SAPSQL_DATA_LOSS
?
This question is not about "why does this exception happen?". This is already solved. My code should handle the exception.
exception try-catch abap
1
Are you using host variables (@...)? help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/… "If the content of a host variable read in an operand position needs to be converted to the target type, this is done using the rules for lossless assignments. If the assignment cannot be lossless, an exception is raised." It is not mentioned that the exception is "catchable", so I assume it is not.
– JozsefSzikszai
Mar 7 at 12:17
1
SAPSQL_DATA_LOSS is no class Exception. You can find all SQL Exceptions here:help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/…
– Dingermann
Mar 7 at 12:18
1
@guettli you can not handle it. As JozsefSzikszai already said, you loose data when it is transferd to your INTO Variable. This can happen when the domain of your variable uses conversion routines. To be on the safe side, you can use the "new" OpenSQL Sysntax SELECT SINGLE XXX FROM YYY INTO @DATA(lv_xxx)...
– Dingermann
Mar 7 at 12:40
2
@guettli this might give you an idea as well: blogs.sap.com/2014/10/08/abap-news-for-740-sp08-open-sql (see the comment of Jacques Nomssi and the answer from Horst Keller)
– JozsefSzikszai
Mar 7 at 13:00
1
@guettli Dingermann has provided the link to the page of possible exception classes (CX_SY...) for Open SQL. Note: if an exception is not caught, it generates a runtime error. Anyway you may simply catch the root exception class (Catch CX_ROOT
), so it will handle all possible catchable exceptions. Note: some exceptions can't be handled (there's no exception class) i.e. a runtime error occurs, and they are listed in the ABAP documentation (for instance, DBIF_RSQL_INVALID_REQUEST, ...) ; when a runtime error occurs, a short dump is generated (ST22).
– Sandra Rossi
Mar 7 at 13:30
|
show 6 more comments
I want to catch and handle SAPSQL_DATA_LOSS
in my ABAP code.
I tried this:
try.
SELECT *
FROM (rtab_name) AS rtab
WHERE (sub_condition)
into table @<sub_result>
.
catch SAPSQL_DATA_LOSS into error.
...
endtry.
But above code is not valid. I get this message:
Type "SAPSQL_DATA_LOSS" is not valid
And I tried this:
catch SYSTEM-EXCEPTIONS SAPSQL_DATA_LOSS = 123.
SELECT *
...
.
endcatch.
if sy-subrc = 123.
...
endif.
But above code gives me:
Instead of "SAPSQL_DATA_LOSS" expected "system-exception" (translated from german to english by me)
How to catch SAPSQL_DATA_LOSS
?
This question is not about "why does this exception happen?". This is already solved. My code should handle the exception.
exception try-catch abap
I want to catch and handle SAPSQL_DATA_LOSS
in my ABAP code.
I tried this:
try.
SELECT *
FROM (rtab_name) AS rtab
WHERE (sub_condition)
into table @<sub_result>
.
catch SAPSQL_DATA_LOSS into error.
...
endtry.
But above code is not valid. I get this message:
Type "SAPSQL_DATA_LOSS" is not valid
And I tried this:
catch SYSTEM-EXCEPTIONS SAPSQL_DATA_LOSS = 123.
SELECT *
...
.
endcatch.
if sy-subrc = 123.
...
endif.
But above code gives me:
Instead of "SAPSQL_DATA_LOSS" expected "system-exception" (translated from german to english by me)
How to catch SAPSQL_DATA_LOSS
?
This question is not about "why does this exception happen?". This is already solved. My code should handle the exception.
exception try-catch abap
exception try-catch abap
edited Mar 7 at 12:45
Jagger
6,43473866
6,43473866
asked Mar 7 at 11:34
guettliguettli
4,14425142287
4,14425142287
1
Are you using host variables (@...)? help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/… "If the content of a host variable read in an operand position needs to be converted to the target type, this is done using the rules for lossless assignments. If the assignment cannot be lossless, an exception is raised." It is not mentioned that the exception is "catchable", so I assume it is not.
– JozsefSzikszai
Mar 7 at 12:17
1
SAPSQL_DATA_LOSS is no class Exception. You can find all SQL Exceptions here:help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/…
– Dingermann
Mar 7 at 12:18
1
@guettli you can not handle it. As JozsefSzikszai already said, you loose data when it is transferd to your INTO Variable. This can happen when the domain of your variable uses conversion routines. To be on the safe side, you can use the "new" OpenSQL Sysntax SELECT SINGLE XXX FROM YYY INTO @DATA(lv_xxx)...
– Dingermann
Mar 7 at 12:40
2
@guettli this might give you an idea as well: blogs.sap.com/2014/10/08/abap-news-for-740-sp08-open-sql (see the comment of Jacques Nomssi and the answer from Horst Keller)
– JozsefSzikszai
Mar 7 at 13:00
1
@guettli Dingermann has provided the link to the page of possible exception classes (CX_SY...) for Open SQL. Note: if an exception is not caught, it generates a runtime error. Anyway you may simply catch the root exception class (Catch CX_ROOT
), so it will handle all possible catchable exceptions. Note: some exceptions can't be handled (there's no exception class) i.e. a runtime error occurs, and they are listed in the ABAP documentation (for instance, DBIF_RSQL_INVALID_REQUEST, ...) ; when a runtime error occurs, a short dump is generated (ST22).
– Sandra Rossi
Mar 7 at 13:30
|
show 6 more comments
1
Are you using host variables (@...)? help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/… "If the content of a host variable read in an operand position needs to be converted to the target type, this is done using the rules for lossless assignments. If the assignment cannot be lossless, an exception is raised." It is not mentioned that the exception is "catchable", so I assume it is not.
– JozsefSzikszai
Mar 7 at 12:17
1
SAPSQL_DATA_LOSS is no class Exception. You can find all SQL Exceptions here:help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/…
– Dingermann
Mar 7 at 12:18
1
@guettli you can not handle it. As JozsefSzikszai already said, you loose data when it is transferd to your INTO Variable. This can happen when the domain of your variable uses conversion routines. To be on the safe side, you can use the "new" OpenSQL Sysntax SELECT SINGLE XXX FROM YYY INTO @DATA(lv_xxx)...
– Dingermann
Mar 7 at 12:40
2
@guettli this might give you an idea as well: blogs.sap.com/2014/10/08/abap-news-for-740-sp08-open-sql (see the comment of Jacques Nomssi and the answer from Horst Keller)
– JozsefSzikszai
Mar 7 at 13:00
1
@guettli Dingermann has provided the link to the page of possible exception classes (CX_SY...) for Open SQL. Note: if an exception is not caught, it generates a runtime error. Anyway you may simply catch the root exception class (Catch CX_ROOT
), so it will handle all possible catchable exceptions. Note: some exceptions can't be handled (there's no exception class) i.e. a runtime error occurs, and they are listed in the ABAP documentation (for instance, DBIF_RSQL_INVALID_REQUEST, ...) ; when a runtime error occurs, a short dump is generated (ST22).
– Sandra Rossi
Mar 7 at 13:30
1
1
Are you using host variables (@...)? help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/… "If the content of a host variable read in an operand position needs to be converted to the target type, this is done using the rules for lossless assignments. If the assignment cannot be lossless, an exception is raised." It is not mentioned that the exception is "catchable", so I assume it is not.
– JozsefSzikszai
Mar 7 at 12:17
Are you using host variables (@...)? help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/… "If the content of a host variable read in an operand position needs to be converted to the target type, this is done using the rules for lossless assignments. If the assignment cannot be lossless, an exception is raised." It is not mentioned that the exception is "catchable", so I assume it is not.
– JozsefSzikszai
Mar 7 at 12:17
1
1
SAPSQL_DATA_LOSS is no class Exception. You can find all SQL Exceptions here:help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/…
– Dingermann
Mar 7 at 12:18
SAPSQL_DATA_LOSS is no class Exception. You can find all SQL Exceptions here:help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/…
– Dingermann
Mar 7 at 12:18
1
1
@guettli you can not handle it. As JozsefSzikszai already said, you loose data when it is transferd to your INTO Variable. This can happen when the domain of your variable uses conversion routines. To be on the safe side, you can use the "new" OpenSQL Sysntax SELECT SINGLE XXX FROM YYY INTO @DATA(lv_xxx)...
– Dingermann
Mar 7 at 12:40
@guettli you can not handle it. As JozsefSzikszai already said, you loose data when it is transferd to your INTO Variable. This can happen when the domain of your variable uses conversion routines. To be on the safe side, you can use the "new" OpenSQL Sysntax SELECT SINGLE XXX FROM YYY INTO @DATA(lv_xxx)...
– Dingermann
Mar 7 at 12:40
2
2
@guettli this might give you an idea as well: blogs.sap.com/2014/10/08/abap-news-for-740-sp08-open-sql (see the comment of Jacques Nomssi and the answer from Horst Keller)
– JozsefSzikszai
Mar 7 at 13:00
@guettli this might give you an idea as well: blogs.sap.com/2014/10/08/abap-news-for-740-sp08-open-sql (see the comment of Jacques Nomssi and the answer from Horst Keller)
– JozsefSzikszai
Mar 7 at 13:00
1
1
@guettli Dingermann has provided the link to the page of possible exception classes (CX_SY...) for Open SQL. Note: if an exception is not caught, it generates a runtime error. Anyway you may simply catch the root exception class (
Catch CX_ROOT
), so it will handle all possible catchable exceptions. Note: some exceptions can't be handled (there's no exception class) i.e. a runtime error occurs, and they are listed in the ABAP documentation (for instance, DBIF_RSQL_INVALID_REQUEST, ...) ; when a runtime error occurs, a short dump is generated (ST22).– Sandra Rossi
Mar 7 at 13:30
@guettli Dingermann has provided the link to the page of possible exception classes (CX_SY...) for Open SQL. Note: if an exception is not caught, it generates a runtime error. Anyway you may simply catch the root exception class (
Catch CX_ROOT
), so it will handle all possible catchable exceptions. Note: some exceptions can't be handled (there's no exception class) i.e. a runtime error occurs, and they are listed in the ABAP documentation (for instance, DBIF_RSQL_INVALID_REQUEST, ...) ; when a runtime error occurs, a short dump is generated (ST22).– Sandra Rossi
Mar 7 at 13:30
|
show 6 more comments
2 Answers
2
active
oldest
votes
SAPSQL_DATA_LOSS
is a runtime error.
As SAPSQL_DATA_LOSS
is not a class-based exception, it is not possible to catch it using try catch
.
As SAPSQL_DATA_LOSS
is not a catchable runtime error, it is not possible to catch it using try catch SYSTEM-EXCEPTIONS
.
see the below catchable runtime errors.
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abenueb-abfb-sysexc.htm
The URL above links to the page "of the obsolete catchable runtime errors"
– Sandra Rossi
Mar 7 at 13:59
because CATCH SYSTEM-EXCEPTIONS is obsolete statement. i have never used it probably it was decades ago.
– Haojie
Mar 7 at 14:14
Thank you very much for this information. How to handle a not catchable runtime error? Is there no way to handle it gracefully?
– guettli
Mar 8 at 9:07
Is there no way to handle it gracefully?
no. The only way is to convert host variables into proper datatype
– Suncatcher
Mar 9 at 3:18
@guettli there is no way to handle it. It is like you access a null reference which causes a short dump that you can’t catch. It is a flaw in the code and you have to fix it.
– Haojie
Mar 9 at 12:36
|
show 1 more comment
After some tries I can propose you a possible solution.
This is a workaround:
I don't know if it can be applied to your case, since it needs the select statement to be wrapped into an RFC function module !
The main point is that a short dump (message type X) CAN be handled in RFC calls.
So using an RFC (CALL FUNCTION 'xxxxx' destination 'NONE'
for example) and using special exception SYSTEM_FAILURE
, the system does not terminate the caller program, but instead it returns a SY-SUBRC > 0
with the Short dump informations in system message fields (SY-MSGxx).
STEPS
Create a Function module (RFC enabled) with your select statement input + the row type of the result table. (All parameters passed by value)
You need this last parameter since generic tables can't be passed in RFC (no "TYPE ANY TABLE" allowed)
FUNCTION Z_DYN_SEL .
*"----------------------------------------------------------------------
*"*"Local interface:
*" IMPORTING
*" VALUE(RTAB_NAME) TYPE TABNAME16
*" VALUE(SUB_CONDITION) TYPE STRING
*" VALUE(RESULT_TYPE) TYPE STRING
*"----------------------------------------------------------------------
* RTAB_NAME: DB Table
* SUB_CONDITION: WHERE Condition
* RESULT_TYPE: The ROW type of the internal table
field-symbols <sub_result> type any table.
* DEFINE LOCAL DYNAMIC TABLE TO STORE THE RESULT
data: lr_res type ref to data.
create data lr_res type standard table of (result_type).
assign lr_res->* to <sub_result>.
* DYNAMIC SELECT
select *
from (rtab_name) as rtab
where (sub_condition)
into table @<sub_result>.
* EXPORT RESULT TO A MEMORY ID, SO IT CAN BE RETRIEVED BY CALLER
export res = <sub_result> to memory id 'RES'.
Main program:
In this caller example some parameters are passed to the RFC.
KTOKD field (should be 4 chars long) is passed with a char10 value (producing your short dump).
If ANY Dump is triggered inside the function, we can now handle it.
If everything went fine, IMPORT
result from the EXPORT
statement inside the RFC
field-symbols <sub_result> type any table.
data: lr_res type ref to data.
create data lr_res type standard table of KNA1.
assign lr_res->* to <sub_result>.
data lv_msg type char255.
call function 'Z_DYN_SEL' destination 'NONE'
exporting
rtab_name = 'KNA1'
sub_condition = `KTOKD = 'D001xxxxxx'`
result_type = 'KNA1'
exceptions
system_failure = 1 message lv_msg.
if sy-subrc = 0.
import res = <sub_result> from memory id 'RES'.
else.
write: / lv_msg.
write : / sy-msgid, sy-msgno, sy-msgty, sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4.
endif.
RESULTS
After the RFC call in case of a short dump in the select statement, the program is not terminated and the following pieces of information are available
SY-SUBRC = 1
lv_msg
is the error text (Data was lost while copying a value.)
Sy-msgid = 00
Sy-msgno = '341'
Sy-msgty = 'X'
Sy-msgv1 = 'SAPSQL_DATA_LOSS'
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55042812%2fcatch-sapsql-data-loss%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
SAPSQL_DATA_LOSS
is a runtime error.
As SAPSQL_DATA_LOSS
is not a class-based exception, it is not possible to catch it using try catch
.
As SAPSQL_DATA_LOSS
is not a catchable runtime error, it is not possible to catch it using try catch SYSTEM-EXCEPTIONS
.
see the below catchable runtime errors.
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abenueb-abfb-sysexc.htm
The URL above links to the page "of the obsolete catchable runtime errors"
– Sandra Rossi
Mar 7 at 13:59
because CATCH SYSTEM-EXCEPTIONS is obsolete statement. i have never used it probably it was decades ago.
– Haojie
Mar 7 at 14:14
Thank you very much for this information. How to handle a not catchable runtime error? Is there no way to handle it gracefully?
– guettli
Mar 8 at 9:07
Is there no way to handle it gracefully?
no. The only way is to convert host variables into proper datatype
– Suncatcher
Mar 9 at 3:18
@guettli there is no way to handle it. It is like you access a null reference which causes a short dump that you can’t catch. It is a flaw in the code and you have to fix it.
– Haojie
Mar 9 at 12:36
|
show 1 more comment
SAPSQL_DATA_LOSS
is a runtime error.
As SAPSQL_DATA_LOSS
is not a class-based exception, it is not possible to catch it using try catch
.
As SAPSQL_DATA_LOSS
is not a catchable runtime error, it is not possible to catch it using try catch SYSTEM-EXCEPTIONS
.
see the below catchable runtime errors.
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abenueb-abfb-sysexc.htm
The URL above links to the page "of the obsolete catchable runtime errors"
– Sandra Rossi
Mar 7 at 13:59
because CATCH SYSTEM-EXCEPTIONS is obsolete statement. i have never used it probably it was decades ago.
– Haojie
Mar 7 at 14:14
Thank you very much for this information. How to handle a not catchable runtime error? Is there no way to handle it gracefully?
– guettli
Mar 8 at 9:07
Is there no way to handle it gracefully?
no. The only way is to convert host variables into proper datatype
– Suncatcher
Mar 9 at 3:18
@guettli there is no way to handle it. It is like you access a null reference which causes a short dump that you can’t catch. It is a flaw in the code and you have to fix it.
– Haojie
Mar 9 at 12:36
|
show 1 more comment
SAPSQL_DATA_LOSS
is a runtime error.
As SAPSQL_DATA_LOSS
is not a class-based exception, it is not possible to catch it using try catch
.
As SAPSQL_DATA_LOSS
is not a catchable runtime error, it is not possible to catch it using try catch SYSTEM-EXCEPTIONS
.
see the below catchable runtime errors.
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abenueb-abfb-sysexc.htm
SAPSQL_DATA_LOSS
is a runtime error.
As SAPSQL_DATA_LOSS
is not a class-based exception, it is not possible to catch it using try catch
.
As SAPSQL_DATA_LOSS
is not a catchable runtime error, it is not possible to catch it using try catch SYSTEM-EXCEPTIONS
.
see the below catchable runtime errors.
https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/abenueb-abfb-sysexc.htm
answered Mar 7 at 13:04
HaojieHaojie
4,75211013
4,75211013
The URL above links to the page "of the obsolete catchable runtime errors"
– Sandra Rossi
Mar 7 at 13:59
because CATCH SYSTEM-EXCEPTIONS is obsolete statement. i have never used it probably it was decades ago.
– Haojie
Mar 7 at 14:14
Thank you very much for this information. How to handle a not catchable runtime error? Is there no way to handle it gracefully?
– guettli
Mar 8 at 9:07
Is there no way to handle it gracefully?
no. The only way is to convert host variables into proper datatype
– Suncatcher
Mar 9 at 3:18
@guettli there is no way to handle it. It is like you access a null reference which causes a short dump that you can’t catch. It is a flaw in the code and you have to fix it.
– Haojie
Mar 9 at 12:36
|
show 1 more comment
The URL above links to the page "of the obsolete catchable runtime errors"
– Sandra Rossi
Mar 7 at 13:59
because CATCH SYSTEM-EXCEPTIONS is obsolete statement. i have never used it probably it was decades ago.
– Haojie
Mar 7 at 14:14
Thank you very much for this information. How to handle a not catchable runtime error? Is there no way to handle it gracefully?
– guettli
Mar 8 at 9:07
Is there no way to handle it gracefully?
no. The only way is to convert host variables into proper datatype
– Suncatcher
Mar 9 at 3:18
@guettli there is no way to handle it. It is like you access a null reference which causes a short dump that you can’t catch. It is a flaw in the code and you have to fix it.
– Haojie
Mar 9 at 12:36
The URL above links to the page "of the obsolete catchable runtime errors"
– Sandra Rossi
Mar 7 at 13:59
The URL above links to the page "of the obsolete catchable runtime errors"
– Sandra Rossi
Mar 7 at 13:59
because CATCH SYSTEM-EXCEPTIONS is obsolete statement. i have never used it probably it was decades ago.
– Haojie
Mar 7 at 14:14
because CATCH SYSTEM-EXCEPTIONS is obsolete statement. i have never used it probably it was decades ago.
– Haojie
Mar 7 at 14:14
Thank you very much for this information. How to handle a not catchable runtime error? Is there no way to handle it gracefully?
– guettli
Mar 8 at 9:07
Thank you very much for this information. How to handle a not catchable runtime error? Is there no way to handle it gracefully?
– guettli
Mar 8 at 9:07
Is there no way to handle it gracefully?
no. The only way is to convert host variables into proper datatype– Suncatcher
Mar 9 at 3:18
Is there no way to handle it gracefully?
no. The only way is to convert host variables into proper datatype– Suncatcher
Mar 9 at 3:18
@guettli there is no way to handle it. It is like you access a null reference which causes a short dump that you can’t catch. It is a flaw in the code and you have to fix it.
– Haojie
Mar 9 at 12:36
@guettli there is no way to handle it. It is like you access a null reference which causes a short dump that you can’t catch. It is a flaw in the code and you have to fix it.
– Haojie
Mar 9 at 12:36
|
show 1 more comment
After some tries I can propose you a possible solution.
This is a workaround:
I don't know if it can be applied to your case, since it needs the select statement to be wrapped into an RFC function module !
The main point is that a short dump (message type X) CAN be handled in RFC calls.
So using an RFC (CALL FUNCTION 'xxxxx' destination 'NONE'
for example) and using special exception SYSTEM_FAILURE
, the system does not terminate the caller program, but instead it returns a SY-SUBRC > 0
with the Short dump informations in system message fields (SY-MSGxx).
STEPS
Create a Function module (RFC enabled) with your select statement input + the row type of the result table. (All parameters passed by value)
You need this last parameter since generic tables can't be passed in RFC (no "TYPE ANY TABLE" allowed)
FUNCTION Z_DYN_SEL .
*"----------------------------------------------------------------------
*"*"Local interface:
*" IMPORTING
*" VALUE(RTAB_NAME) TYPE TABNAME16
*" VALUE(SUB_CONDITION) TYPE STRING
*" VALUE(RESULT_TYPE) TYPE STRING
*"----------------------------------------------------------------------
* RTAB_NAME: DB Table
* SUB_CONDITION: WHERE Condition
* RESULT_TYPE: The ROW type of the internal table
field-symbols <sub_result> type any table.
* DEFINE LOCAL DYNAMIC TABLE TO STORE THE RESULT
data: lr_res type ref to data.
create data lr_res type standard table of (result_type).
assign lr_res->* to <sub_result>.
* DYNAMIC SELECT
select *
from (rtab_name) as rtab
where (sub_condition)
into table @<sub_result>.
* EXPORT RESULT TO A MEMORY ID, SO IT CAN BE RETRIEVED BY CALLER
export res = <sub_result> to memory id 'RES'.
Main program:
In this caller example some parameters are passed to the RFC.
KTOKD field (should be 4 chars long) is passed with a char10 value (producing your short dump).
If ANY Dump is triggered inside the function, we can now handle it.
If everything went fine, IMPORT
result from the EXPORT
statement inside the RFC
field-symbols <sub_result> type any table.
data: lr_res type ref to data.
create data lr_res type standard table of KNA1.
assign lr_res->* to <sub_result>.
data lv_msg type char255.
call function 'Z_DYN_SEL' destination 'NONE'
exporting
rtab_name = 'KNA1'
sub_condition = `KTOKD = 'D001xxxxxx'`
result_type = 'KNA1'
exceptions
system_failure = 1 message lv_msg.
if sy-subrc = 0.
import res = <sub_result> from memory id 'RES'.
else.
write: / lv_msg.
write : / sy-msgid, sy-msgno, sy-msgty, sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4.
endif.
RESULTS
After the RFC call in case of a short dump in the select statement, the program is not terminated and the following pieces of information are available
SY-SUBRC = 1
lv_msg
is the error text (Data was lost while copying a value.)
Sy-msgid = 00
Sy-msgno = '341'
Sy-msgty = 'X'
Sy-msgv1 = 'SAPSQL_DATA_LOSS'
add a comment |
After some tries I can propose you a possible solution.
This is a workaround:
I don't know if it can be applied to your case, since it needs the select statement to be wrapped into an RFC function module !
The main point is that a short dump (message type X) CAN be handled in RFC calls.
So using an RFC (CALL FUNCTION 'xxxxx' destination 'NONE'
for example) and using special exception SYSTEM_FAILURE
, the system does not terminate the caller program, but instead it returns a SY-SUBRC > 0
with the Short dump informations in system message fields (SY-MSGxx).
STEPS
Create a Function module (RFC enabled) with your select statement input + the row type of the result table. (All parameters passed by value)
You need this last parameter since generic tables can't be passed in RFC (no "TYPE ANY TABLE" allowed)
FUNCTION Z_DYN_SEL .
*"----------------------------------------------------------------------
*"*"Local interface:
*" IMPORTING
*" VALUE(RTAB_NAME) TYPE TABNAME16
*" VALUE(SUB_CONDITION) TYPE STRING
*" VALUE(RESULT_TYPE) TYPE STRING
*"----------------------------------------------------------------------
* RTAB_NAME: DB Table
* SUB_CONDITION: WHERE Condition
* RESULT_TYPE: The ROW type of the internal table
field-symbols <sub_result> type any table.
* DEFINE LOCAL DYNAMIC TABLE TO STORE THE RESULT
data: lr_res type ref to data.
create data lr_res type standard table of (result_type).
assign lr_res->* to <sub_result>.
* DYNAMIC SELECT
select *
from (rtab_name) as rtab
where (sub_condition)
into table @<sub_result>.
* EXPORT RESULT TO A MEMORY ID, SO IT CAN BE RETRIEVED BY CALLER
export res = <sub_result> to memory id 'RES'.
Main program:
In this caller example some parameters are passed to the RFC.
KTOKD field (should be 4 chars long) is passed with a char10 value (producing your short dump).
If ANY Dump is triggered inside the function, we can now handle it.
If everything went fine, IMPORT
result from the EXPORT
statement inside the RFC
field-symbols <sub_result> type any table.
data: lr_res type ref to data.
create data lr_res type standard table of KNA1.
assign lr_res->* to <sub_result>.
data lv_msg type char255.
call function 'Z_DYN_SEL' destination 'NONE'
exporting
rtab_name = 'KNA1'
sub_condition = `KTOKD = 'D001xxxxxx'`
result_type = 'KNA1'
exceptions
system_failure = 1 message lv_msg.
if sy-subrc = 0.
import res = <sub_result> from memory id 'RES'.
else.
write: / lv_msg.
write : / sy-msgid, sy-msgno, sy-msgty, sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4.
endif.
RESULTS
After the RFC call in case of a short dump in the select statement, the program is not terminated and the following pieces of information are available
SY-SUBRC = 1
lv_msg
is the error text (Data was lost while copying a value.)
Sy-msgid = 00
Sy-msgno = '341'
Sy-msgty = 'X'
Sy-msgv1 = 'SAPSQL_DATA_LOSS'
add a comment |
After some tries I can propose you a possible solution.
This is a workaround:
I don't know if it can be applied to your case, since it needs the select statement to be wrapped into an RFC function module !
The main point is that a short dump (message type X) CAN be handled in RFC calls.
So using an RFC (CALL FUNCTION 'xxxxx' destination 'NONE'
for example) and using special exception SYSTEM_FAILURE
, the system does not terminate the caller program, but instead it returns a SY-SUBRC > 0
with the Short dump informations in system message fields (SY-MSGxx).
STEPS
Create a Function module (RFC enabled) with your select statement input + the row type of the result table. (All parameters passed by value)
You need this last parameter since generic tables can't be passed in RFC (no "TYPE ANY TABLE" allowed)
FUNCTION Z_DYN_SEL .
*"----------------------------------------------------------------------
*"*"Local interface:
*" IMPORTING
*" VALUE(RTAB_NAME) TYPE TABNAME16
*" VALUE(SUB_CONDITION) TYPE STRING
*" VALUE(RESULT_TYPE) TYPE STRING
*"----------------------------------------------------------------------
* RTAB_NAME: DB Table
* SUB_CONDITION: WHERE Condition
* RESULT_TYPE: The ROW type of the internal table
field-symbols <sub_result> type any table.
* DEFINE LOCAL DYNAMIC TABLE TO STORE THE RESULT
data: lr_res type ref to data.
create data lr_res type standard table of (result_type).
assign lr_res->* to <sub_result>.
* DYNAMIC SELECT
select *
from (rtab_name) as rtab
where (sub_condition)
into table @<sub_result>.
* EXPORT RESULT TO A MEMORY ID, SO IT CAN BE RETRIEVED BY CALLER
export res = <sub_result> to memory id 'RES'.
Main program:
In this caller example some parameters are passed to the RFC.
KTOKD field (should be 4 chars long) is passed with a char10 value (producing your short dump).
If ANY Dump is triggered inside the function, we can now handle it.
If everything went fine, IMPORT
result from the EXPORT
statement inside the RFC
field-symbols <sub_result> type any table.
data: lr_res type ref to data.
create data lr_res type standard table of KNA1.
assign lr_res->* to <sub_result>.
data lv_msg type char255.
call function 'Z_DYN_SEL' destination 'NONE'
exporting
rtab_name = 'KNA1'
sub_condition = `KTOKD = 'D001xxxxxx'`
result_type = 'KNA1'
exceptions
system_failure = 1 message lv_msg.
if sy-subrc = 0.
import res = <sub_result> from memory id 'RES'.
else.
write: / lv_msg.
write : / sy-msgid, sy-msgno, sy-msgty, sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4.
endif.
RESULTS
After the RFC call in case of a short dump in the select statement, the program is not terminated and the following pieces of information are available
SY-SUBRC = 1
lv_msg
is the error text (Data was lost while copying a value.)
Sy-msgid = 00
Sy-msgno = '341'
Sy-msgty = 'X'
Sy-msgv1 = 'SAPSQL_DATA_LOSS'
After some tries I can propose you a possible solution.
This is a workaround:
I don't know if it can be applied to your case, since it needs the select statement to be wrapped into an RFC function module !
The main point is that a short dump (message type X) CAN be handled in RFC calls.
So using an RFC (CALL FUNCTION 'xxxxx' destination 'NONE'
for example) and using special exception SYSTEM_FAILURE
, the system does not terminate the caller program, but instead it returns a SY-SUBRC > 0
with the Short dump informations in system message fields (SY-MSGxx).
STEPS
Create a Function module (RFC enabled) with your select statement input + the row type of the result table. (All parameters passed by value)
You need this last parameter since generic tables can't be passed in RFC (no "TYPE ANY TABLE" allowed)
FUNCTION Z_DYN_SEL .
*"----------------------------------------------------------------------
*"*"Local interface:
*" IMPORTING
*" VALUE(RTAB_NAME) TYPE TABNAME16
*" VALUE(SUB_CONDITION) TYPE STRING
*" VALUE(RESULT_TYPE) TYPE STRING
*"----------------------------------------------------------------------
* RTAB_NAME: DB Table
* SUB_CONDITION: WHERE Condition
* RESULT_TYPE: The ROW type of the internal table
field-symbols <sub_result> type any table.
* DEFINE LOCAL DYNAMIC TABLE TO STORE THE RESULT
data: lr_res type ref to data.
create data lr_res type standard table of (result_type).
assign lr_res->* to <sub_result>.
* DYNAMIC SELECT
select *
from (rtab_name) as rtab
where (sub_condition)
into table @<sub_result>.
* EXPORT RESULT TO A MEMORY ID, SO IT CAN BE RETRIEVED BY CALLER
export res = <sub_result> to memory id 'RES'.
Main program:
In this caller example some parameters are passed to the RFC.
KTOKD field (should be 4 chars long) is passed with a char10 value (producing your short dump).
If ANY Dump is triggered inside the function, we can now handle it.
If everything went fine, IMPORT
result from the EXPORT
statement inside the RFC
field-symbols <sub_result> type any table.
data: lr_res type ref to data.
create data lr_res type standard table of KNA1.
assign lr_res->* to <sub_result>.
data lv_msg type char255.
call function 'Z_DYN_SEL' destination 'NONE'
exporting
rtab_name = 'KNA1'
sub_condition = `KTOKD = 'D001xxxxxx'`
result_type = 'KNA1'
exceptions
system_failure = 1 message lv_msg.
if sy-subrc = 0.
import res = <sub_result> from memory id 'RES'.
else.
write: / lv_msg.
write : / sy-msgid, sy-msgno, sy-msgty, sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4.
endif.
RESULTS
After the RFC call in case of a short dump in the select statement, the program is not terminated and the following pieces of information are available
SY-SUBRC = 1
lv_msg
is the error text (Data was lost while copying a value.)
Sy-msgid = 00
Sy-msgno = '341'
Sy-msgty = 'X'
Sy-msgv1 = 'SAPSQL_DATA_LOSS'
edited Mar 16 at 21:31
Jagger
6,43473866
6,43473866
answered Mar 11 at 16:09
manuel_bmanuel_b
289313
289313
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55042812%2fcatch-sapsql-data-loss%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Are you using host variables (@...)? help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/… "If the content of a host variable read in an operand position needs to be converted to the target type, this is done using the rules for lossless assignments. If the assignment cannot be lossless, an exception is raised." It is not mentioned that the exception is "catchable", so I assume it is not.
– JozsefSzikszai
Mar 7 at 12:17
1
SAPSQL_DATA_LOSS is no class Exception. You can find all SQL Exceptions here:help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/…
– Dingermann
Mar 7 at 12:18
1
@guettli you can not handle it. As JozsefSzikszai already said, you loose data when it is transferd to your INTO Variable. This can happen when the domain of your variable uses conversion routines. To be on the safe side, you can use the "new" OpenSQL Sysntax SELECT SINGLE XXX FROM YYY INTO @DATA(lv_xxx)...
– Dingermann
Mar 7 at 12:40
2
@guettli this might give you an idea as well: blogs.sap.com/2014/10/08/abap-news-for-740-sp08-open-sql (see the comment of Jacques Nomssi and the answer from Horst Keller)
– JozsefSzikszai
Mar 7 at 13:00
1
@guettli Dingermann has provided the link to the page of possible exception classes (CX_SY...) for Open SQL. Note: if an exception is not caught, it generates a runtime error. Anyway you may simply catch the root exception class (
Catch CX_ROOT
), so it will handle all possible catchable exceptions. Note: some exceptions can't be handled (there's no exception class) i.e. a runtime error occurs, and they are listed in the ABAP documentation (for instance, DBIF_RSQL_INVALID_REQUEST, ...) ; when a runtime error occurs, a short dump is generated (ST22).– Sandra Rossi
Mar 7 at 13:30