Where-Bedingungen separieren/ interne Tabellen dynamisch?
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
Hallo,
ich muss alle Einträge einer DB-Tabelle behandeln.
(Nennen wir sie mal T1)
Da diese allerdings mehrere Millionen Einträge haben kann lese ich sie Packetweise mithilfe eines DB-Cursor. Die Größe der Packete ist per Eingabeparameter einstellbar.
In einer anderen Tabelle(T2) ist ein Schlüsselfeld gleich einem normalen Feld meiner T1. Allerdings ist T2 absolut unsortierbar.
Deshalb will ich immer die passenden Einträge zu den derzeit bearbeiteten T1-Einträgen aus T2 lesen.
Nun habe ich aus T1 eine Rangestabelle gebaut, diese mithilfe des Fubas "FREE_SELECTIONS_RANGE_2_WHERE" in eine Where bedingung umgewandelt und damit dann selektiert.
Funktioniert alles wunderbar, solange die Lesegröße der T1 150 Einträge nicht übersteigt.(Entsprechen dann auch 150 where-Bedingungen.) Bei mehr Where-Bedingungen kommt eine Fehlermeldung.
Nun zu meinen Fragen:
Ich könnte viele Einträge aus T1 lesen und verarbeiten. Da ich nicht weiß wieviele Einträge der Benutzer einlesen will, müssten die Selektionskriterien für T2 dann dynamisch in 150er Packete separiert werden. Kann ich hierfür dynamisch eine Anzahl von internen Tabellen erstellen?
Ich hoffe mal meine Absichten kamen einigermaßen klar rüber.
Vielen Dank für eure Antworten!
Viele Grüße
ich muss alle Einträge einer DB-Tabelle behandeln.
(Nennen wir sie mal T1)
Da diese allerdings mehrere Millionen Einträge haben kann lese ich sie Packetweise mithilfe eines DB-Cursor. Die Größe der Packete ist per Eingabeparameter einstellbar.
In einer anderen Tabelle(T2) ist ein Schlüsselfeld gleich einem normalen Feld meiner T1. Allerdings ist T2 absolut unsortierbar.
Deshalb will ich immer die passenden Einträge zu den derzeit bearbeiteten T1-Einträgen aus T2 lesen.
Nun habe ich aus T1 eine Rangestabelle gebaut, diese mithilfe des Fubas "FREE_SELECTIONS_RANGE_2_WHERE" in eine Where bedingung umgewandelt und damit dann selektiert.
Funktioniert alles wunderbar, solange die Lesegröße der T1 150 Einträge nicht übersteigt.(Entsprechen dann auch 150 where-Bedingungen.) Bei mehr Where-Bedingungen kommt eine Fehlermeldung.
Nun zu meinen Fragen:
Ich könnte viele Einträge aus T1 lesen und verarbeiten. Da ich nicht weiß wieviele Einträge der Benutzer einlesen will, müssten die Selektionskriterien für T2 dann dynamisch in 150er Packete separiert werden. Kann ich hierfür dynamisch eine Anzahl von internen Tabellen erstellen?
Ich hoffe mal meine Absichten kamen einigermaßen klar rüber.
Vielen Dank für eure Antworten!
Viele Grüße
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo,
also um ganz ehrlich zu sein ... 100%ig verstanden hab ich's noch nicht Sorry.
Welches Release habt Ihr denn? Laesst sich das nicht mit dynamischen where-Bedingungen einfacher loesen?
Wieso brauchst Du 150 verschiedene where-Bedingungen und was fuer eine Fehlermeldung bekommst Du?
Wenn Du ein Beispiel geben koenntest, das waere bestimmt hilfreich.
Gruss,
Steff
also um ganz ehrlich zu sein ... 100%ig verstanden hab ich's noch nicht
Sorry.Welches Release habt Ihr denn? Laesst sich das nicht mit dynamischen where-Bedingungen einfacher loesen?
Wieso brauchst Du 150 verschiedene where-Bedingungen und was fuer eine Fehlermeldung bekommst Du?
Wenn Du ein Beispiel geben koenntest, das waere bestimmt hilfreich.
Gruss,
Steff
Hey,
danke für deine Antwort!
Ich arbeite auf ECC 6.0 im Release 700.
Der Fehler "DBIF_RSQL_INVALID_RSQL" mit der Ausnahme "CX_SY_OPEN_SQL_DB" erscheint. Als mögliche Fehlerursache wird angegeben, dass die maximale Länge eines SQL-Statements erreicht ist.
Ich nehme 150, weil das mit die größte Anzahl an where-Bedingungen ist, bei der mein System nicht dumpt.
Außerdem ist es performanter wenige große Selects zu haben als viele kleine.
Ich will eigentlich die Lesemenge aus T1 vom Benutzer steuern lassen. Die Lesemenge aus T2 hängt dabei aber 1:1 von T1 ab.
Zurzeit mach ich folgendes:
FeldX1 EQ XYZ OR
FeldX2 EQ ABC OR...
Ich weiß nicht recht wie ich die Where-Bedingungen sonst machen soll.^^
Für hilfreiche Tipps bin ich dankbar!
Viele Grüße
danke für deine Antwort!
Ich arbeite auf ECC 6.0 im Release 700.
Der Fehler "DBIF_RSQL_INVALID_RSQL" mit der Ausnahme "CX_SY_OPEN_SQL_DB" erscheint. Als mögliche Fehlerursache wird angegeben, dass die maximale Länge eines SQL-Statements erreicht ist.
Ich nehme 150, weil das mit die größte Anzahl an where-Bedingungen ist, bei der mein System nicht dumpt.
Außerdem ist es performanter wenige große Selects zu haben als viele kleine.
Ich will eigentlich die Lesemenge aus T1 vom Benutzer steuern lassen. Die Lesemenge aus T2 hängt dabei aber 1:1 von T1 ab.
Zurzeit mach ich folgendes:
LT_WHERE-WHERE_TAB sieht so ähnlich aus:*Aufbau der Ranges
LOOP AT LT_T1 INTO LV_T1.
LV_RTAB-LOW = LV_T1-FeldX.
LV_RTAB-SIGN = 'I'.
LV_RTAB-OPTION = 'EQ'.
APPEND LV_RTAB TO LT_RTAB.
ENDLOOP.
*
*Hier fehlen ein paar umformungen... die LT_RTAB wird
*einfach in eine tiefe Struktur gepackt.
*
*Convert RANGE table to WHERE-clause
CALL FUNCTION 'FREE_SELECTIONS_RANGE_2_WHERE'
EXPORTING
FIELD_RANGES = LT_RANGES
IMPORTING
WHERE_CLAUSES = LT_WHERE.
*Select
SELECT
Key1
Key2
Key3
Feld1
Feld2
FROM T2 INTO TABLE LT_T2
WHERE (LT_WHERE-WHERE_TAB).
FeldX1 EQ XYZ OR
FeldX2 EQ ABC OR...
Ich weiß nicht recht wie ich die Where-Bedingungen sonst machen soll.^^
Für hilfreiche Tipps bin ich dankbar!
Viele Grüße
Hi,
hab mal ein bisschen ausprobiert:
Was mich etwas verwundert hatte war die Benutzung des Bausteins 'FREE_SELECTIONS_RANGE_2_WHERE', da das eigentlich die DB-Schnittstelle selbst erledigt.
Ich dachte, dass diese so smart ist und einem das Aufteilen in Pakete abnimmt. Allerdings ist es auch in diesem Beispiel so, dass wenn die rangestabelle zu gross wird (z.b. 150 Eintraege) das select-statement ebenfalls abbricht (aus demselben Grund, das SQL-statement in der where-Bedingung wird zu lang).
Ich weiss nicht genau was der Usecase ist, aber evtl. laesst sich die ganze Transaktion etwas anders designen. Mehr als 150 Eintraege zu bearbeiten halte ich fuer etwas unuebersichtlich.
Evtl. kann man auch ein Sortierung der Tabellen erreichen und damit die where-Bedingung optimieren (ich kenne aber zu wenig die Hintergruende, insofern hoffe ich dass diese Vorschlaege weiterhelfen).
Gruss,
Steff[/quote]
hab mal ein bisschen ausprobiert:
Code: Alles auswählen.
DATA: lt_ref TYPE REF TO data.
DATA: BEGIN OF lt_range OCCURS 0,
sign TYPE c LENGTH 1,
option TYPE c LENGTH 2,
low LIKE BKPF-BELNR,
high LIKE BKPF-BELNR,
END OF lt_range.
FIELD-SYMBOLS: <lft_bkpf> TYPE table,
<lft_bseg> TYPE table,
<lfs_bkpf> TYPE ANY,
<lf_belnr> TYPE ANY.
CREATE DATA lt_ref TYPE STANDARD TABLE OF ('BKPF') WITH DEFAULT KEY.
ASSIGN lt_ref->* TO <lft_bkpf>.
SELECT * FROM bkpf up to 10 ROWS INTO TABLE <lft_bkpf>.
LOOP AT <lft_bkpf> ASSIGNING <lfs_bkpf>.
ASSIGN COMPONENT 'BELNR' OF STRUCTURE <lfs_bkpf> TO <lf_belnr>.
CLEAR lt_range.
MOVE <lf_belnr> TO lt_range-low.
lt_range-sign = 'I'.
lt_range-option = 'EQ'.
APPEND lt_range.
ENDLOOP.
CREATE DATA lt_ref TYPE STANDARD TABLE OF ('BSEG') WITH DEFAULT KEY.
ASSIGN lt_ref->* TO <lft_bseg>.
SELECT * FROM BSEG INTO TABLE <lft_bseg> WHERE belnr IN
lt_range[].
Ich dachte, dass diese so smart ist und einem das Aufteilen in Pakete abnimmt. Allerdings ist es auch in diesem Beispiel so, dass wenn die rangestabelle zu gross wird (z.b. 150 Eintraege) das select-statement ebenfalls abbricht (aus demselben Grund, das SQL-statement in der where-Bedingung wird zu lang).
Ich weiss nicht genau was der Usecase ist, aber evtl. laesst sich die ganze Transaktion etwas anders designen. Mehr als 150 Eintraege zu bearbeiten halte ich fuer etwas unuebersichtlich.
Evtl. kann man auch ein Sortierung der Tabellen erreichen und damit die where-Bedingung optimieren (ich kenne aber zu wenig die Hintergruende, insofern hoffe ich dass diese Vorschlaege weiterhelfen).
Gruss,
Steff[/quote]
Hallo,
nochmal: Tabelle T1, sehr groß, sortiert, mit Index.
Tabelle T2 (Wurschttabelle), hat Einträge und in einem Feld steht der Verweis auf T1.
Jetzt mal das Pferd umdrehen und andersrum:
Wie wäre es mit Lesen der Tabelle T2 (Reihenfolge egal) und dann immer schön den passenden T1-Satz mit SELECT SINGLE geholt.
Könnte mir auch eine View vorstellen T2->T1 ...
Gruß
babap
nochmal: Tabelle T1, sehr groß, sortiert, mit Index.
Tabelle T2 (Wurschttabelle), hat Einträge und in einem Feld steht der Verweis auf T1.
Jetzt mal das Pferd umdrehen und andersrum:
Wie wäre es mit Lesen der Tabelle T2 (Reihenfolge egal) und dann immer schön den passenden T1-Satz mit SELECT SINGLE geholt.
Könnte mir auch eine View vorstellen T2->T1 ...
Gruß
babap
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
4352
Views
Views
Dynamisch Workarea und interne Tabellen benutzen?
von kbit100 » 07.05.2008 14:51 • Verfasst in ABAP® für Anfänger
von kbit100 » 07.05.2008 14:51 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
1647
Views
Views
JOIN über 2 Tabellen mit verschiedenen Bedingungen
von Patrick1982 » 06.03.2020 13:53 • Verfasst in ABAP® für Anfänger
von Patrick1982 » 06.03.2020 13:53 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
1304
Views
Views
3 Tabellen miteinander vergleichen und Treffer ausgeben (Ohne Interne Tabellen)
von Reyvn94 » 07.02.2022 00:34 • Verfasst in ABAP® für Anfänger
von Reyvn94 » 07.02.2022 00:34 • Verfasst in ABAP® für Anfänger
12
Antw.
Antw.
8038
Views
Views
2
Antw.
Antw.
4901
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1047
vor 2 Tagen von DeathAndPain 4 / 1047
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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1047
vor 2 Tagen von DeathAndPain 4 / 1047