Warum passiert das Übergeben eines zugewiesenen Feldsymbols an eine Hash-Tabellenzeile als Änderungsparameter einen Kurzdump?

Question

Warum versucht SAP, im folgenden Fall schlauer zu sein als es sein muss und kurze Speicherauszüge erstellen muss?

REPORT zzy. 

CLASS lcl_main DEFINITION FINAL CREATE PRIVATE. 
    PUBLIC SECTION. 
    CLASS-METHODS: 
     main. 
    PRIVATE SECTION. 
    TYPES: 
     BEGIN OF t_my_type, 
     hierlevel TYPE i, 
     groupname TYPE ktext, 
     result TYPE p LENGTH 9 DECIMALS 2, 
     END OF t_my_type, 
     tt_my_type TYPE HASHED TABLE OF t_my_type WITH UNIQUE KEY hierlevel groupname. 
    CLASS-METHODS: 
     change 
     CHANGING 
      cs_my_type TYPE t_my_type. 
ENDCLASS. 

CLASS lcl_main IMPLEMENTATION. 
    METHOD main. 
    DATA: 
     lt_my_table TYPE tt_my_type. 

    INSERT VALUE #(hierlevel = 0 groupname = 'MY_GROUP' result = '0.0') INTO TABLE lt_my_table 
     ASSIGNING FIELD-SYMBOL(<fs_my_type>). 

    change(
     CHANGING 
     cs_my_type = <fs_my_type> 
    ). 
    ENDMETHOD. 

    METHOD change. 
    ENDMETHOD. 
ENDCLASS. 

START-OF-SELECTION. 
    lcl_main=>main(). 

Es gibt nichts in der Methode geändert change und noch in der Beschreibung der Kurzdump Ich sehe

Feld <FS_MY_TYPE>-HIERLEVEL, war ein neuer Wert zugewiesen, aber dieses Feld ist zumindest teilweise gegen Änderungen geschützt .

Es scheint, dass SAP versucht, schlauer zu sein, als es sein sollte. Ich würde verstehen, wenn der Kurzdump erzeugt wurde, wenn ich tatsächlich versuchte, eines der Schlüsselfelder zu ändern. Warum ist das so gestaltet?

Answer 1

Ich habe entdeckt nur, dass eine weitere Beschreibung in der Kurzdump hat, dass

Die gegen Änderungen geschützt sind folgende:
- Zugriffs Symbole über das Feld, wenn das zugewiesene Feld ASSIGN ist teilweise oder vollständig geschützt (z. B. Schlüsselkomponenten der internen Tabelle des Typs SORTED oder HASHED TABLE).

Ein bisschen seltsam für mich, aber sieht wie eine Designentscheidung aus. Vielleicht war es technisch schwierig, nur nach den Feldern zu suchen, die tatsächlich geschützt sind.

Answer 2

Wenn Sie die Syntax INSERT...ASSIGNING <fs_row> verwenden, sollten Sie sich immer der Einschränkungen bewusst sein, die für das entsprechende Feldsymbol gelten. Laut SAP sind the same Beschränkungen, die in READ TABLE ...ASSIGNING <fs_row> existieren, auch auf INSERT Aufbau angewendet. Insbesondere sind sie:

Solange das Feldsymbol zeigt auf die Zeile, auf die Zuweisungen Feldsymbol die Zeile in der internen Tabelle ändern. Die folgenden Einschränkungen gelten für modifizierende Schlüsselfelder des primären und sekundären Tabellenschlüssels:

• der Schlüsselfelder des Primärtabellenschlüssels von sortierten Tabellen und gehasht Tabellen schreibgeschützt sind, und darf nicht modifiziert werden . Dies würde interne Tabellenverwaltung ungültig machen. Versuche, dies zu tun, führen normalerweise zu einer unbehandelbaren Ausnahme .
  ...

die gleichen Einschränkungen sind as well für Inline-Deklarationen angewendet.
Wie Sie in Ihrem Code sehen, verwenden Sie eine implizite Weitergabe nach Referenzdeklaration für Parameter Ihrer Methode. Aber als Referenz übergeben Sie keine lokalen Datenobjekte für Parameter und works with the actual parameters instead, die sie benötigen beschreibbar sein. Dies ist der Schlüssel zu Ihrer Frage.