Unterschiede in der ABAP-Länge

Re: Unterschiede in der ABAP-Länge

hi!

Ich weiß jetzt nicht, wie die RFC-Schnittstelle auf unterschiedliche Strukturdefinition in Hinblick auf die Reihenfolge reagiert.
Persönlich würde ich erwarten, dass die Strukurlänge entscheidend ist. Sprich ist die Länge gleich, werden die Felder von links nach rechts aufgefüllt und das unabhängig von ihrer Reihenfolge. Dadurch kann es mitunter sein, dass der Inhalt eines Quell-Feldes auf mehrere Zielfelder aufgeteilt wird bzw. die Inhalte mehrerer Quellfelder in ein und demselben Zielfeld landen.
Aber ich kann mich auch täuschen

Wie hast du denn die Struktur mit den INCLUDES definiert?
Mit INCLUDE TYPE (.INCLUDE im DDIC) oder ist jedes Teil-Include als eigenes Feld per Name eingebunden?

lg ADT

Re: Unterschiede in der ABAP-Länge

Aus der Hilfe zur Strukturlänge:

Die hier angezeigten Längen haben folgende Bedeutung:

In der Spalte 'Dictionary' ist die Summe der Angaben aus der Spalte
'Länge' der Komponentenanzeige aufaddiert. Strukturierte Komponenten
werden dabei expandiert, sofern sie nicht Type ... Boxed sind.

Die Spalte ABAP liefert die Gesamtlänge in der Laufzeitumgebung. Sie wird
aus dem zugehörigen Laufzeitobjekt übernommen.

Im Laufzeitobjekt muss je nach Komponententyp die Komponente ausgerichtet
werden, was die Gesamtlänge beeinflusst. Daher können sich die Summen
voneinander unterscheiden.

Das erklärt zumindest den Unterschied zwischen DB und DDIC aber der Unterschied zwischen zwei Strukturen mit denselben Feldern eher nicht.
(Hier gehts vor allem darum wenn man Zahlenfelder verwendet, dass die im Speicher mitunter anders verwaltet werden)

Wie schauen denn deine Strukturen aus? Kannst du die mal posten?

Re: Unterschiede in der ABAP-Länge

a-dead-trousers hat geschrieben:Das erklärt zumindest den Unterschied zwischen DB und DDIC aber der Unterschied zwischen zwei Strukturen mit denselben Feldern eher nicht.

Doch, auch das wird damit erklärt.

Denn wenn eine Struktur als erste Komponente ein Feld vom Typ X mit Länge 1 hat (oder in Nicht-Unicode-Systemen ein Feld vom Typ C mit Länge 1), danach ein Feld vom Typ I, dann wird es dazwischen eine Alignment-Lücke von 3 Bytes geben (mal angenommen, die Architektur verlangt 4-Byte-Alignment für Integers).
Wenn nun diese Include-Struktur in eine andere Struktur eingebunden wird, dürfte auch die Struktur selbst an 4-Byte-Grenzen ausgerichtet werden, d.h., je nach Länge der vorherigen Komponenten incl. Alignment-Lücken gibt es unmittelbar vor der Struktur auch eine Alignment-Lücke. (Das kann man mit einem Mini-ABAP-Report und dem Befehle DESCRIBE DISTANCE ... leicht prüfen.)
Wenn statt des Includes nun aber Einzelfelder in die Struktur aufgenommen werden, wird das erste Feld vom Typ X ohne Alignment-Lücke direkt an das vorherige Feld geklebt. Dann hätte man also eine Abweichung der Gesamtlänge, die durch ein Alignment vor dem Feld mit Typ X verursacht wird, falls nicht die Einzelfelder eingebunden werden, sondern die komplette Struktur.
Auch zwischen diesem Feld vom Typ X und dem nachfolgenden vom Typ I muss beim Einbinden von Einzelfeldern die Alignment-Lücke nicht unbedingt 3 Bytes sein. Sie kann auch kleiner sein oder ganz entfallen, je nachdem, welche Gesamtlänge in Bytes erreicht ist, bevor das Feld vom Typ I kommt.

Frank