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 in INTO CORRESPONDING FIELDS OF field-symbol structure

Former Member
0 Kudos

Dear gurus,

I get a Short Dump error everytime I use this piece of code (Header pasted later):

     LOOP AT lt_idocs ASSIGNING <lf_idocs>.

       SELECT docnum

              counter

              segnum

         INTO TABLE lt_segmen_init

         FROM edid4

         WHERE docnum EQ <lf_idocs>-docnum.

       LOOP AT lt_segmen_init ASSIGNING <lf_segmen>.

         SELECT SINGLE segnam

                       dtint2

                       sdata

           INTO CORRESPONDING FIELDS OF <lf_segmen>

           FROM edid4

           WHERE docnum  EQ <lf_segmen>-docnum

             AND counter EQ <lf_segmen>-counter

             AND segnum  EQ <lf_segmen>-segnum.

       ENDLOOP.

       APPEND LINES OF lt_segmen_init TO lt_segmen.

     ENDLOOP.

But if I use this one (Using structure)...

   DATA: ls_segmen TYPE ty_segmen.

   LOOP AT lt_idocs ASSIGNING <lf_idocs>.

     SELECT docnum

            counter

            segnum

       INTO TABLE lt_segmen_init

       FROM edid4

       WHERE docnum EQ <lf_idocs>-docnum.

     LOOP AT lt_segmen_init INTO ls_segmen.

       SELECT SINGLE segnam

                     dtint2

                     sdata

         FROM edid4

         INTO CORRESPONDING FIELDS OF ls_segmen

         WHERE docnum  EQ ls_segmen-docnum

           AND counter EQ ls_segmen-counter

           AND segnum  EQ ls_segmen-segnum.

       APPEND ls_segmen TO lt_segmen.

     ENDLOOP.

   ENDLOOP.

...or this one (Choosing individual fields of the field-symbol explicitly)...

     LOOP AT lt_idocs ASSIGNING <lf_idocs>.

       SELECT docnum

              counter

              segnum

         INTO TABLE lt_segmen_init

         FROM edid4

         WHERE docnum EQ <lf_idocs>-docnum.

       LOOP AT lt_segmen_init ASSIGNING <lf_segmen>.

         SELECT SINGLE segnam

                       dtint2

                       sdata

           INTO (<lf_segmen>-segnam,

                 <lf_segmen>-dtint2,

                 <lf_segmen>-sdata)

           FROM edid4

           WHERE docnum  EQ <lf_segmen>-docnum

             AND counter EQ <lf_segmen>-counter

             AND segnum  EQ <lf_segmen>-segnum.

       ENDLOOP.

       INSERT LINES OF lt_segmen_init INTO TABLE lt_segmen.

     ENDLOOP.

...it works fine.

Header here:

TYPES: BEGIN OF ty_idocs,

          docnum TYPE edidc-docnum,

          credat TYPE edidc-credat,

        END OF ty_idocs,

        ty_h_idocs TYPE HASHED TABLE OF ty_idocs

                     WITH UNIQUE KEY docnum,

        BEGIN OF ty_segmen,

          docnum    TYPE edi_docnum,

          counter   TYPE edi_clustc,

          segnum    TYPE idocdsgnum,

          segnam    TYPE edi_segnam,

          dtint2    TYPE edi_dtint2,

          sdata     TYPE edi_sdata,

        END OF ty_segmen,

        ty_o_segmen TYPE SORTED TABLE OF ty_segmen

                      WITH UNIQUE KEY docnum

                                      counter

                                      segnum.

CONSTANTS: lc_mestyp TYPE edi_mestyp

                        VALUE 'ZDEM_SERVICIO_SAC'.

DATA: lt_idocs  TYPE ty_h_idocs.

DATA: lt_segmen_init TYPE ty_o_segmen,

       lt_segmen      TYPE ty_o_segmen.

FIELD-SYMBOLS: <lf_idocs>  TYPE ty_idocs,

                <lf_segmen> TYPE ty_segmen.

START-OF-SELECTION.

   SELECT docnum

          credat

     FROM edidc

     INTO TABLE lt_idocs

     WHERE mestyp EQ lc_mestyp

       %_HINTS ORACLE 'INDEX("EDIDC" "EDIDC~3")'.

[Here goes the segment selection...]

The error in Dump reads something like the following: '<LF_SEGMEN>-DOCNUM' field is being forced to be overwritten (and fails because it is key of the internal table). But I think I don't try to.

With references fails too.

Does anyone know why?

Thanks a lot!,

Eloi

1 ACCEPTED SOLUTION

Ryan-Crosby
Active Contributor
0 Kudos

Hi Eloi,

I replicated the example in my system to test and this is the key piece of information from the short dump:

If you change the table declaration to a standard table it works fine - however, as a note I'm not sure why you would select some fields on EDID4 and then within a LOOP go select more fields on EDID4 instead of simply getting all of the fields you require in one selection.

Regards,

Ryan Crosby

10 REPLIES 10

Former Member
0 Kudos

Rather than "the error in the dump reads something like...", why don't you just post the relevant portion of the dump (the part containing the code plus the error)?

Rob

0 Kudos

Hello Rob,

Here:

Runtime Errors         MOVE_TO_LIT_NOTALLOWED_NODATA

Short Text

Assignment error: Overwriting of a protected field.

Error analysis

Field "<LF_SEGMEN>-DOCNUM" 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.

How to correct this error

The field to be overwritten is either a parameter or a field symbol.

Declare the parameter as a VALUE. Alternatively, either enter a help

field that already contains the constant or assign this help field to

the field symbol instead of the constants.

If the error occurred in your own ABAP program or in an SAP

program you modified, try to remove the error. [...]

Code:

  110     LOOP AT lt_idocs ASSIGNING <lf_idocs>.

  111       SELECT docnum

  112              counter

  113              segnum

  114         INTO TABLE lt_segmen_init

  115         FROM edid4

  116         WHERE docnum EQ <lf_idocs>-docnum.

  117       LOOP AT lt_segmen_init ASSIGNING <lf_segmen>.

>>>>>         SELECT SINGLE segnam

  119                       dtint2

  120                       sdata

  121           INTO CORRESPONDING FIELDS OF <lf_segmen>

  122           FROM edid4

  123           WHERE docnum  EQ <lf_segmen>-docnum

  124             AND counter EQ <lf_segmen>-counter

  125             AND segnum  EQ <lf_segmen>-segnum.

  126       ENDLOOP.

  127       APPEND LINES OF lt_segmen_init TO lt_segmen.

  128     ENDLOOP.

Many thanks,

Eloi

0 Kudos

  110     LOOP AT lt_idocs ASSIGNING <lf_idocs>.

  111       SELECT docnum

  112              counter

  113              segnum

  114         INTO TABLE lt_segmen_init

  115         FROM edid4

  116         WHERE docnum EQ <lf_idocs>-docnum.

  117       LOOP AT lt_segmen_init ASSIGNING <lf_segmen>.

>>>>>         SELECT SINGLE segnam

  119                       dtint2

  120                       sdata

  121           INTO CORRESPONDING FIELDS OF <lf_segmen>

  122           FROM edid4

  123           WHERE docnum  EQ <lf_segmen>-docnum

  124             AND counter EQ <lf_segmen>-counter

  125             AND segnum  EQ <lf_segmen>-segnum.

  126       ENDLOOP.

  127       APPEND LINES OF lt_segmen_init TO lt_segmen.

  128     ENDLOOP.

You are passing the data back to field symbol you use as condition? not sure if this is possible. + Select inside loop is not advisable. Do this instead:

lt_idocs_tmp[] = lt_idocs[].

SORT lt_idocs_tmp BY docnum.

DELETE ADJACENT DUPLICATES FROM LT_IDOCS_TMP comparing DOCNUM.

SELECT docnum counter segnum

   FROM edid4

   INTO TABLE lt_segmen_init

   FOR ALL ENTRIES IN lt_idocs_tmp

   WHERE docnum EQ lt_idocs_tmp-docnum.

IF sy-subrc EQ 0.

   SELECT segnam dtint2 sdata

     FROM edid4

     INTO CORRESPONDING FIELDS OF TABLE lt_segmen(new table)

     FOR ALL ENTRIES IN lt_segmen_init

     WHERE docnum  EQ lt_segmen_init-docnum

      AND counter EQ lt_segmen_init-counter

      AND segnum  EQ lt_segmen_init-segnum.

ENDIF.

0 Kudos

Hello Elzkie,

First of all, thanks for your collaboration; but I don't think it will work.

Your example, as I think, lacks of correlation between table LT_SEGMEN_INIT and LT_SEGMEN.

How do I know which SEGNAM+DTINT2+SDATA goes with its corresponding DOCNUM+COUNTER+SEGNUM?


It's a common misconception to think that DB reads return [guaranteed] lines sorted by key.


Thanks,


Eloi

Ryan-Crosby
Active Contributor
0 Kudos

Hi Eloi,

I replicated the example in my system to test and this is the key piece of information from the short dump:

If you change the table declaration to a standard table it works fine - however, as a note I'm not sure why you would select some fields on EDID4 and then within a LOOP go select more fields on EDID4 instead of simply getting all of the fields you require in one selection.

Regards,

Ryan Crosby

0 Kudos

Hello Ryan,


If you change the table declaration to a standard table it works fine

I think STANDARD table does not cause the problem due to lack of key uniqueness.


I'm not sure why you would select some fields on EDID4 and then within a LOOP go select more fields on EDID4 instead of simply getting all of the fields you require in one selection.

I'm testing performance. ATC explains selection on field EDID4-SDATA (being a LCHR) may cause DB access time increase (due to FOR ALL ENTRIES clausule).

Thanks anyway,

Eloi

0 Kudos

Hi Eloi,

Didn't I state the same answer as Gabor below?  And yes, it is a result of the uniqueness.  As far as the FOR ALL ENTRIES vs. Re-SELECT within a LOOP - there might be some performance gain but I doubt it would be very big.

Regards,

Ryan Crosby

0 Kudos

Yes, my fault. Marked as helpful.

On the other hand, what I don't understand is why if I choose individual fields explicitly (of the Field-Symbol) it works.

           INTO (<lf_segmen>-segnam,

                 <lf_segmen>-dtint2,

                 <lf_segmen>-sdata)


As read in the dump description, it would have to crash too. ¿No?

Well, I will code it this way from now on, in case I shall need it.



Thanks everyone that contributed so far.

Eloi

0 Kudos

Hi Eloi,

I most certainly understand the puzzling case here as I would think the same.  I think in this case it's a difference between how the underlying code is executed with respect to access vs. update when you use INTO CORRESPONDING vs. giving the unique fields as a target.  Somehow the system must be interpreting that as you are trying to insert a new row into the table with a key that already exists instead of updating the fields of the row.

Regards,

Ryan Crosby

0 Kudos

With explicit field names, the system doesn't find docnum key field nor other protected field, so no error. With corresponding option, it seems to consider you are trying to modify whole record structure, so every field and error raised.

Regards,

Raymond