Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Short Dump While Changing Non-KeyField of Sorted Table

nomssi
Active Contributor
0 Kudos

Hello,


A short dump occurs while trying to change a field of a sorted table item passed as CHANGING parameter.  Are non-key fields in a sorted structure protected? The error message does not explicitely say so. Can anyone link to documentation explaining this behavior? 

best regards,

JNN

1 ACCEPTED SOLUTION

horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hello,

Here, two things come together:

  • For table expressions, that are internally represented as field symbols, the same restrictions hold as for field symbols specified after READ ASSIGNING: You cannot modify the primary key of sorted and hashed tables (see READ TABLE - result ).
  • Unfortunately, a partial check for modification operations, that guarantees that no key fields are changes is only done in table operations but not if a table line is accessed as a whole. In the latter case any write access is prohibited. As for field symbols, this is only checked at runtime in the moment.

Horst

14 REPLIES 14

s_nnoorie
Active Participant
0 Kudos

Can you please send the short dump error analysis.

nomssi
Active Contributor
0 Kudos

Error analysis

An exception has occurred which is explained in more detail below. The exception is assigned to class 'CX_SY_DYN_CALL_ILLEGAL_TYPE' and was not caught in procedure "SORTED" "(METHOD)", nor was it propagated by a RAISING clause. Since the caller of the procedure could not have anticipated this exception, the current program was terminated.

The reason for the exception is:    Field "%_##TVREG_001-EBELN" was to assigned a new value but this field is at least partly protected against changes. The following are protected against changes:

  • Character literals or numerical literals,
  • Constants (CONSTANTS),
  • Parameters of category IMPORTING REFERENCE in functions and methods,
  • untyped field symbols that have not been assigned a field using ASSIGN,
  • TABLES parameters, if the actual parameter is protected against changes.
  • USING reference parameters and CHANGING parameters in FORMs, if the actual parameter is protected against changes.

  • Access using field symbols if the field assigned using ASSIGN is partly or completely protected (for example key components of internal table of the type SORTED or HASHED TABLE).
  • Access using field symbols if the field assigned using ASSIGN contains components of a secondary key that is currently in use in a higher-level LOOP statement.
  • Access using references if the field bound to the reference is (partly) protected against changes.
  • Write access from outside to READ-ONLY attributes.
  • Content of a shared objects area instance accessed using a shared lock (ATTACH_FOR_READ.
  • Rows or fields in a table that are currently being serialized by a Simple Transformation.

s_nnoorie
Active Participant
0 Kudos

Hi, According to short dump Actual parameter of your program is protected against changes. that why changing parameter is also protected. little changes to the code can solve your problem. Can you post the code so that I can suggest to resolve your problem. Regards Noorie

nomssi
Active Contributor
0 Kudos

Hi Noorie,

check the code from the link to the Code Gallery.


Actually, I can think of a work around: create a sub-structure for non-key field and pass a reference to it as a CHANGING parameter. But my question here is, do you think the dump is normal/expected behavior?

I do not think so. I am actually presuming the error message is wrong. My argument is, the key fields of the structure are not accessed.


best regards,


JNN

matt
Active Contributor
0 Kudos

What happens if instead of using a local defined variable, you define your sorted table as a private attribute of your class?

Edit: I tried it. No difference. Not surprising, really.

matt
Active Contributor
0 Kudos

You get the dump even if you remove the body of the change_text method. My guess is that the CHANGING is somehow requiring that access to the whole structure be available.

To get any further, I think you'll have to report to SAP, unless you can get a response here from someone like

horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

What a coincidence!

We stumbled over exactly that last week internally. The following crashes since the introduction of sorted and hashed tables:

CLASS demo DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS main CHANGING VALUE(p) TYPE scarr.
ENDCLASS.

CLASS demo IMPLEMENTATION.
  METHOD main.
  ENDMETHOD.
ENDCLASS.

DATA itab TYPE SORTED TABLE OF scarr WITH NON-UNIQUE KEY carrid.

START-OF-SELECTION.
  FIELD-SYMBOLS <fs> TYPE scarr.
  INSERT INITIAL LINE INTO itab INDEX 1 ASSIGNING <fs>.
  demo=>main( CHANGING p = <fs> ).

The problem is already addressed to the respective developers, answers pending ...

nomssi
Active Contributor
0 Kudos

Hi Horst,


    CLASS-METHODS main CHANGING VALUE(p) TYPE scarr..

what could be the use case of changing pararameter passed by value?

best regards,

JNN

horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

Now that is neatly documented, I even have a guideline for that.

In short, changing parameters passed by reference are changed immediately, changing parameters passed by value are only returned if the method is left regularly (without exception) via RETURN or ENDMETHOD.

Former Member
0 Kudos

You are passing by reference with CHANGING.

It looks like read-only stuff can't be passed to method CHANGING.

When I pass a literal or constant, there is a syntax error.

System could have given you a syntax error instead of dump.

Have a look at this snippet. Both method calls throw syntax error.

  1. *----------------------------------------------------------------------*
  2. CLASS mainclass DEFINITION.
  3.   PUBLIC SECTION.
  4.     CLASS-METHODS main.
  5.   PRIVATE SECTION.
  6.     CLASS-METHODS passref CHANGING cv_test TYPE i.
  7. ENDCLASS.                    "mainclass DEFINITION
  8. *----------------------------------------------------------------------*
  9. CLASS mainclass IMPLEMENTATION.
  10.   METHOD main.
  11.     "pass literal by ref
  12.     passref(
  13.       CHANGING
  14.         cv_test = '2'
  15.     ).
  16.     "pass constant by ref
  17.     CONSTANTS lc_test TYPE i VALUE 1.
  18.     passref(
  19.       CHANGING
  20.         cv_test = lc_test
  21.     ).
  22.   ENDMETHOD.                    "main
  23.   METHOD passref.
  24.     "nothing
  25.   ENDMETHOD.                    "passref
  26. ENDCLASS.                    "mainclass IMPLEMENTATION
  27. START-OF-SELECTION.
  28.   mainclass=>main( ).

/.

0 Kudos

Hi Manish,

yes, but I would expect this syntax error.

I my code example, the field is not read-only, it is a partly protected field-symbol.

So I am now convinced it is a bug in the standard. I found this while trying to replace a STANDARD table with SORTED tables in my code, so I think it has a major impact and I hope it will be fixed in a future release.

If not, then at least the documentation (in this case, I mean this misleading message from the error analysis)

  • Access using field symbols if the field assigned using ASSIGN is partly or completely protected (for example key components of internal table of the type SORTED or HASHED TABLE).

will be updated to say

  • (for example all components of internal table of the type SORTED or HASHED TABLE).

best regards,

JNN

horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hello,

Here, two things come together:

  • For table expressions, that are internally represented as field symbols, the same restrictions hold as for field symbols specified after READ ASSIGNING: You cannot modify the primary key of sorted and hashed tables (see READ TABLE - result ).
  • Unfortunately, a partial check for modification operations, that guarantees that no key fields are changes is only done in table operations but not if a table line is accessed as a whole. In the latter case any write access is prohibited. As for field symbols, this is only checked at runtime in the moment.

Horst

nomssi
Active Contributor
0 Kudos

Hi Horst,

should we expect

  • a syntax error at compile time or
  • a better partial checking access at compile and run-time

in future releases?

Of course I would prefer the later.

best regards,

JNN

horst_keller
Product and Topic Expert
Product and Topic Expert
0 Kudos

I'm afraid neither nor