auf Tabellen in Strukturen zugreifen
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
Hallo zusammen,
ich habe eine Tabelle Auslöser, die 6 Untertabellen (Vertrag, Aufgaben,Tarif....hat.
wie kann ich in dieser Tabelle Feldern der Untertabellen Werte zuweisen ?
z.B soll in der ersten Zeile, in der Tabelle Vertrag das Feld betrag geändert werden und zwar nur der Zeile derVertragstabelle, in der in der Spalte "Nummer" der wert der var1 steht und der Spalte "tarif" der wert der var2 steht.
irgendwas so in der Richtung ?
auslöser[ 1 ]-tarif[ nummer = var1 tarif = var2 ]-Betrag =
ich habe eine Tabelle Auslöser, die 6 Untertabellen (Vertrag, Aufgaben,Tarif....hat.
wie kann ich in dieser Tabelle Feldern der Untertabellen Werte zuweisen ?
z.B soll in der ersten Zeile, in der Tabelle Vertrag das Feld betrag geändert werden und zwar nur der Zeile derVertragstabelle, in der in der Spalte "Nummer" der wert der var1 steht und der Spalte "tarif" der wert der var2 steht.
irgendwas so in der Richtung ?
auslöser[ 1 ]-tarif[ nummer = var1 tarif = var2 ]-Betrag =
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4412 / 224 /
1184
)
»
In der neuen Sytax genau so wie du das angegeben hast.
In der alten Syntax mit READ TABLE und ASSIGNING oder REFERENCE. Diese Zusätze erstellen einen Zeiger auf die jeweilige Zeile und keine Kopie wie bei INTO.
Wenn man mehere Zeilen hintereinander ändern möchte kann man auch bei LOOP AT diese Zusätze verwenden.
Bezugnehmend auf dein Beispiel:
Das Ganze mag zwar vielleicht etwas kompliziert aussehen, bringt aber meines Erachtens im Vergleich zur "neuen" Variante das Fehlerhandling deutlicher zu Geltung. In der neuen Sytax müsste man, wenn man sich nicht 100% sicher ist, dass z.B. die Tabelle Tarif einen Eintrag mit dem gesuchten Schüssel hat, einen TRY ... CATCH herumbauen oder mit line_exists erst wieder zweimal auf die Daten zugreifen um Fehler zu vermeiden.
lg ADT
In der alten Syntax mit READ TABLE und ASSIGNING oder REFERENCE. Diese Zusätze erstellen einen Zeiger auf die jeweilige Zeile und keine Kopie wie bei INTO.
Wenn man mehere Zeilen hintereinander ändern möchte kann man auch bei LOOP AT diese Zusätze verwenden.
Bezugnehmend auf dein Beispiel:
Code: Alles auswählen.
READ TABLE auslößer INDEX 1 ASSIGNING FIELD-SYMBOL(<auslößer>).
IF sy-subrc EQ 0.
READ TABLE <auslößer>-tarif ASSIGNING FIELD-SYMBOL(<tarif>)
WITH KEY nummer = var1 tarif = var2.
IF sy-subrc EQ 0.
<tarif>-Betrag = ...
ENDIF.
ENDIF.lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Also den alten READ TABLE würde ich überhaupt nicht mehr verwenden, außer ich will zusätzlich zur Tabellenzeile auch den SY-TABIX haben, den er mitliefert. Gleichwohl stimme ich zu, dass die Lösung mit TRY-CATCH hässlich (und bei Nichtvorhandensein der Tabellenzeile auch langsam) ist.
Die Wahrheit liegt daher aus meiner Sicht in der Mitte. Statt des READ TABLE-Befehls kann man eine weitgehend äquivalente Syntax des ASSIGN-Befehls verwenden, die aber die Verwendung der neuen Syntax trotzdem erlaubt.
Hier ein vollständig lauffähiges Beispielprogramm mit genau Deinem Fall, Micha_ela:
Kannste Dir Breakpunkte reinsetzen und Dir das anschauen. So halte ich das für elegant.
Selbstverständlich kann man das - wie adt schon angemerkt hat - auch in LOOPs verwenden.
Die Wahrheit liegt daher aus meiner Sicht in der Mitte. Statt des READ TABLE-Befehls kann man eine weitgehend äquivalente Syntax des ASSIGN-Befehls verwenden, die aber die Verwendung der neuen Syntax trotzdem erlaubt.
Hier ein vollständig lauffähiges Beispielprogramm mit genau Deinem Fall, Micha_ela:
Code: Alles auswählen.
REPORT ZTEST4.
TYPES: BEGIN OF TARIFZEILE,
NUMMER TYPE NUMC4,
TARIF TYPE NUMC2,
BETRAG(6) TYPE P DECIMALS 2,
END OF TARIFZEILE,
T_TARIF TYPE HASHED TABLE OF TARIFZEILE WITH UNIQUE KEY NUMMER TARIF, " schön brav Index auf die Spalten, nach denen wir nachher suchen wollen
BEGIN OF AUSLOESERZEILE,
TARIF TYPE T_TARIF,
END OF AUSLOESERZEILE,
T_AUSLOESER TYPE STANDARD TABLE OF AUSLOESERZEILE WITH EMPTY KEY.
DATA: AUSLOESER TYPE T_AUSLOESER.
START-OF-SELECTION.
* Tabelle Auslöser mit einer Zeile vorfüllen, deren Untertabelle auch eine Zeile hat, die aber noch keinen Betrag enthält
AUSLOESER = VALUE #( ( TARIF = VALUE #( ( NUMMER = '0001' TARIF = '01' ) ) ) ).
* Der Zeile dieser Untertabelle den Betrag 15 geben
ASSIGN AUSLOESER[ 1 ]-TARIF[ NUMMER = '0001' TARIF = '01' ]-BETRAG TO FIELD-SYMBOL(<BETRAG>).
IF SY-SUBRC <> 0.
" hier irgendwas machen, falls entweder AUSLOESER überhaupt keine erste Zeile hat oder deren
" Untertabelle keine Zeile mit NUMMER = '0001' und TARIF = '01' hat
ELSE.
<BETRAG> = 15.
ENDIF.Selbstverständlich kann man das - wie adt schon angemerkt hat - auch in LOOPs verwenden.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
a-dead-trousers
Nein, muss man nicht.a-dead-trousers hat geschrieben: ↑07.06.2023 18:08In der neuen Sytax müsste man, wenn man sich nicht 100% sicher ist, dass z.B. die Tabelle Tarif einen Eintrag mit dem gesuchten Schüssel hat, einen TRY ... CATCH herumbauen oder mit line_exists erst wieder zweimal auf die Daten zugreifen um Fehler zu vermeiden.
Code: Alles auswählen.
DATA(eintrag) = VALUE #( ausloeser[ feld = abc ] optional ).
Ja, es wird zweimal gelesen. Allerdings sind die neuen Befehle sehr gut optimiert, so dass nicht wirklich zweimal gelesen wird. Ich meine gelesen zu haben, dass eine interne Pufferung eingebaut ist, um genau so einen Fall abzudecken.
Zusätzlich möchte ich mal mit der Mär aufräumen, dass die TRY-CATCHES langsam sind. Ja, sie sind langsamer, als das Abfragen des SUBRC nach dem READ, aber nicht so langsam, als dass man es auf Teufel komm raus vermeiden müsste. Bei Tests, die ich gemacht habe, ist der Try-Catch im Zusammenhang mit Tabellenzugriffen ca. 50% langsamer. Sofern man also Millionen von Datensätzen bearbeitet, sollte man TRY-CATCH vermeiden, aber das ist in den seltensten Fällen so.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
a-dead-trousers
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Diese Variante hatte ich auch im Auge, aber sie bietet keine Reaktionsmöglichkeit auf den Fall, dass die Zeile nicht da ist, sondern man bekommt dann einfach einen initialen Wert. Häufig ist das gut genug, aber in Micha_Elas Beispiel hatte ich schon den Eindruck, dass solch Fall konkret mit abgedeckt werden sollte. Und spätestens wenn der initiale Wert auch ein tatsächlicher Rückgabewert sein könnte, ist anhand dessen auch mit nachgeschaltetem IF nicht mehr erkennbar, ob die Zeile gefunden wurde oder nicht.ewx hat geschrieben: ↑07.06.2023 19:36Nein, muss man nicht.Code: Alles auswählen.
DATA(eintrag) = VALUE #( ausloeser[ feld = abc ] optional ).
Der ASSIGN mit nachfolgender Prüfung auf SY-SUBRC löst all diese Probleme. Dennoch, ganz deutlich: der VALUE...OPTIONAL ist gut, und ich nutze ihn auch viel, da er sehr häufig ausreicht.
Das mag so sein, aber in meinen Augen ist ein LINE_EXISTS und dann ein nachfolgender READ mit genau derselben Suchbedingung ein extrem unbeholfen und anfängerhaft wirkender Programmierstil, als ob der Programmierer halt nicht gewusst hätte, wie er es besser machen kann, als zweimal dasselbe zu suchen. Vermutlich war der SAP klar, dass viele Entwickler nicht gut programmieren können, und deshalb werden sie dann als Unterstützungskrücke diese Pufferung eingebaut haben.ewx hat geschrieben: ↑07.06.2023 19:36zum doppelten READ mit prüfen LINE_EXISTS und dann tatsächlichem READ:
Ja, es wird zweimal gelesen. Allerdings sind die neuen Befehle sehr gut optimiert, so dass nicht wirklich zweimal gelesen wird. Ich meine gelesen zu haben, dass eine interne Pufferung eingebaut ist, um genau so einen Fall abzudecken.
Vor langer Zeit habe ich das mal gemessen. Der Zugriff mit TRY-CATCH ist vor allem dann langsamer, wenn es die gesuchte Zeile tatsächlich nicht gibt. Nach meiner (zugegebenermaßen dunklen) Erinnerung kam ich da auf die siebenfache Laufzeit (d.h. +600%!!) verglichen mit eleganteren Ansätzen. Das hängt damit zusammen, dass ABAP dann extra ein Exceptionobjekt erzeugen muss, und das kostet richtig.ewx hat geschrieben: ↑07.06.2023 19:36Zusätzlich möchte ich mal mit der Mär aufräumen, dass die TRY-CATCHES langsam sind. Ja, sie sind langsamer, als das Abfragen des SUBRC nach dem READ, aber nicht so langsam, als dass man es auf Teufel komm raus vermeiden müsste. Bei Tests, die ich gemacht habe, ist der Try-Catch im Zusammenhang mit Tabellenzugriffen ca. 50% langsamer.
Insofern hängt es von den Umständen ab. Wenn man davon ausgehen kann, dass die Zeile in aller Regel da sein wird und man nur halt im Sonderfall nicht dumpen möchte, mag TRY-CATCH gut genug sein. Wenn allerdings die Zeile häufig nicht existiert, dann ist das performancetechnischer Mist.
So oder so sehe ich aber nicht viel, was an dieser Stelle für TRY-CATCH spricht, weil die Variante mit dem ASSIGN auf der ganzen Linie besser ist, auch hinsichtlich der Lesbarkeit.
auf jeden Fall. Die Try Catch-Variante ist fast immer "hässlich". Sehr viel Code-Noise um einen einzelnen Befehl herum.DeathAndPain hat geschrieben: ↑08.06.2023 15:56So oder so sehe ich aber nicht viel, was an dieser Stelle für TRY-CATCH spricht, weil die Variante mit dem ASSIGN auf der ganzen Linie besser ist, auch hinsichtlich der Lesbarkeit.
Trotzdem habe ich noch mal einen Test gemacht:
10000 Einträge in interner Tabelle Struktur VBAP.
jeweils 1000 x ein READ, der auf jeden Fall fehlschlägt.
das sind die Ergebnisse:
Code: Alles auswählen.
1000x READ TABLE 280.776
1000x TRY-CATCH w/o INTO 287.318
1000x TRY-CATCH with INTO 575.574
1000x VALUE OPTIONAL 829.144Was ich nicht gedacht hätte ist, dass VALUE ... OPTION noch mal deutlich langsamer ist.
Zur Sicherheit noch das Coding; vielleicht habe ich etwas übersehen?:
Code: Alles auswählen.
DATA items TYPE STANDARD TABLE OF vbap WITH DEFAULT KEY.
DATA(vbeln) = CONV numc10( 0 ).
DO 1000 TIMES.
ADD 1 TO vbeln.
DO 10 TIMES.
APPEND VALUE #( vbeln = vbeln posnr = sy-index matnr = 'ABC' kwmeng = 10 vrkme = 'ST' ) TO items.
ENDDO.
ENDDO.
GET RUN TIME FIELD DATA(start).
DO 1000 TIMES.
READ TABLE items INTO DATA(item) WITH KEY vbeln = CONV #( sy-index ) posnr = 99.
ENDDO.
GET RUN TIME FIELD DATA(stopp).
DATA(diff) = stopp - start.
WRITE : / '1000x READ TABLE', AT 50 diff.
GET RUN TIME FIELD start.
DO 1000 TIMES.
TRY.
DATA(item2) = items[ vbeln = CONV #( sy-index ) posnr = 99 ].
CATCH cx_sy_itab_line_not_found.
ENDTRY.
ENDDO.
GET RUN TIME FIELD stopp.
diff = stopp - start.
WRITE : / '1000x TRY-CATCH w/o INTO', AT 50 diff.
DO 1000 TIMES.
TRY.
DATA(item3) = items[ vbeln = CONV #( sy-index ) posnr = 99 ].
CATCH cx_sy_itab_line_not_found INTO DATA(error).
ENDTRY.
ENDDO.
GET RUN TIME FIELD stopp.
diff = stopp - start.
WRITE : / '1000x TRY-CATCH with INTO', AT 50 diff.
DO 1000 TIMES.
DATA(item4) = VALUE #( items[ vbeln = CONV #( sy-index ) posnr = 99 ] OPTIONAL ).
ENDDO.
GET RUN TIME FIELD stopp.
diff = stopp - start.
WRITE : / '1000x VALUE OPTIONAL', AT 50 diff.
Beitrag
von a-dead-trousers (Top Expert / 4412 / 224 /
1184
)
»
Nur kleinere Anmerkungen:
Das CONV #( ) erhöht die Laufzeit ebenfalls (unnötig) aber da es in allen Vergleichen verwendet wird, kann man das wieder verschmerzen.
Die Variante mit OPTIONAL dürfte deswegen langsamer sein, weil da ein Datenobjekt mit 3.480 Bytes (VBAP) im Speicher tatsächlich "kopiert" wird. In allen anderen Varianten wird zwar eine Datenobjekt erzeugt aber nie Daten zugewiesen, weil die Verarbeitung in Ermangelung einer passenden Tabellenzeile abbricht.
Den Unterschied bei TRY ... CATCH mit INTO finde ich am Interessantesten. Das bedeutet, dass die SAP hier Optimierungen eingebaut hat, wenn die Informationen aus der Exception (8 Byte Zeiger auf den Heap usw.) nicht benötigt werden. Nachdem ich mir in den letzten Jahren angewöhnt habe, für ein schnelleres Debugging bei allen TRY ... CATCH immer auch ein INTO anzugeben, werde ich das wohl doch überdenken müssen.
Das CONV #( ) erhöht die Laufzeit ebenfalls (unnötig) aber da es in allen Vergleichen verwendet wird, kann man das wieder verschmerzen.
Die Variante mit OPTIONAL dürfte deswegen langsamer sein, weil da ein Datenobjekt mit 3.480 Bytes (VBAP) im Speicher tatsächlich "kopiert" wird. In allen anderen Varianten wird zwar eine Datenobjekt erzeugt aber nie Daten zugewiesen, weil die Verarbeitung in Ermangelung einer passenden Tabellenzeile abbricht.
Den Unterschied bei TRY ... CATCH mit INTO finde ich am Interessantesten. Das bedeutet, dass die SAP hier Optimierungen eingebaut hat, wenn die Informationen aus der Exception (8 Byte Zeiger auf den Heap usw.) nicht benötigt werden. Nachdem ich mir in den letzten Jahren angewöhnt habe, für ein schnelleres Debugging bei allen TRY ... CATCH immer auch ein INTO anzugeben, werde ich das wohl doch überdenken müssen.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ewx
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Wenn der initiale Wert gefunden werden könnte, gibt es sehr häufig trotzdem Werte, von denen man weiß, dass sie nicht vorkommen können. In solchen Fällen definiere ich eine Konstante mit einem Wert der nicht vorkommen kann und verwende statt des OPTIONAL Zusatzes den DEFAULT Zusatz und vergleiche danach ob die Konstante getroffen wurde oder nicht.DeathAndPain hat geschrieben: ↑08.06.2023 15:56Und spätestens wenn der initiale Wert auch ein tatsächlicher Rückgabewert sein könnte, ist anhand dessen auch mit nachgeschaltetem IF nicht mehr erkennbar, ob die Zeile gefunden wurde oder nicht.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
In der Tat. Da fehlen so einige GET RUN TIME FIELD start. Da misst Du also bei jedem Durchgang die Laufzeiten der vorherigen Durchgänge mit.
Im übrigen: Gerade wenn ABAP solche Tücken eingebaut hat wie Pufferung vergangener Suchen, ist es möglicherweise nicht sachgerecht, alle drei Suchvarianten nacheinander auszuführen, weil womöglich eine später kommende vom Ergebnis einer früher kommenden profitieren könnte.
Dass da auch DEFAULT geht, hatte ich gar nicht auf dem Schirm. Vielen Dank; wieder was gelernt.black_adept hat geschrieben:Wenn der initiale Wert gefunden werden könnte, gibt es sehr häufig trotzdem Werte, von denen man weiß, dass sie nicht vorkommen können. In solchen Fällen definiere ich eine Konstante mit einem Wert der nicht vorkommen kann und verwende statt des OPTIONAL Zusatzes den DEFAULT Zusatz und vergleiche danach ob die Konstante getroffen wurde oder nicht.
boah, wie peinlich... 😬DeathAndPain hat geschrieben: ↑09.06.2023 15:53In der Tat. Da fehlen so einige GET RUN TIME FIELD start. Da misst Du also bei jedem Durchgang die Laufzeiten der vorherigen Durchgänge mit.
Jetzt sieht es anders aus, aber kann das richtig sein?
Code: Alles auswählen.
1000x READ TABLE 273.292
1000x TRY-CATCH w/o INTO 279.639
1000x TRY-CATCH with INTO 274.695
1000x VALUE OPTIONAL 266.569
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Wenn ich Dein Programm bei mir ausführe, sieht es so aus:
1000x READ TABLE 368.822
1000x TRY-CATCH w/o INTO 378.446
1000x TRY-CATCH with INTO 354.862
1000x VALUE OPTIONAL 346.166
Minimal müsste man unterschiedliche Zeilen suchen, wobei es selbst dann sein kann, dass er Teile der Tabelle vorlädt und damit andere Suchzugriffe optimiert (aber dann könnte man argumentieren, dass das auch im produktiven Code so sein wird und die Testergebnisse daher dennoch repräsentativ sind). Denkbar auch, dass der CATCH das exakt in der benötigten Form bereits bestehende Exception-Objekt irgendwie "recyclet" und damit nicht neu erzeugen muss.
Zudem suchst Du in einer Standardtabelle, was hoffentlich nicht praxisrelevant ist. Bei Deinen 10 Einträgen wird das performancetechnisch kaum eine Rolle spielen, aber ich denke, man sollte solch Test so praxisnah wie möglich gestalten. Die Suchzeit selbst misst Du ja immer mit.
1000x READ TABLE 368.822
1000x TRY-CATCH w/o INTO 378.446
1000x TRY-CATCH with INTO 354.862
1000x VALUE OPTIONAL 346.166
Na ja, Du machst jeweils 1000x exakt den gleichen Zugriff. Wenn da wirklich irgendwelche Pufferungsalgorithmen im Compiler verbaut sind, dann kann das ganze Ergebnis locker für die Tonne sein.
Minimal müsste man unterschiedliche Zeilen suchen, wobei es selbst dann sein kann, dass er Teile der Tabelle vorlädt und damit andere Suchzugriffe optimiert (aber dann könnte man argumentieren, dass das auch im produktiven Code so sein wird und die Testergebnisse daher dennoch repräsentativ sind). Denkbar auch, dass der CATCH das exakt in der benötigten Form bereits bestehende Exception-Objekt irgendwie "recyclet" und damit nicht neu erzeugen muss.
Zudem suchst Du in einer Standardtabelle, was hoffentlich nicht praxisrelevant ist. Bei Deinen 10 Einträgen wird das performancetechnisch kaum eine Rolle spielen, aber ich denke, man sollte solch Test so praxisnah wie möglich gestalten. Die Suchzeit selbst misst Du ja immer mit.
Die Tabelle hat 10.000 Einträge.
Der Zugriff erfolgt immer mit einer neuen VBELN.
Klar könnten bei ähnlichen Pufferungsmechanismen greifen (sehr wahrscheinlich sogar) aber auch wenn man zwischendurch über ein anderes Feld zugreift, könnte die Pufferung trotzdem greifen.
Zugriffe über Standardtabellen sind sehr praxisrelevant, denn häufig wird die Tabelle zur Anzeige im ALV-Grid genutzt und da funktionieren nur Standardtabellen.
Der Zugriff erfolgt immer mit einer neuen VBELN.
Klar könnten bei ähnlichen Pufferungsmechanismen greifen (sehr wahrscheinlich sogar) aber auch wenn man zwischendurch über ein anderes Feld zugreift, könnte die Pufferung trotzdem greifen.
Zugriffe über Standardtabellen sind sehr praxisrelevant, denn häufig wird die Tabelle zur Anzeige im ALV-Grid genutzt und da funktionieren nur Standardtabellen.
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Ihr habt beide irgendwie recht. Und SAP hat das auch so gesehen und uns die Möglichkeit gegeben Tabellen mit weiteren Schlüsseln zu versehen [https://help.sap.com/doc/abapdocu_752_i ... ondary.htm], so dass es man wie bei Hannah Montana "Best of Both Worlds" bekommt.DeathAndPain hat geschrieben: ↑09.06.2023 17:28Zudem suchst Du in einer Standardtabelle, was hoffentlich nicht praxisrelevant ist.
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Stimmt, da habe ich den Code nicht genau genug gelesen und den geschachtelten LOOP am Anfang nicht gesehen.
Aber bei 10.000 Einträgen halte ich eine Indizierung schon für relevant. Vielleicht sind 98% der Laufzeit sequenzielle Suche in der Tabelle? Bei so einer Tabelle ist ein vernünftiger Index in meinen Augen Pflicht.
Zugriffe über Standardtabellen sind sehr praxisrelevant, denn häufig wird die Tabelle zur Anzeige im ALV-Grid genutzt und da funktionieren nur Standardtabellen.[/quote]
Wie black_adept korrekt anmerkt, ist das kein Grund, ohne Index zu suchen. Wenn es die Option mit dem Sekundärindex nicht gäbe, würde ich tatsächlich sogar die Tabelle trotzdem indiziert führen und dem ALV eine Kopie davon als Standardtabelle übergeben. Nur einem ALV zuliebe mit einer miesen CPU-Performance zu leben, halte ich nicht für einen guten Ansatz. Und so eine ALV-Tabelle hat keine Größenordnung, mit dem man heutige Arbeitsspeicher noch ins Schwitzen bringen können sollte. Man wird ja hoffentlich kein ALV mit Millionen Zeilen anzeigen wollen.
Seite 1 von 1
Vergleichbare Themen
6
Antw.
Antw.
5543
Views
Views
Auf Strukturen untypisierter Tabellen zugreifen
von Timo7 » 18.10.2006 12:56 • Verfasst in ABAP® Core
von Timo7 » 18.10.2006 12:56 • Verfasst in ABAP® Core
1
Antw.
Antw.
2433
Views
Views
7
Antw.
Antw.
3194
Views
Views
dynamische Tabellen in komplexen Strukturen
von mike81503 » 28.07.2006 15:03 • Verfasst in ABAP® Core
von mike81503 » 28.07.2006 15:03 • Verfasst in ABAP® Core
0
Antw.
Antw.
1098
Views
Views
0
Antw.
Antw.
3200
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 6 Stunden von a-dead-trousers 5 / 257
vor 6 Stunden von a-dead-trousers 5 / 257
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 6 Stunden von a-dead-trousers 5 / 257
vor 6 Stunden von a-dead-trousers 5 / 257