Kontakt

Ansicht
Dokumentation

ABAPEXPORT_DATA_CLUSTER_MEDIUM - EXPORT DATA CLUSTER MEDIUM

ABAPEXPORT_DATA_CLUSTER_MEDIUM - EXPORT DATA CLUSTER MEDIUM

CL_GUI_FRONTEND_SERVICES - Frontend Services   Fill RESBD Structure from EBP Component Structure  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

EXPORT, medium

Kurzreferenz



... ${ DATA BUFFER xstr $}
  $| ${ INTERNAL TABLE itab $}
  $| ${ MEMORY ID id $}
  $| ${ DATABASE      dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id $}
  $| ${ SHARED MEMORY dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id $}
  $| ${ SHARED BUFFER dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id $} ...

Alternativen:

1. ... DATA BUFFER xstr

2. ... INTERNAL TABLE itab

3. ... MEMORY ID id

4. ... DATABASE dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id

5. ... SHARED MEMORY dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id

6. ... SHARED BUFFER dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id

Wirkung

Der exportierte Daten-Cluster kann in einem Bytestring xstr oder in einer internen Tabelle itab , im ABAP Memory, in einer Datenbanktabelle dbtab oder in einem programmübergreifenden Speicherbereich (Angabe SHARED MEMORY oder BUFFER) abgelegt werden.

Hinweis

Der binäre Inhalt des Daten-Clusters kann aus Optimierungsgründen von der Art der Ablage abhängen. Ein Daten-Cluster, der in mehreren Teilen abgelegt ist, ergibt zusammengesetzt nicht unbedingt einen Daten-Cluster, der in einem Stück abgelegt ist. Ein Daten-Cluster kann deshalb in der Regel nur mit einer zur Ablage passenden IMPORT-Anweisung eingelesen werden. Insbesondere kann ein in einer Struktur für Export-/Import-Tabellen in mehreren Zeilen abgelegter Daten-Cluster nicht in jedem Fall zu einer Bytekette verkettet werden, die mit FROM DATA BUFFER importiert werden kann. Auch Daten-Cluster, die in mehreren Zeilen abgelegt sind, können sich je nach Ablagemethode unterscheiden. Dies bedeutet, dass sich ein mit INTERNAL TABLE abgelegter Daten-Cluster von einem Daten-Cluster für dieselben Daten in Export-/Import-Tabellen unterscheiden kann, insbesondere wenn sie in unterschiedlichen Releases oder für unterschiedliche Codepages abgelegt wurden.

Beispiel

Das Programm DEMO_DATA_CLUSTER zeigt, dass die Größe des Daten-Clusters weitgehend unabhängig von der Art der Ablage ist.

Alternative 1

... DATA BUFFER xstr


Wirkung

Bei der Angabe von DATA BUFFER wird der Daten-Cluster in das elementare Datenobjekt xstr geschrieben, das vom Typ xstring sein muss. Der vorhergehende Inhalt von xstr wird dabei vollständig überschrieben.

Hinweise

  • Ein mit EXPORT TO DATA BUFFER gefülltes Datenobjekt xstr enthält genau einen Daten-Cluster.
  • Eine gängige Anwendung für den Zusatz DATA BUFFER ist es, den erzeugten Daten-Cluster in einem Feld einer DDIC-Datenbanktabelle mit entsprechendem Datentyp abzulegen. In diesem Fall sollte die Komprimierung des Daten-Clusters mit dem Zusatz COMPRESSION in Erwägung gezogen werden, da die Komprimierung standardmäßig nur bei der direkten Angabe von DATABASE als Medium eingeschaltet ist.
  • Der Inhalt eines mit EXPORT TO DATA BUFFER gefüllten Datenobjekts darf nur mit IMPORT FROM DATA BUFFER ausgewertet werden. Bei anderen Auswertungen, etwa bei Vergleichen zwischen Daten-Clustern, ist das Ergebnis undefiniert. Beispielsweise kann der undefinierte Inhalt von Ausrichtungslücken in Strukturen zu unterschiedlichen Daten-Clustern bei ansonsten inhaltsgleichen Strukturen führen.

Beispiel

Export einer internen Tabelle in einen Bytestring und Ablage desselben in einer Datenbanktabelle. Nach dem Einlesen des Bytestrings aus der DDIC-Datenbanktabelle kann der Inhalt des Daten-Clusters in eine andere interne Tabelle importiert werden.

Alternative 2

... INTERNAL TABLE itab


Wirkung

Bei der Angabe von INTERNAL TABLE wird der Daten-Cluster in der internen Tabelle itab abgelegt. Der vorhergehende Inhalt von itab wird dabei vollständig überschrieben.

Die erste Spalte von itab muss den Datentyp s oder i haben, die zweite Spalte den Typ x. In Abhängigkeit von der Breite der zweiten Spalte werden die Daten bei Bedarf über mehrere Tabellenzeilen verteilt abgelegt. Die erste Spalte enthält die in der zweiten Spalte belegte Länge. Als Tabellenart sind für itab nur Standardtabellen ohne sekundäre Tabellenschlüssel erlaubt.

Hinweise

  • Eine mit EXPORT TO INTERNAL TABLE gefüllte interne Tabelle itab enthält genau einen Daten-Cluster.
  • Der Inhalt einer mit EXPORT TO INTERNAL TABLE gefüllten internen Tabelle darf aus den gleichen Gründen wie bei EXPORT TO DATA BUFFER nur mit IMPORT FROM INTERNAL TABLE ausgewertet werden.
  • In der Regel ist die Variante EXPORT TO DATA BUFFER der Variante EXPORT TO INTERNAL TABLE vorzuziehen, da sie einfacher zu handhaben ist. Nur bei sehr großen Daten-Clustern und wenn der verfügbare Speicher knapp wird kann der Export in eine interne Tabelle eventuell günstiger sein, da deren Speicher blockweise angefordert wird, während der Speicher eines Strings immer an einem Stück vorhanden sein muss.

Beispiel

Export einer internen Tabelle in einen Datencluster in einer internen Tabelle und Import in eine andere interne Tabelle.

Alternative 3

... MEMORY ID id


Wirkung

Bei der Angabe von MEMORY wird der Daten-Cluster unter der in id angegebenen Kennung in das ABAP Memory geschrieben. Für id wird ein flaches zeichenartiges Datenobjekt erwartet, das eine Kennung von maximal 60 Zeichen enthält, in der die Groß-/Kleinschreibung berücksichtigt wird. Ein bereits vorhandener Daten-Cluster mit der gleichen Kennung id wird vollständig überschrieben. Durch die Kennung in id wird ein Daten-Cluster in der Ablage identifiziert und kann mit derselben Kennung wieder ausgelesen werden.

Hinweise

  • Ein Daten-Cluster im ABAP Memory steht allen Programmen innerhalb einer Aufrufkette zur Verfügung, wodurch Daten an aufgerufene Programme übergeben werden können.
  • Außerhalb von Klassen gibt es noch eine obsolete Kurzform in welcher der Zusatz ID weggelassen werden kann. Dies ist jedoch fehleranfällig, da alle EXPORT-Anweisungen ohne Kennung den gleichen Daten-Cluster überschreiben.

Beispiel

Export zweier Textstrings unter den Bezeichnern P1 und P2 in das ABAP Memory. Nach der Ausführung der Anweisung IMPORT sind die Inhalte der beiden Felder text1 und text2 vertauscht.



Alternative 4

... DATABASE dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id


Wirkung

Bei der Angabe von DATABASE wird der Daten-Cluster unter der Kennung id in der DDIC-Datenbanktabelle dbtab abgelegt und beim nächsten Datenbank-Commit festgeschrieben. Die DDIC-Datenbanktabelle muss eine Export-/Import-Tabelle mit einem vorgegebenen Aufbau sein. Für id wird ein flaches zeichenartiges Datenobjekt erwartet, das eine Kennung enthält, die nicht länger ist, als die zwischen den Spalten RELID und SRTF2 definierten Schlüsselfelder der Export-/Import-Tabelle. In der Kennung wird die Groß-/Kleinschreibung berücksichtigt.

Mit dem zweistelligen Bereich ar, der direkt angegeben werden muss, werden die Zeilen der Datenbanktabelle in verschiedene Bereiche unterteilt, sodass Daten-Cluster gleicher Kennung id mehrmals in der DDIC-Datenbanktabelle vorkommen können.

Hinter FROM kann ein Arbeitsbereich wa angegeben werden, der den gleichen Datentyp wie die Export-/Import-Tabelle dbtab haben muss. Beim Export werden die aktuellen Werte der Komponenten von wa, die zwischen den Feldern SRTF2 und CLUSTR liegen, in die gleichnamigen Felder jeder vom Daten-Cluster belegte Zeile der Datenbanktabelle geschrieben. Wenn der Zusatz FROM wa innerhalb von Klassen nicht angegeben ist, findet kein Datentransport in diese Datenbankfelder statt. Wenn der Zusatz FROM wa außerhalb von Klassen nicht angegeben ist, mit der Anweisung TABLES aber ein Tabellenarbeitsbereich für die Export-/Import-Tabelle dbtab deklariert ist, werden beim Export die aktuellen Werte der entsprechenden Komponenten des Tabellenarbeitsbereichs dbtab in die Zeilen der DDIC-Datenbanktabelle geschrieben.

Falls die Export-/Import-Tabelle dbtab mandantenabhängig ist, kann hinter dem Zusatz CLIENT ein flaches zeichenartiges Feld cl angegeben werden, das eine Mandantenkennung enthält. Falls der Zusatz nicht angegeben ist, wird der aktuelle Mandant verwendet. Die Spalte MANDT jeder vom Daten-Cluster belegten Zeile der Datenbanktabelle wird beim Export mit dieser Mandantenkennung gefüllt.

Hinweise

  • Die Anweisung EXPORT TO DATABASE setzt bis zum nächsten Datenbank-Commit bzw. -Rollback eine Datenbanksperre, wodurch es bei falscher Verwendung zu einer Verklemmung (deadlock) kommen kann.
  • Daten-Cluster in Datenbanken werden bei der Migration von einer Nicht-Unicode-Datenbank in ein Unicode-System nicht konvertiert. In einem Unicode-System gibt es deshalb unter Umständen Daten-Cluster, die Nicht-Unicode-Zeichen enthalten. Diese Zeichen werden bei jedem Import automatisch in Unicode-Zeichen konvertiert. Beim Export von Daten werden in Unicode-Systemen die in den abgelegten Datenobjekten enthaltenen Unicode-Zeichen plattformspezifisch abgelegt.
  • Die implizite Verwendung eines Tabellenarbeitsbereichs statt der expliziten Angabe von FROM wa ist als obsolete Kurzform zu betrachten.
  • Da jeder Mandant eine in sich abgeschlossene Einheit darstellt, sollte der Zusatz CLIENT in Anwendungsprogrammen nicht verwendet werden.

Beispiel

Exports an internal table itab with the name scarr_tab and the ID SCARR to the range SC of the DDIC database table DEMO_INDX_BLOB. Die frei wählbaren Komponenten werden aus der Struktur wa versorgt.

Alternative 5

... SHARED MEMORY dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id


Alternative 6

... SHARED BUFFER dbtab(ar) $[FROM wa$] $[CLIENT cl$] ID id


Wirkung

Bei der Angabe von SHARED MEMORY oder SHARED BUFFER wird der Daten-Cluster in transaktionsübergreifenden Anwendungspuffern des Shared Memory der aktuellen gespeichert, auf die alle Programme der gleichen gemeinsam zugreifen.

Die beiden Anwendungspuffer unterscheiden sich darin, wie sich das System beim Erreichen der Speichergrenze verhält. Beide Anwendungspuffer können bis zu einer internen Höchstgrenze gefüllt werden, die über die Profilparameter rsdb/esm/buffersize_kb (SHARED MEMORY) und rsdb/obj/buffersize (SHARED BUFFER) einstellbar sind.

  • Bevor die Höchstgrenze des Puffers von SHARED MEMORY erreicht wird, muss vor einem erneuten Export explizit mit der Anweisung DELETE FROM SHARED MEMORY Platz geschaffen werden, ansonsten kommt es zu einer behandelbaren Ausnahme.
  • Der Puffer von SHARED BUFFER wird automatisch bei Erreichen der Höchstgrenze durch ein Verdrängungsverfahren geleert. Dabei werden diejenigen Datenobjekte aus dem Puffer entfernt, die bisher am wenigsten benutzt wurden.

Beim Ablegen der Daten erzeugt das System eine Speichertabelle im Anwendungspuffer, deren Zeilenstruktur durch dbtab definiert wird. Für dbtab muss eine Datenbanktabelle aus dem ABAP Dictionary angegeben werden, die den Aufbau einer Export-/Import-Tabelle hat. Der Zeilenbereich ar, der Arbeitsbereich wa, der optionale Mandant cl und die Kennung id haben für die Speichertabelle die gleiche Bedeutung wie beim Speichern in einer Datenbanktabelle, mit der Ausnahme, dass die Länge der Kennung in id zusätzlich auf 59 bzw. 62 Zeichen beschränkt ist, je nachdem, ob der Zusatz CLIENT angegeben ist oder nicht.

Hinweise

  • Bei der Ablage im Shared Memory wird Bezug auf eine Export-/Import-Tabelle genommen, obwohl die Daten nicht in der Tabelle selbst, sondern in einer entsprechend aufgebauten Speichertabelle abgelegt werden.
  • Die Länge der zwischen den Spalten RELID und SRTF2 definierten Schlüsselfelder der adressierten Export-/Import-Tabelle darf 59 bzw. 62 Zeichen, nicht überschreiten, je nachdem ob eine Mandantenspalte vorhanden ist oder nicht.
  • Beim Export von Daten wird ein eventuell bereits vorhandenes Daten-Cluster mit gleichem Mandanten cl, Zeilenbereich ar und Kennung id überschrieben. Falls bei SHARED MEMORY ein bestehendes Daten-Cluster mit einem größeren überschrieben werden soll, dabei aber die Speichergrenze überschritten werden würde, dann führt dies nur zur Löschung des bisherigen Daten-Clusters.
  • Statt der Verwendung von Daten-Clustern im Shared Memory wird die Verwendung von Shared Objects empfohlen. Shared Objects erlauben das Ablegen von Objekten mit komplexen Abhängigkeiten, können wie normale Objekte bearbeitet werden und erlauben den kopierfreien Zugriff auf das Shared Memory durch mehrere Verwender.

Beispiel

Export einer internen Tabelle itab unter dem Namen scarr_tab und der Kennung SCARR in den transaktionsübergreifenden Anwendungspuffer. Die Zeilenstruktur der Speichertabelle entspricht der Export-/Import-Tabelle DEMO_INDX_BLOB.






ROGBILLS - Synchronize billing plans   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 21435 Date: 20240423 Time: 134538     sap01-206 ( 317 ms )