Bringen Datenbank-Cursoren irgendwas?
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Hallo zusammen,
im Code eines Kollegen habe ich folgende Methode gefunden:
Frage: Bringt diese Paketierung irgend etwas? Wäre es nicht effizienter, einfach ohne Cursor einen SELECT INTO TABLE zu machen? Der Kollege ist gerade im Urlaub, und außerdem würde ich dazu gerne die Meinung von Dritten hören. Der Code sieht aus, als ob er mit der Paketierung irgendwie Rücksicht auf die Datenbank nehmen wollte, aber ich habe noch nie gehört, dass sowas notwendig wäre oder irgend etwas bringen würde. Demzufolge habe ich auch die Befehle OPEN CURSOR nebst FETCH noch nie benutzt.
Würde gerne wissen, ob es irgendwelche Gründe gibt, das so umständlich zu machen. Vielen Dank!
im Code eines Kollegen habe ich folgende Methode gefunden:
Code: Alles auswählen.
METHOD get_hierarchy.
DATA: lc_cursor TYPE cursor.
OPEN CURSOR lc_cursor FOR
** Hierarchy.
SELECT otype objid sclas sobid rsign relat prozt begda endda aedtm
FROM hrp1001
WHERE relat EQ zcl_data_employee=>gc_relat_002
AND sclas EQ zcl_data_employee=>gc_otype_o
AND plvar EQ me->liv_plvar
AND endda GE me->liv_date
AND otype EQ zcl_data_employee=>gc_otype_o
AND begda LE me->liv_date
AND subty EQ zcl_data_employee=>gc_subty_b002.
DO.
FETCH NEXT CURSOR lc_cursor APPENDING TABLE me->lit_hierarchy PACKAGE SIZE 60000.
IF ( sy-subrc NE 0 ).
EXIT.
ENDIF.
ENDDO.
CLOSE CURSOR lc_cursor.
ENDMETHOD.Würde gerne wissen, ob es irgendwelche Gründe gibt, das so umständlich zu machen. Vielen Dank!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Das macht man wenn es ein Mengenproblem gibt und die Daten
welche selektiert werden sollen nicht in eine interne Tabelle
passen (bzw. nicht genug Speicher zur Verfügung steht).
Ich hab das früher häufig gebraucht, inzwischen haben wir so
viel Speicher daß es nur noch in ganz seltenen Fällen Sinn macht.
welche selektiert werden sollen nicht in eine interne Tabelle
passen (bzw. nicht genug Speicher zur Verfügung steht).
Ich hab das früher häufig gebraucht, inzwischen haben wir so
viel Speicher daß es nur noch in ganz seltenen Fällen Sinn macht.
Daniel: Das ist eine Erklärung für PACKAGE-SIZE aber nicht für die Verwendung von FETCH.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
...und schon gar nicht für den obenstehenden Code, denn da wird ja doch wieder alles der Reihe nach in die interne Tabelle geschaufelt.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Die Methode ist so, wie ich sie wiedergegeben habe, noch kein halbes Jahr alt. Das ganze Programm ist neu.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Der Vorteil, neben dem Umgehen eines evtl. Speicherengpasses, ist außerdem, dass man beim Debuggen "leichter" in den Code reinkommt, weil ein großes Select auf diese Weise nicht auf einmal ausgeführt wird. Natürlich ist da aber eine Packagesize von 60.000 wiederum kontraproduktiv. Vorallem wenn man dann erst wieder alles in eine interne Tabelle reinstopft anstatt es gleich zu verarbeiten und minimieren.
Mittlerweile gibt es den Packagesize Zusatz übrigens auch bei einem normalen Select. Ich würde daher darauf tippen, dass der Kollege noch "von der alten Schule" ist.
Mittlerweile gibt es den Packagesize Zusatz übrigens auch bei einem normalen Select. Ich würde daher darauf tippen, dass der Kollege noch "von der alten Schule" ist.
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 ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
„Das hab ich immer schon so gemacht, das funktioniert, also mache ich das so weiter“ 
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Tatsächlich glaube ich das nicht, denn er programmiert hier konsequentesten OO-Code und hat auch die neuen 7.40-Befehle wie ein Schwamm aufgesaugt (die finden sich reichlich in eben jenem Programm und auch durchaus sinnvoll eingesetzt). Dessen ungeachtet kann es ja sein, dass er in irgendeinem Detail falsch informiert ist. Ich wollte nur sicherstellen, dass nicht vielleicht ich derjenige bin, der hier etwas Wichtiges übersieht bzw. nicht weiß.
Also ihr seid alle meiner Meinung, dass das in dieser Form Unsinn ist und ein gewöhnlicher SELECT INTO TABLE besser wäre? Dann werde ich ihn mal fragen, wenn er wieder da ist.
Sein Code hat in dieser Form auch den Nachteil, dass seine interne (sortierte) Tabelle (die tatsächlich eine Puffertabelle ist, wie der Code schon erahnen lässt) den gleichen Schlüssel haben muss wie die zugehörige Datenbanktabelle, weil ihm sonst vermutlich sein FETCH ... APPENDING dumpen würde (Verletzung des Sortierkriteriums der internen Tabelle durch APPEND). Das ist aber nicht der Schlüssel, mit der er im weiteren Programmverlauf in der Tabelle sucht. Da ich an dem Programm sowieso einen Bug beheben musste, habe ich schon mal einen Sekundärschlüssel mit den richtigen Suchfeldern hinzugefügt. Aber ohne das FETCH bräuchte die Tabelle den Primärschlüssel gar nicht; der bringt ja nix.
@Ralf: Übrigens hat er diese Puffertabelle als Attribut seiner Klasse definiert und liegt damit genau auf Deiner Linie.
Also ihr seid alle meiner Meinung, dass das in dieser Form Unsinn ist und ein gewöhnlicher SELECT INTO TABLE besser wäre? Dann werde ich ihn mal fragen, wenn er wieder da ist.
Sein Code hat in dieser Form auch den Nachteil, dass seine interne (sortierte) Tabelle (die tatsächlich eine Puffertabelle ist, wie der Code schon erahnen lässt) den gleichen Schlüssel haben muss wie die zugehörige Datenbanktabelle, weil ihm sonst vermutlich sein FETCH ... APPENDING dumpen würde (Verletzung des Sortierkriteriums der internen Tabelle durch APPEND). Das ist aber nicht der Schlüssel, mit der er im weiteren Programmverlauf in der Tabelle sucht. Da ich an dem Programm sowieso einen Bug beheben musste, habe ich schon mal einen Sekundärschlüssel mit den richtigen Suchfeldern hinzugefügt. Aber ohne das FETCH bräuchte die Tabelle den Primärschlüssel gar nicht; der bringt ja nix.
@Ralf: Übrigens hat er diese Puffertabelle als Attribut seiner Klasse definiert und liegt damit genau auf Deiner Linie.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Die interessiert uns hier bestimmt alle.DeathAndPain hat geschrieben:Also ihr seid alle meiner Meinung, dass das in dieser Form Unsinn ist und ein gewöhnlicher SELECT INTO TABLE besser wäre? Dann werde ich ihn mal fragen, wenn er wieder da ist.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Und mich würde interessieren, wie seine HN aufgebaut ist.
Ich dachte erst das "gc" wären (g)lobal (c) = gc... Konstanten (zcl_data_employee=>gc_relat_002) aber dann habe ich lc_cursor gesehen und der ist definitiv nicht als Konstante definiert und das me->lit_hierarchy passt da auch nicht rein.
Ich dachte erst das "gc" wären (g)lobal (c) = gc... Konstanten (zcl_data_employee=>gc_relat_002) aber dann habe ich lc_cursor gesehen und der ist definitiv nicht als Konstante definiert und das me->lit_hierarchy passt da auch nicht rein.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Ich denke, das kann ich erklären (auch wenn er sich dabei anscheinend einige Freiheiten genommen hat).
gc: global constant (als Attribute definiert)
lc: local cursor (logisch oder?
)
me->lit_hierarchy: local internal table (wobei man über das "local" hier diskutieren kann, denn sie ist ja nicht innerhalb der Methode definiert. Ich interpretiere das so, dass es sich bei dieser Tabelle um ein privates Attribut der Klasse handelt, also als "klassenlokal" angesehen werden kann.
Obenstehendes ist nur als Erläuterung, nicht als Rechtfertigung gemeint.
gc: global constant (als Attribute definiert)
lc: local cursor (logisch oder?
)me->lit_hierarchy: local internal table (wobei man über das "local" hier diskutieren kann, denn sie ist ja nicht innerhalb der Methode definiert. Ich interpretiere das so, dass es sich bei dieser Tabelle um ein privates Attribut der Klasse handelt, also als "klassenlokal" angesehen werden kann.
Obenstehendes ist nur als Erläuterung, nicht als Rechtfertigung gemeint.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
*heul*DeathAndPain hat geschrieben:gc: global constant (als Attribute definiert)
lc: local cursor (logisch oder?
me->lit_hierarchy: local internal table
Ralf *gibt es noch andere Tabellen in Programmen als interne Tabellen?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Wir sollten hier nun nicht das Ursprungsthema "Cursor" verwässern.Ray Ozzie hat geschrieben:When you’re working in somebody else’s module, though, you’d better use his or her conventions. It’s part of learning to work with others.
Vielleicht gibt es für die Verwendung von FETCH CURSOR noch eine sinnvolle "Ausrede"?!
Vergleichbare Themen
3
Antw.
Antw.
5270
Views
Views
Arbeitsplan konsistent auf die Datenbank bringen.
von f.kemmer » 24.01.2007 10:14 • Verfasst in Material Management & Produktionsplanung
von f.kemmer » 24.01.2007 10:14 • Verfasst in Material Management & Produktionsplanung
3
Antw.
Antw.
1907
Views
Views
15
Antw.
Antw.
11708
Views
Views
3
Antw.
Antw.
485
Views
Views
Sourcecode in Änderung bringen und Transportauftrag erstellen
von Markus69 » 28.05.2022 18:25 • Verfasst in ABAP® Core
von Markus69 » 28.05.2022 18:25 • Verfasst in ABAP® Core
0
Antw.
Antw.
1019
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.