Auffrischen einer internen Tabelle aus ALV-Liste
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
Hallo, ich benutze den FuBa REUSE_ALV_GRID_DISPLAY u. a. mit dem Exportparameter I_CALLBACK_USER_COMMAND.
In der FORM USER_COMMAND sieht das abgekürzt so aus:
Ich habe auf der ALV-Liste einen REFRESH-Button eingefügt, der bei Klick die ALV-Liste anhand einer — sehr großen — internen Tabelle (IT) neu aufbaut. Die IT wird in der FORM daten_holen vorher per JOIN über 5 größere Tabellen langwierig geladen. Der Nutzer nimmt nun parallel Änderungen an einem/mehreren Datensätzen vor und möchte die Änderungen anschließend nach dem REFRESH ganz fix im ALV sehen. So weit, so gut. Gibt es irgendeine Möglichkeit, dass die IT nicht bei jedem Refresh neu von der DB geladen werden muss über JOIN, sondern inkl. der Änderungen sehr zeitnah im ALV angezeigt wird? Der Nutzer will also nicht 5 min warten, bis die Datenbankänderungen im ALV erscheinen, sondern z. B. nur 5 s ...
Vielen Dank!
sapdepp
In der FORM USER_COMMAND sieht das abgekürzt so aus:
Code: Alles auswählen.
FORM USER_COMMAND USING i_ucomm LIKE sy-ucomm
i_selfield TYPE slis_selfield.
CASE I_UCOMM.
when 'REFRESH'.
PERFORM daten_holen.
i_selfield-refresh = 'X'.
i_selfield-col_stable = 'X'.
i_selfield-row_stable = 'X'.
Vielen Dank!
sapdepp
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von jensschladitz (Specialist / 417 / 0 /
56
)
»
Sali,
nimmt der User Änderungen an der internen Tabelle vor oder sollen Änderungen an den DB Daten sofort erfolgen - das ist zum einen entscheidend. Und zum anderen - du brauchst doch nur zu vermerken in der IT welche Datensätze der User geändert / bearbeitet hat und dann exakt zu diesen Sätzen die Daten nachlesen - denn ich glaube kaum, dass der User Tausende Sätze gleichzeitig bearbeiten wird / kann. Ausserdem ist zu prüfen ob du im Vorfeld bei der Selektion der Daten nicht vom User verlangen kannst, dass die Datenmenge eingeschränkt wird - denn wie gesagt - wer bearbeitet zig Hundert oder Tausend Sätze gleichzeitig !
Gruss Jens
nimmt der User Änderungen an der internen Tabelle vor oder sollen Änderungen an den DB Daten sofort erfolgen - das ist zum einen entscheidend. Und zum anderen - du brauchst doch nur zu vermerken in der IT welche Datensätze der User geändert / bearbeitet hat und dann exakt zu diesen Sätzen die Daten nachlesen - denn ich glaube kaum, dass der User Tausende Sätze gleichzeitig bearbeiten wird / kann. Ausserdem ist zu prüfen ob du im Vorfeld bei der Selektion der Daten nicht vom User verlangen kannst, dass die Datenmenge eingeschränkt wird - denn wie gesagt - wer bearbeitet zig Hundert oder Tausend Sätze gleichzeitig !
Gruss Jens
thanks Jens
Beitrag
von a-dead-trousers (Top Expert / 4356 / 219 /
1169
)
»
hi!
Kommt darauf an, wie die Daten auf der DB abgelegt werden.
Werden die Daten vom User innerhalb derselben Transaktion angelegt?
Dann musst du nur die Daten die in der DB landen auch in die IT einfügen.
Wenn die Daten woanders eingegeben werden, solltest du prüfen, ob nicht z.B. die Daten auch Erstelldatum/-zeit enthalten.
Dann würde ich einen Index auf diese Informationen anlegen. (Das geht auch bei Standardtabelle ohne Standardänderung)
Nach dem ersten Lesen der Daten, ermitteln welche die jüngsten sind (die mit dem höchsten Datum)
Dann einen Timer (CL_GUI_TIMER) initialisieren, der die Daten z.B. alle 10 - 20 sek. aktualisert.
Das Lesen der Daten über diesen Schritt muss dann eben über das Erstelldatum/-zeit erfolgen.
Die Daten müssen NACH dem ursprünglichen Erstelldatum/-zeit liegen.
So werden nur die neuesten Datensätze gelesen.
(Natürlich danach wieder das jüngste Erstelldatum/-zeit ermitteln)
lg ADT
Kommt darauf an, wie die Daten auf der DB abgelegt werden.
Werden die Daten vom User innerhalb derselben Transaktion angelegt?
Dann musst du nur die Daten die in der DB landen auch in die IT einfügen.
Wenn die Daten woanders eingegeben werden, solltest du prüfen, ob nicht z.B. die Daten auch Erstelldatum/-zeit enthalten.
Dann würde ich einen Index auf diese Informationen anlegen. (Das geht auch bei Standardtabelle ohne Standardänderung)
Nach dem ersten Lesen der Daten, ermitteln welche die jüngsten sind (die mit dem höchsten Datum)
Dann einen Timer (CL_GUI_TIMER) initialisieren, der die Daten z.B. alle 10 - 20 sek. aktualisert.
Das Lesen der Daten über diesen Schritt muss dann eben über das Erstelldatum/-zeit erfolgen.
Die Daten müssen NACH dem ursprünglichen Erstelldatum/-zeit liegen.
So werden nur die neuesten Datensätze gelesen.
(Natürlich danach wieder das jüngste Erstelldatum/-zeit ermitteln)
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
Der User muss doch auch schon 5 Minuten warten, bis er das erstmal den ALV angezeigt bekommt. Demnach ist die Datenbeschaffung ansich inperformant. Kann man diese nicht weiter optimieren?sapdepp hat geschrieben:Der Nutzer will also nicht 5 min warten, bis die Datenbankänderungen im ALV erscheinen, sondern z. B. nur 5 s ...
Das akutalisieren des ALV-Grids ansich wird immer gleich lange dauern, da immer alle Daten (ganze IT) an das Frontend übertragen werden müssen und nicht nur die geänderten Sätze (Summen, Filterungen etc. müssen ebenfalls aktualisiert werden).
Gruß Hendrik
Hallo, Jens, hallo, ADT,
es ist so, dass Änderungen direkt in die DB geschrieben werden. Das passiert vom Nutzer direkt über Doppelklick auf eine ALV-Zeile mit Absprung in eine andere Pflegetransaktion, kann aber häufig auch aus einem parallelen Modus erfolgen. Weiterhin werden die Daten völlig unabhängig von "meinem" Problem auch von anderen Nutzern auf DB-Ebene geändert oder mit Batch-Input direkt in die DB-Tabelle geschrieben. Es kann also sein, dass durchaus in wenigen Sekunden 100 Datensätze geändert werden. Ich möchte, dass nicht nur die Änderungen meines Programms refresht werden, sondern auch gleich mit die Änderungen, die durch andere Nutzer erfolgten ... Die größte Tabelle des Joins enthält insg. über 33 Mio. Einträge, und selbst bei Indexabgriff über Schlüsselfelder und Datum benötigt das Refresh eine Weile ... Optional gäbe es die Möglichkeit, nur den per Doppelklick angefassten Datensatz neu einzulesen mit euren Vorschlägen, ideal wären aber alle Änderungen innerhalb der Zeitspanne. Ich müsste quasi jede der 5 Tabellen auf Änderungszeitstempel überprüfen und anhand dieser die betroffenen Datensätze refreshen ...
VG
sapdepp
es ist so, dass Änderungen direkt in die DB geschrieben werden. Das passiert vom Nutzer direkt über Doppelklick auf eine ALV-Zeile mit Absprung in eine andere Pflegetransaktion, kann aber häufig auch aus einem parallelen Modus erfolgen. Weiterhin werden die Daten völlig unabhängig von "meinem" Problem auch von anderen Nutzern auf DB-Ebene geändert oder mit Batch-Input direkt in die DB-Tabelle geschrieben. Es kann also sein, dass durchaus in wenigen Sekunden 100 Datensätze geändert werden. Ich möchte, dass nicht nur die Änderungen meines Programms refresht werden, sondern auch gleich mit die Änderungen, die durch andere Nutzer erfolgten ... Die größte Tabelle des Joins enthält insg. über 33 Mio. Einträge, und selbst bei Indexabgriff über Schlüsselfelder und Datum benötigt das Refresh eine Weile ... Optional gäbe es die Möglichkeit, nur den per Doppelklick angefassten Datensatz neu einzulesen mit euren Vorschlägen, ideal wären aber alle Änderungen innerhalb der Zeitspanne. Ich müsste quasi jede der 5 Tabellen auf Änderungszeitstempel überprüfen und anhand dieser die betroffenen Datensätze refreshen ...
VG
sapdepp
Beitrag
von jensschladitz (Specialist / 417 / 0 /
56
)
»
Sali,
also da hat es meiner Ansaicht schon einmal ein paar Dinge die nicht korrekt sind - gleichzeitiges Ändern der DB von verschiedenen Stellen - was ist mit dem Sperrmechanismus wird der bei dir / euch völlig ausgeschaltet ?
33 Mio Sätze - also da ist schon mal die Frage - wieso wird nichts archiviert und dann solltest du auf jeden Fall deine SO (Select options ) für dein Programm so gestalten, dass du nur wirklich benötigte Sätze von der DB holst und sobald der User per DK den Satz ändern will - diesen sperren und das Ganze so lange sperren bis du explizit einen DB Update per Save oder so startest. Alles andere ist M...
Du musst auch nur die Daten refreshen, die der User gerade in seiner Liste hat - entsprechend seiner SO - daher ist auch hier die Einschränkung ganz wichtig und dann können durch andere Applikationen andere Sätze geändert werden - das interessiert ja dann gerade den User nicht - er hat ja seinen Arbeitsvorrat dr ihn interessiert !
Gruss Jens
also da hat es meiner Ansaicht schon einmal ein paar Dinge die nicht korrekt sind - gleichzeitiges Ändern der DB von verschiedenen Stellen - was ist mit dem Sperrmechanismus wird der bei dir / euch völlig ausgeschaltet ?
33 Mio Sätze - also da ist schon mal die Frage - wieso wird nichts archiviert und dann solltest du auf jeden Fall deine SO (Select options ) für dein Programm so gestalten, dass du nur wirklich benötigte Sätze von der DB holst und sobald der User per DK den Satz ändern will - diesen sperren und das Ganze so lange sperren bis du explizit einen DB Update per Save oder so startest. Alles andere ist M...
Du musst auch nur die Daten refreshen, die der User gerade in seiner Liste hat - entsprechend seiner SO - daher ist auch hier die Einschränkung ganz wichtig und dann können durch andere Applikationen andere Sätze geändert werden - das interessiert ja dann gerade den User nicht - er hat ja seinen Arbeitsvorrat dr ihn interessiert !
Gruss Jens
thanks Jens
Hallo, Jens,
natürlich verwenden wir das Sperrkonzept, und dass bei uns keine Archivierung stattfindet, hat organisatorische Gründe.
Die SO ist schon so gestaltet, dass nur die relevanten Dinge gelesen werden von der DB, aber auch das dauert schon 5 min.
Ich werde das jetzt auch so machen, dass ich nur die per SO erhaltenen Daten betrachte und diese ggf. refreshe über FOR ALL ENTRIES oder per READ. Mal gucken, was sich besser macht.
VD und VG
sapdepp
natürlich verwenden wir das Sperrkonzept, und dass bei uns keine Archivierung stattfindet, hat organisatorische Gründe.
Die SO ist schon so gestaltet, dass nur die relevanten Dinge gelesen werden von der DB, aber auch das dauert schon 5 min.
Ich werde das jetzt auch so machen, dass ich nur die per SO erhaltenen Daten betrachte und diese ggf. refreshe über FOR ALL ENTRIES oder per READ. Mal gucken, was sich besser macht.
VD und VG
sapdepp
Beitrag
von jensschladitz (Specialist / 417 / 0 /
56
)
»
Sali,
nun dann schau aber bei deinen DB Tabellen nach - welche Indizes benutzt werden für deine Datenermittlung und bei Bedarf bau dir noch ein paar dazu. Wobei ich glaube wenn du die Tabellen per Join verbindest hebelt man die Indizes etwas aus - daher prüfe ob "geschachtelte" selects dann doch nicht besser sind oder nutze die Itab und erweitere diese nach und nach um die fehlenden Daten. Auf jeden Fall denke ich hast du Potential zum optimieren !
Gruss Jens
nun dann schau aber bei deinen DB Tabellen nach - welche Indizes benutzt werden für deine Datenermittlung und bei Bedarf bau dir noch ein paar dazu. Wobei ich glaube wenn du die Tabellen per Join verbindest hebelt man die Indizes etwas aus - daher prüfe ob "geschachtelte" selects dann doch nicht besser sind oder nutze die Itab und erweitere diese nach und nach um die fehlenden Daten. Auf jeden Fall denke ich hast du Potential zum optimieren !
Gruss Jens
thanks Jens
Seite 1 von 1
Vergleichbare Themen
9
Antw.
Antw.
7730
Views
Views
Problem mit Zeilen einer internen Liste
von ostpower » 22.04.2010 16:49 • Verfasst in ABAP® für Anfänger
von ostpower » 22.04.2010 16:49 • Verfasst in ABAP® für Anfänger
4
Antw.
Antw.
1669
Views
Views
Probleme bei Ausgabe einer internen Liste auf Präsentationsserver
von Doobie » 04.07.2024 12:10 • Verfasst in ABAP® für Anfänger
von Doobie » 04.07.2024 12:10 • Verfasst in ABAP® für Anfänger
4
Antw.
Antw.
4453
Views
Views
Aus einer Tabelle Daten einer internen Tabelle filtern - Interne Tabelle ist eine Tabelle ohne Kopfzeile
von Sonne1234 » 09.12.2019 08:29 • Verfasst in ABAP® für Anfänger
von Sonne1234 » 09.12.2019 08:29 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
5460
Views
Views
Inhalt einer internen Tabelle in eine transparente Tabelle?
von Gast » 19.10.2004 14:23 • Verfasst in ABAP® Core
von Gast » 19.10.2004 14:23 • Verfasst in ABAP® Core
2
Antw.
Antw.
3640
Views
Views
Daten aus internen Tabelle in Tabelle speichern
von Stahle71 » 03.06.2015 11:03 • Verfasst in ABAP® für Anfänger
von Stahle71 » 03.06.2015 11:03 • Verfasst in ABAP® für Anfänger
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.