ABAPEXPORT_DATA_CLUSTER_MEDIUM - EXPORT DATA CLUSTER MEDIUM

CPI1466 during Backup   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.

EXPORT - medium

Kurzreferenz

Syntax

... { 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, in einer internen Tabelle itab, imABAPMemory, in einer Datenbanktabelle dbtab oder in einem programmübergreifenden Speicherbereich (Angabe SHARED MEMORY oder BUFFER) abgelegt werden.

Alternative 1

... DATA BUFFER xstr

Wirkung

Bei der Angabe von DATA BUFFER wird der Daten-Cluster in das elementare Datenobjekt xstrgeschrieben, 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-Clusterin einem Feld einer Datenbanktabelle mit entsprechendem Datentyp abzulegen. In diesem Fall sollte dieKomprimierung des Daten-Clusters mit dem Zusatz COMPRESSIONin 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 IMPORTFROM DATA BUFFER ausgewertet werden. Bei anderen Auswertungen, etwa bei Vergleichen zwischen Daten-Clustern, ist das Ergebnis undefiniert. Beispielsweise kann der undefinierte Inhalt vonAusrichtungslückenin Strukturen zu unterschiedlichen Daten-Clustern bei ansonsten inhaltsgleichen Strukturen führen.
  
  
  

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 soder ihaben, die zweite Spalte den Typ x. In Abhängigkeit von der Breite der zweiten Spaltewerden 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 nurStandardtabellen ohnesekundä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 dengleichen 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ügbareSpeicherknapp wird kann der Export in eine interne Tabelle eventuell günstiger sein, da deren Speicherblockweise angefordert wird, während der Speicher eines Strings immer an einem Stück vorhanden sein muss.
  
  
  

Alternative 3

... MEMORY ID id

Wirkung

Bei der Angabe von MEMORY wird der Daten-Cluster unter der in id angegebenen Kennung in dasABAP Memory geschrieben. Für id wird einflacheszeichenartigesDatenobjekt erwartet, das eine Kennung von maximal 60 Zeichen enthält, in der die Groß-/Kleinschreibungberücksichtigt wird. Ein bereits vorhandener Daten-Cluster mit der gleichen Kennung idwird 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 einerAufrufkettezur Verfügung, wodurch Daten an aufgerufene Programme übergeben werden können.
  
• Außerhalb von Klassen gibt es noch eine obsoleteKurzform 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

Es werden zwei Felder unter zwei unterschiedlichen Kennungen "P1" und "P2" mit der dynamischen Varianteder Cluster-Definition in das ABAP Memory geschrieben. Nach der Ausführung der Anweisung IMPORT sind die Inhalte der beiden Felder text1 und text2 vertauscht.

TYPES:
  BEGIN OF tab_type,
    para TYPE string,
    dobj TYPE string,
  END OF tab_type.

DATA:
  id    TYPE c LENGTH 10 VALUE 'TEXTS',
  text1 TYPE string VALUE `IKE`,
  text2 TYPE string VALUE `TINA`,
  line  TYPE tab_type,
  itab  TYPE STANDARD TABLE OF tab_type.

line-para = 'P1'.
line-dobj = 'TEXT1'.
APPEND line TO itab.

line-para = 'P2'.
line-dobj = 'TEXT2'.
APPEND line TO itab.

EXPORT (itab)     TO MEMORY ID id.
IMPORT p1 = text2
       p2 = text1 FROM MEMORY ID id.

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 Datenbanktabelle dbtab abgelegt und beim nächstenDatenbank-Commit festgeschrieben. Die Datenbanktabelle muss im ABAP Dictionary mit einem fest vorgegebenenINDX-artigenAufbau definiert sein. Für id wird einflacheszeichenartigesDatenobjekt erwartet, das eine Kennung enthält, die nicht länger ist, als die zwischen den SpaltenRELID undSRTF2definierten Schlüsselfelder der INDX-artigen Tabelle. In der Kennung wird die Groß-/Kleinschreibung berücksichtigt.

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

Hinter FROM kann ein Arbeitsbereich wa angegeben werden, der den gleichen Datentyp wiedie Datenbanktabelle dbtab haben muss. Beim Export werden die aktuellen Werte der Komponenten von wa, die zwischen den FeldernSRTF2 undCLUSTRliegen, 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 Datentransportin diese Datenbankfelder statt. Wenn der Zusatz FROM wa außerhalb von Klassen nicht angegeben ist, mit der Anweisung TABLES aber einTabellenarbeitsbereichfür die Datenbanktabelle dbtab deklariert ist, werden beim Export die aktuellen Werte der entsprechenden Komponenten des Tabellenarbeitsbereichs dbtab in die Zeilen der Datenbanktabelle geschrieben.

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

Hinweise

• Daten-Cluster in Datenbanken werden bei der Migration von einer Nicht-Unicode-Datenbank in einUnicode-Systemnicht konvertiert. In einem Unicode-System gibt es deshalb unter Umständen Daten-Cluster, dieNicht-Unicode-Zeichen enthalten. Diese Zeichen werden bei jedem Import automatisch in Unicode-Zeichenkonvertiert. Beim Export von Daten werden in Unicode-Systemen die in den abgelegten Datenobjekten eventuell enthaltenen Unicode-Zeichen plattformspezifisch abgelegt.
  
• Die implizite Verwendung eines Tabellenarbeitsbereichs statt der expliziten Angabe von FROM wa ist alsobsolete Kurzform zu betrachten.
  
• Da jeder Mandant eine in sich abgeschlossene Einheit darstellt, sollte der Zusatz CLIENT in Anwendungsprogrammen nicht verwendet werden. Auf Systemen mitMultitenancy wird dies von der ABAP-Laufzeitumgebung zugesichert.
  
  
  

Beispiel

Es wird eine interne Tabelle itab unter dem Namen tab und der Kennung "TABLE" in den Bereich "XY" der von SAP ausgelieferten DatenbanktabelleINDX exportiert, wobei die frei wählbaren Komponenten aus der Struktur wa_indx versorgt werden.

TYPES:
  BEGIN OF tab_type,
    col1 TYPE i,
    col2 TYPE i,
  END OF tab_type.

DATA:
  wa_indx TYPE indx,
  wa_itab TYPE tab_type,
  cl      TYPE mandt VALUE '100',
  itab    TYPE STANDARD TABLE OF tab_type.

WHILE sy-index < 100.
  wa_itab-col1 = sy-index.
  wa_itab-col2 = sy-index ** 2.
  APPEND wa_itab TO itab.
ENDWHILE.

wa_indx-aedat = sy-datum.
wa_indx-usera = sy-uname.
wa_indx-pgmid = sy-repid.

EXPORT tab = itab
  TO DATABASE indx(XY)
  FROM wa_indx
  CLIENT cl
  ID 'TABLE'.

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 intransaktionsübergreifenden Anwendungspuffern desShared Memory auf demApplikationsservergespeichert, auf die alle Programme des gleichen Applikationsservers gemeinsam zugreifen.

Die beiden Anwendungspuffer unterscheiden sich darin, wie sich das System beim Erreichen der Speichergrenzeverhält. Beide Anwendungspuffer können bis zu einer internen Höchstgrenze gefüllt werden, die über dieProfilparameterrsdb/esm/buffersize_kb (SHARED MEMORY) undrsdb/obj/buffersize(SHARED BUFFER) einstellbar sind. Bevor die Höchstgrenze des Puffers von SHARED MEMORYerreicht wird, muss vor einem erneuten Export explizit mit der Anweisung DELETEFROM 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 einVerdrä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 Zeilenstrukturdurch dbtab definiert wird. Für dbtab muss eine Datenbanktabelle aus dem ABAP Dictionary angegeben werden, die den gleichenAufbauwie bei einer Ablage in der Datenbanktabelle selbst hat. Der Zeilenbereich ar, der Arbeitsbereichwa, der optionale Mandant cl und die Kennung id haben für die Speichertabelledie gleiche Bedeutung wie beim Speichern in einer Datenbanktabelle, mit der Ausnahme, dass die Längeder 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 Datenbanktabelle genommen, obwohl die Daten nicht in der Tabelle selbst, sondern in einer entsprechend aufgebauten Speichertabelle abgelegt werden.
  
  
• 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 einbestehendes Daten-Cluster mit einem größeren überschrieben werden soll, dabei aberdie Speichergrenze überschritten werden würde, dann führt dies nur zur Löschung des bisherigen Daten-Clusters.
  
  
• Statt der Ablage von Daten-Clustern im Shared Memory wird die Verwendung vonSharedObjects 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.
  
  
  

General Material Data   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.


Length: 19887 Date: 20120526 Time: 200335     triton ( 446 ms )