DBIF_RSQL_INVALID_RSQL Error
Hallo!
Nachfolgendes SELECT-Statement verursacht bei mir ein DBIF_RSQL_INVALID_RSQL Error.
Grund hierfür ist die zu große lt_bu_partner_range (16.000 Datensätze).
Könnt ihr mir vllt. sagen, wie ich das Problem noch halbwegs performant lösen kann?
Grüße
Nachfolgendes SELECT-Statement verursacht bei mir ein DBIF_RSQL_INVALID_RSQL Error.
Grund hierfür ist die zu große lt_bu_partner_range (16.000 Datensätze).
Könnt ihr mir vllt. sagen, wie ich das Problem noch halbwegs performant lösen kann?
Code: Alles auswählen.
SELECT
b~partner
b~name_org1
b~name_org2
b~name_last
b~name_first
b~type
INTO TABLE
lt_customer
FROM
but000 AS b INNER JOIN ekun AS e ON b~partner = e~partner
INNER JOIN fkkvkp AS f ON f~gpart = b~partner
INNER JOIN ever AS v ON v~vkonto = f~vkont
WHERE
e~zvks_online_flag = 'X' AND
v~vbeginn < lv_mig_date AND
v~vende > lv_mig_date AND
b~partner IN lt_bu_partner_range
.
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,
wo füllst du denn die Range Tabelle - kannst du da das Ganze nicht stückeln / portionieren und den Select da absetzen mit appending table itab ?
Gruss Jens
wo füllst du denn die Range Tabelle - kannst du da das Ganze nicht stückeln / portionieren und den Select da absetzen mit appending table itab ?
Gruss Jens
thanks Jens
Beitrag
von a-dead-trousers (Top Expert / 4286 / 214 /
1142
)
»
Vielleicht kannst du ja ansatt eines Ranges eine Tabelle von Kunden verwenden.
Schau dir mal den Zusatz FOR ALL ENTRIES für das SELECT-Statement an. Da würde SAP/ABAP die Stückelung vornehmen. Du musst nur dafür sorgen, dass die Schlüssel für den Zugriff eindeutig sind. Sprich es darf jeder Schlüssel in der Tabelle nur einmal vorkommen.
(SORT & DELETE ADJACENT DUPLICATES)
lg ADT
Schau dir mal den Zusatz FOR ALL ENTRIES für das SELECT-Statement an. Da würde SAP/ABAP die Stückelung vornehmen. Du musst nur dafür sorgen, dass die Schlüssel für den Zugriff eindeutig sind. Sprich es darf jeder Schlüssel in der Tabelle nur einmal vorkommen.
(SORT & DELETE ADJACENT DUPLICATES)
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
Ok, erstes Posting ist irgendwie ins Nirwana....
Du kannst auch versuchen, die rangetabelle lt_bu_partner_range zu komprimieren.
Aus neuen Zeilen in der Tabelle: "1,2,3,4,5,6,7,8,9" wird dann eine Zeile "1-9".
Du kannst auch versuchen, die rangetabelle lt_bu_partner_range zu komprimieren.
Aus neuen Zeilen in der Tabelle: "1,2,3,4,5,6,7,8,9" wird dann eine Zeile "1-9".
Ich hätte vielleicht erwähnen sollen, dass die 16.000 Datensätze auf dem Q-System entstanden sind. Ich vermute, dass auf dem Produktivsystem deutlich mehr Daten vorhanden sind.
Würde ein FOR ALL ENTRIES nicht auch (bei dieser Anzahl an Daten) zu einem Kurzdump führen? Problem ist ja auch, dass es produktiv noch mehr wären.
Wenn ich das mit der Komprimierung richtig verstanden habe, würden rund 1/9 der Daten in der Range-Tabelle anfallen, ja? Das könnte meines Erachtens immer noch zu viel sein. Zumindest wenn es dann produktiv läuft, wird es zu Kurzdumps führen.
Würde ein FOR ALL ENTRIES nicht auch (bei dieser Anzahl an Daten) zu einem Kurzdump führen? Problem ist ja auch, dass es produktiv noch mehr wären.
Wenn ich das mit der Komprimierung richtig verstanden habe, würden rund 1/9 der Daten in der Range-Tabelle anfallen, ja? Das könnte meines Erachtens immer noch zu viel sein. Zumindest wenn es dann produktiv läuft, wird es zu Kurzdumps führen.
Beitrag
von Alexander D. (Expert / 682 / 30 /
84
)
»
nicht ganz. Gemeint war, dass Du zusammenhängende Zahlen in Bereiche zusammenfassen könntest. Wenn die 16.000 Zahlen alle fortlaufend wären, so würde nach der Komprimierung genau eine Zeile übrig bleiben mit low = 1 und high = 16000ABAP_User hat geschrieben:Wenn ich das mit der Komprimierung richtig verstanden habe, würden rund 1/9 der Daten in der Range-Tabelle anfallen, ja? Das könnte meines Erachtens immer noch zu viel sein. Zumindest wenn es dann produktiv läuft, wird es zu Kurzdumps führen.
FOR ALL ENTRIES sollte mit 16000 übrigens problemlos zurechtkommen
Zuletzt geändert von Alexander D. am 25.09.2012 15:33, insgesamt 1-mal geändert.
schöne Grüße
Alexander
ECC 6.0 EHP 7
Alexander
ECC 6.0 EHP 7
hier mal was von der SAP dazu:
das wo unten Fett makiert ist, gibt dir glaube ich die Antowrt.
SELECT ... FOR ALL ENTRIES
In der äußeren Schleife wird die Datenbanktabelle (PACKAGE SIZE) portionsweise in eine interne Tabelle eingelesen, die nach dem Primärschlüssel sortiert wird (SORT auf die interne Tabelle oder mit ORDER BY PRIMARY KEY einlesen). Für jede Datenmenge der internen Tabelle werden alle zugehörigen abhängigen Sätze mit einem Datenbankzugriff in eine weitere interne Tabelle gelesen (mit SELECT ... FOR ALL ENTRIES), die auch sortiert werden sollte. Danach kann die weitere Verarbeitung mit einem geschachtelten LOOP fortgesetzt werden.
Der Vorteil der Variante SELECT ... FOR ALL ENTRIES besteht darin, das er unabhängig von der Selektivität der Bedingung auf der äußeren Tabelle eine vernünftige Performance bietet, da er im Gegensatz zum geschachtelten SELECT mengenorientiert gegenüber der Datenbank arbeitet, und trotzdem nur die relevanten Datensätze liest (anders als bei der parallelen Cursorverarbeitung).
Der Zusatz FOR ALL ENTRIES sollte verwendet werden, wenn ein JOIN aus syntaktischen gründen nicht möglich ist, oder falls durch den JOIN eine zu große Redundanz durch die stets wiederholten Felder aus der linken Tabelle entstünde.
http://help.sap.com/abapdocu_70/de/ABEN ... EN_SQL.htm
das wo unten Fett makiert ist, gibt dir glaube ich die Antowrt.
SELECT ... FOR ALL ENTRIES
In der äußeren Schleife wird die Datenbanktabelle (PACKAGE SIZE) portionsweise in eine interne Tabelle eingelesen, die nach dem Primärschlüssel sortiert wird (SORT auf die interne Tabelle oder mit ORDER BY PRIMARY KEY einlesen). Für jede Datenmenge der internen Tabelle werden alle zugehörigen abhängigen Sätze mit einem Datenbankzugriff in eine weitere interne Tabelle gelesen (mit SELECT ... FOR ALL ENTRIES), die auch sortiert werden sollte. Danach kann die weitere Verarbeitung mit einem geschachtelten LOOP fortgesetzt werden.
Der Vorteil der Variante SELECT ... FOR ALL ENTRIES besteht darin, das er unabhängig von der Selektivität der Bedingung auf der äußeren Tabelle eine vernünftige Performance bietet, da er im Gegensatz zum geschachtelten SELECT mengenorientiert gegenüber der Datenbank arbeitet, und trotzdem nur die relevanten Datensätze liest (anders als bei der parallelen Cursorverarbeitung).
Der Zusatz FOR ALL ENTRIES sollte verwendet werden, wenn ein JOIN aus syntaktischen gründen nicht möglich ist, oder falls durch den JOIN eine zu große Redundanz durch die stets wiederholten Felder aus der linken Tabelle entstünde.
http://help.sap.com/abapdocu_70/de/ABEN ... EN_SQL.htm
<:: XING-Gruppe Tricktresor::>
Wenn ich FOR ALL ENTRIES IN lt_bu_partner_range vor das WHERE Statement setze bekomme ich folgenden Sytaxfehler:
In der WHERE-Bedingung wird nicht auf die FOR ALL ENTRIES Tabelle Bezug
lt_bu_partner_range ist folgenermaßen definiert:
Ich kann in der WHERE-Bedingung jetzt aber nicht auf lt_bu_partner_range Bezug nehmen, da es kein Feld besitzt.
In der WHERE-Bedingung wird nicht auf die FOR ALL ENTRIES Tabelle Bezug
lt_bu_partner_range ist folgenermaßen definiert:
Code: Alles auswählen.
DATA lt_bu_partner_range TYPE RANGE OF bu_partner
Beitrag
von a-dead-trousers (Top Expert / 4286 / 214 /
1142
)
»
hi!
Wo "entsteht" der Range? Sprich wird er vom Benutzer befüllt oder von einem anderen Select-Statement?
Wenn Ersteres: Da funktioniert FOR ALL ENTRIES nicht, da der Benutzer auch Einträge zum Ausschluss angegeben haben könnte (SIGN = 'E') oder mit Wildcards gearbeitet wurde (OPTION = 'CP')
Wenn zweiteres: Da würde ich überhaupt eine andere Tabelle empfehlen, die nur aus dem Feld besteht das du brauchst. Damit sparst du jede Menge Speicher (vorallem bei 16.000 Datenzeilen)
lg ADT
Wo "entsteht" der Range? Sprich wird er vom Benutzer befüllt oder von einem anderen Select-Statement?
Wenn Ersteres: Da funktioniert FOR ALL ENTRIES nicht, da der Benutzer auch Einträge zum Ausschluss angegeben haben könnte (SIGN = 'E') oder mit Wildcards gearbeitet wurde (OPTION = 'CP')
Wenn zweiteres: Da würde ich überhaupt eine andere Tabelle empfehlen, die nur aus dem Feld besteht das du brauchst. Damit sparst du jede Menge Speicher (vorallem bei 16.000 Datenzeilen)
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
Die Frage ist aber nicht ernst gemeint (Das der User die 16.000 am Bildschirm eingibt), odera-dead-trousers hat geschrieben:hi!
Wo "entsteht" der Range? Sprich wird er vom Benutzer befüllt oder von einem anderen Select-Statement?
Wenn Ersteres: Da funktioniert FOR ALL ENTRIES nicht, da der Benutzer auch Einträge zum Ausschluss angegeben haben könnte (SIGN = 'E') oder mit Wildcards gearbeitet wurde (OPTION = 'CP')
Wenn zweiteres: Da würde ich überhaupt eine andere Tabelle empfehlen, die nur aus dem Feld besteht das du brauchst. Damit sparst du jede Menge Speicher (vorallem bei 16.000 Datenzeilen)
lg ADT
Hi!
Hab die SELECT-Abfrage mal angepasst.
Inzwischen bekomme ich keinen DBIF_RSQL_INVALID_RSQL Error, die Abfrage läuft jedoch ewig, weswegen ich abgebrochen habe. In der but000 befinden sich 1.300.000 Datensätze, in lt_bu_partner_range wie bereits erwähnt 16.000. Meint ihr wirklich nicht, dass dies insgesamt zu viel sind?
Hab die SELECT-Abfrage mal angepasst.
Inzwischen bekomme ich keinen DBIF_RSQL_INVALID_RSQL Error, die Abfrage läuft jedoch ewig, weswegen ich abgebrochen habe. In der but000 befinden sich 1.300.000 Datensätze, in lt_bu_partner_range wie bereits erwähnt 16.000. Meint ihr wirklich nicht, dass dies insgesamt zu viel sind?
Code: Alles auswählen.
SELECT
b~partner
b~name_org1
b~name_org2
b~name_last
b~name_first
b~type
INTO TABLE
lt_customer
FROM
but000 AS b INNER JOIN ekun AS e ON b~partner = e~partner
INNER JOIN fkkvkp AS f ON f~gpart = b~partner
INNER JOIN ever AS v ON v~vkonto = f~vkont
FOR ALL ENTRIES IN lt_bu_partner_range
WHERE
e~zvks_online_flag = 'X' AND
v~vbeginn < lv_mig_date AND
v~vende > lv_mig_date AND
b~partner <> lt_bu_partner_range-low.
Ich bin mir nicht sicher, ob diese Abfrage einen Sinn ergibt: <> internal_table-field
Code: Alles auswählen.
FOR ALL ENTRIES IN lt_bu_partner_range
WHERE ........
b~partner <> lt_bu_partner_range-low.Hm...bin mir da auch nicht sicher.
Vermutlich aber nicht, da ich FOR ALL ENTRIES von lt_bu_partner_range selektiere, die nicht in lt_bu_partner_range sind...Widerspruch?!
Was ich eigentlich möchte sind alle Geschäftspartner, die noch nicht in lt_bu_partner_range sind...
Vermutlich aber nicht, da ich FOR ALL ENTRIES von lt_bu_partner_range selektiere, die nicht in lt_bu_partner_range sind...Widerspruch?!
Was ich eigentlich möchte sind alle Geschäftspartner, die noch nicht in lt_bu_partner_range sind...
Ich probiers wohl mal so...alle in lt_customer laden und dann über lt_customer und lt_bu_partner_range loopen um die entsprechenden herauszufiltern. Vermutlich nicht so performant, aber mal schauen.
Oder habt ihr bessere Vorschläge?
Oder habt ihr bessere Vorschläge?
Vergleichbare Themen
0
Antw.
Antw.
1808
Views
Views
DIM-00035: You have entered and invalid option for the -EDIT
von Pitzy007 » 07.02.2007 14:47 • Verfasst in SAP - Allgemeines
von Pitzy007 » 07.02.2007 14:47 • Verfasst in SAP - Allgemeines
1
Antw.
Antw.
200
Views
Views
7
Antw.
Antw.
3861
Views
Views
2
Antw.
Antw.
3218
Views
Views
ERROR bei der Installation von Web AS 6.40
von bohne » 25.09.2006 15:08 • Verfasst in Web Application Server
von bohne » 25.09.2006 15:08 • Verfasst in Web Application Server
2
Antw.
Antw.
5046
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
xlsx mit CL_SALV_TABLE aus interner Tabelle erstellen - kann man auch mehrere Tabreiter erzeugen?
vor 15 Stunden von black_adept 7 / 73
vor 15 Stunden von black_adept 7 / 73
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
xlsx mit CL_SALV_TABLE aus interner Tabelle erstellen - kann man auch mehrere Tabreiter erzeugen?
vor 15 Stunden von black_adept 7 / 73
vor 15 Stunden von black_adept 7 / 73