READ und Schlüssel von internen Tabellen
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo Forum,
ich wollte eine verschachtelte Loop in Loop-Schleife vermeiden und innerhalb der ersten Loop ein READ einsetzen.
Hm, mit dem Schlüssel einer internen Tabelle bin ich noch nicht so vetraut, ganz gezielt habe ich beim Stöbern in der Onlinehilfe auch nichts aussagekräftiges gefunden. Wenn es denn so ist, dass der Schlüssel wie bei einer transparenten Tabelle von links nach rechts aufgebaut ist und er auch genau so verwendet werden muss, dann habe ich in meinem Fall keine Chance: Das einzige für mich verwendbare Feld zur Suche liegt etwa an 6.er Stelle...
Ich hatte mir eigentlich eingebildet (gewünscht
), dass READ auf eine interne Tabelle ähnlich wie ein Select auf eine transparente Tabelle funktioniert, dem ist offensichtlich nicht so - oder geht das doch irgendwie und ich habe das berühmte Brett vor dem Kopf?
Hilfe: Unter "InterneTabellen/Interne Tabellen bearbeiten/Operationen für alle Tabellenarten/Tabellenzeilen lesen" ist u. a. diese Beispielzeile:
READ TABLE itab FROM line INTO line COMPARING col2.
Das habe ich so getestet:
READ TABLE it_z91 FROM wa_z9o INTO wa_z9o COMPARING arbpl.
Alles die gleiche Struktur, col2 dürfte hier doch auch col5 oder 6 sein (da liegt etwa arbpl)?
Allerdings habe ich zu diesem Zeitpunkt wie oben geschildert nur einen Wert in der gesamten Workarea wa_z9o, nämlich in wa_z9o-arbpl, alle anderen Felder sind leer und somit ist natürlich kein Schlüssel befüllt.
Sy-Subrc steht Satz für Satz auf 4
, auch wenn die Übereinstimmung gegeben ist.
Geht es halt so nicht oder ist noch etwas falsch?
Loop in Loop (so läuft's jetzt halt) ist hier aus Performancegründen kein Problem (wenig Daten, ich wollte das nur prinzipiell testen).
Gruss aus dem verschneiten Süden
Gino
ich wollte eine verschachtelte Loop in Loop-Schleife vermeiden und innerhalb der ersten Loop ein READ einsetzen.
Hm, mit dem Schlüssel einer internen Tabelle bin ich noch nicht so vetraut, ganz gezielt habe ich beim Stöbern in der Onlinehilfe auch nichts aussagekräftiges gefunden. Wenn es denn so ist, dass der Schlüssel wie bei einer transparenten Tabelle von links nach rechts aufgebaut ist und er auch genau so verwendet werden muss, dann habe ich in meinem Fall keine Chance: Das einzige für mich verwendbare Feld zur Suche liegt etwa an 6.er Stelle... Ich hatte mir eigentlich eingebildet (gewünscht
), dass READ auf eine interne Tabelle ähnlich wie ein Select auf eine transparente Tabelle funktioniert, dem ist offensichtlich nicht so - oder geht das doch irgendwie und ich habe das berühmte Brett vor dem Kopf?Hilfe: Unter "InterneTabellen/Interne Tabellen bearbeiten/Operationen für alle Tabellenarten/Tabellenzeilen lesen" ist u. a. diese Beispielzeile:
READ TABLE itab FROM line INTO line COMPARING col2.
Das habe ich so getestet:
READ TABLE it_z91 FROM wa_z9o INTO wa_z9o COMPARING arbpl.
Alles die gleiche Struktur, col2 dürfte hier doch auch col5 oder 6 sein (da liegt etwa arbpl)?
Allerdings habe ich zu diesem Zeitpunkt wie oben geschildert nur einen Wert in der gesamten Workarea wa_z9o, nämlich in wa_z9o-arbpl, alle anderen Felder sind leer und somit ist natürlich kein Schlüssel befüllt.
Sy-Subrc steht Satz für Satz auf 4
, auch wenn die Übereinstimmung gegeben ist.Geht es halt so nicht oder ist noch etwas falsch?
Loop in Loop (so läuft's jetzt halt) ist hier aus Performancegründen kein Problem (wenig Daten, ich wollte das nur prinzipiell testen).
Gruss aus dem verschneiten Süden
Gino
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Probier mal
Wenn Du das beschleunigen willst (und die Tabelle von Typ STANDARD ist) kannst Du <itab> auch vorher sortieren und binär suchen.
Gruss,
Haubi
Code: Alles auswählen.
READ TABLE itab INTO wa WITH KEY feld = wert.Code: Alles auswählen.
SORT itab BY feld ASCENDING.
...
READ TABLE itab INTO wa WITH KEY feld = wert
BINARY SEARCH.
Haubi
Hallo Haubi,
vielen Dank für die nette Unterstützung!
Allerdings hatte ich das auch in meinem Testrepertoire...
Ergebnis: Sy-Subrc = 4
Allerdings ist "Feld" bei mir ein Feld, das an 6.ter Stelle (von links nach rechts) steht,
hm da ich nur dieses zur Verfügung habe liege ich doch deshalb falsch, weil ja der Key eigentlich nicht befüllt ist.
Oder liege ich mit dieser Annahme daneben?
Gruss
Gino
vielen Dank für die nette Unterstützung!
Allerdings hatte ich das auch in meinem Testrepertoire...
Ergebnis: Sy-Subrc = 4
Allerdings ist "Feld" bei mir ein Feld, das an 6.ter Stelle (von links nach rechts) steht,
hm da ich nur dieses zur Verfügung habe liege ich doch deshalb falsch, weil ja der Key eigentlich nicht befüllt ist.
Oder liege ich mit dieser Annahme daneben?
Gruss
Gino
Unter einem leeren Sack keucht's sich oft schwerer als unter einem vollen...
Moinsen.
Der READ TABLE beachtet den Schlüssel nur, wenn Du WITH TABLE KEY angibst. Der Zusatz WITH KEY funzt auf jedem Feld, egal ob Schlüssel oder nicht. Auch die Feldreihenfolge ist egal.
Wenn Du aus dem READ TABLE...WITH KEY einen SY-SUBRC = 4 bekommst heisst das schlicht, dass der gesuchte Wert nicht vorhanden ist.
In Deinem Beispiel ziehst Du die Suchbedingung aus der Workarea (Zusatz FROM <wa>). Bei einer Tabelle mit Schlüssel müßte SAP IMHO die Keyfelder beachten und dann geht der READ TABLE natürlich ins Leere.
Gruss,
Haubi
Der READ TABLE beachtet den Schlüssel nur, wenn Du WITH TABLE KEY angibst. Der Zusatz WITH KEY funzt auf jedem Feld, egal ob Schlüssel oder nicht. Auch die Feldreihenfolge ist egal.
Wenn Du aus dem READ TABLE...WITH KEY einen SY-SUBRC = 4 bekommst heisst das schlicht, dass der gesuchte Wert nicht vorhanden ist.
In Deinem Beispiel ziehst Du die Suchbedingung aus der Workarea (Zusatz FROM <wa>). Bei einer Tabelle mit Schlüssel müßte SAP IMHO die Keyfelder beachten und dann geht der READ TABLE natürlich ins Leere.
Gruss,
Haubi
Hallo,
Du kannst drei sy-subrc's bekommen:
0 bedeutet: Der Schlüssel ist in Table 1 und 2 vorhanden und die restlichen Daten sind identisch.
2 bedeutet: Der Schlüssel ist in Table 1 und 2 vorhanden, die restlichen Daten weisen Unterschiede auf.
4 bedeutet: Der Schlüssel ist lediglich in Table 1 vorhanden.
Achtung:
Bei Deltavergleichen zweier Tables werden dann aber auch nur die Sätze verglichen, die es bereits in Table 1 gibt. Wenn Table 2 einen aktuelleren Datenbestand hat, werden die jüngeren Daten nicht abgeglichen ...
Gruß von der Weser
(auch hier liegt Schnee)
Nemesis
Du kannst drei sy-subrc's bekommen:
0 bedeutet: Der Schlüssel ist in Table 1 und 2 vorhanden und die restlichen Daten sind identisch.
2 bedeutet: Der Schlüssel ist in Table 1 und 2 vorhanden, die restlichen Daten weisen Unterschiede auf.
4 bedeutet: Der Schlüssel ist lediglich in Table 1 vorhanden.
Achtung:
Bei Deltavergleichen zweier Tables werden dann aber auch nur die Sätze verglichen, die es bereits in Table 1 gibt. Wenn Table 2 einen aktuelleren Datenbestand hat, werden die jüngeren Daten nicht abgeglichen ...
Gruß von der Weser
(auch hier liegt Schnee)
Nemesis
also, jetzt habe ich mir mal die SAP-Hilfe angesehen:
Der 'READ TABLE itab FROM wa' macht nur dann Sinn, wenn die Tabelle von Typ SORTED oder HASHED ist oder aber die interessanten Spalten am Anfang der STANDARD TABLE stehen und der Zusatz COMPARING benutzt wird. Wird COMPARING bei einer STANDARD TABLE weggelassen, gilt die gesamte Zeile als Schlüssel!!!
Der, von Dir gewünschte, READ müsste wahrscheinlich folgende Form benutzen:
Das hat aber Haubi auch schon geschrieben.
Der 'READ TABLE itab FROM wa' macht nur dann Sinn, wenn die Tabelle von Typ SORTED oder HASHED ist oder aber die interessanten Spalten am Anfang der STANDARD TABLE stehen und der Zusatz COMPARING benutzt wird. Wird COMPARING bei einer STANDARD TABLE weggelassen, gilt die gesamte Zeile als Schlüssel!!!
Der, von Dir gewünschte, READ müsste wahrscheinlich folgende Form benutzen:
Code: Alles auswählen.
READ TABLE itab2 WITH KEY arbpl = >itab1-wert<.
Gruß
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Ereglam
May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Hallo miteinander,
vielen herzlichen Dank für die nette Hilfe!
Ich glaube, dass Haubi und Erreglam richtig liegen mit der Vermutung, dass ich das in der Form einsetzen muss:
READ TABLE itab2 WITH KEY arbpl = >wa1-wert<.
Das werde ich gleich am Montag so versuchen.
Irritiert war ich durch den Zusatz WITH KEY, das habe ich so interpriert, dass die Itab schon bei der Deklaration explizit mit einem KEY versehen sein muss.
Schönes Wochenende
Gino
vielen herzlichen Dank für die nette Hilfe!
Ich glaube, dass Haubi und Erreglam richtig liegen mit der Vermutung, dass ich das in der Form einsetzen muss:
READ TABLE itab2 WITH KEY arbpl = >wa1-wert<.
Das werde ich gleich am Montag so versuchen.
Irritiert war ich durch den Zusatz WITH KEY, das habe ich so interpriert, dass die Itab schon bei der Deklaration explizit mit einem KEY versehen sein muss.
Schönes Wochenende
Gino
Unter einem leeren Sack keucht's sich oft schwerer als unter einem vollen...
Seite 1 von 1
Vergleichbare Themen
11
Antw.
Antw.
2096
Views
Views
Zeilen in 2 durch Schlüssel verbundenen Tabellen einfügen
von patlau » 15.10.2013 09:05 • Verfasst in ABAP® für Anfänger
von patlau » 15.10.2013 09:05 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
2811
Views
Views
Schlüssel > 120, generischer Schlüssel vergrößern
von zer0 » 27.01.2014 09:20 • Verfasst in ABAP® Core
von zer0 » 27.01.2014 09:20 • Verfasst in ABAP® Core
3
Antw.
Antw.
2204
Views
Views
Inhaltübergabe bei internen Tabellen
von castadiva » 22.10.2007 12:47 • Verfasst in ABAP® für Anfänger
von castadiva » 22.10.2007 12:47 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
3988
Views
Views
5
Antw.
Antw.
2875
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.