Wobei sich mir bei dem gezeigten Coding die Frage stellt wieso man den Umweg über FOR ALL ENTRIES macht, das ganze kann man mit einem SELECT und SubSELECT auch ohne lösen:a-dead-trousers hat geschrieben:Zuerst alles selektieren und dann im Programm ausfiltern.
Code: Alles auswählen.
SELECT mseg~mblnr
mseg~mjahr
mseg~zeile
INTO CORRESPONDING FIELDS OF TABLE lt_data
FROM mkpf AS mkpf
JOIN mseg AS mseg
ON mkpf~mblnr = mseg~mblnr
AND mkpf~mjahr = mseg~mjahr
WHERE ( mkpf~mblnr IN s_mblnrm AND mkpf~mjahr IN s_mjahrm )
AND NOT EXSIST ( SELECT *
FROM zz_not
WHERE zz_not~mblnr EQ mseg~mblnr
AND zz_not~mjahr EQ mseg~mjahr
AND zz_not~zeile EQ mseg~zeile ) .
Hinweis : Subqueries gehen schon ewig in SAPa-dead-trousers hat geschrieben:Hi!
Du könntest zumindest für ein einzelnes Feld ein IN <range> (mit Exlcude-Einträgen) oder NOT IN <range> (mit Include-Einträgen) verwenden.
Wenn du aber mehrer Felder deiner Ausschlusstabelle gleichzeitig und zusammenhängend abfragen möchtest, wird es kompliziert:
Unter 7.40 könntest du dank der neuen Syntax mit ausschließenden JOINs oder SUBQUERY arbeiten.
Alternativ würden dir die CDS unter Eclipse das volle Potenzial der SQL-Syntax bereitstellen, um dieses Problem zu lösen.
Wenn du noch in einem älteren Release unterwegs bist, wirst du wohl in den sauren Apfel beisen müssen:
Zuerst alles selektieren und dann im Programm ausfiltern.
Generell sei aber noch der Hinweis gegeben, dass im Datenbankumfeld Ausschlüsse nicht empfohlen werden, da immer alle EInträge ermittelt werden müssen (Full Table Scan)
Bei großen Tabellen kann das sehr rasch inperformant werden, wenn man nur einige wenige Einträge weglassen möchte.
lg ADT
jubo515 hat geschrieben:Hallo,
ich bin auf der Suche nach ein Syntax mit der ich in der Select - Anweisung die Einträge einer Tabelle ausschliessen kann.
Anbei mal das Coding wie ich es mir vorstelle:
REPORT zz_test_01.
TYPES: BEGIN OF ty_data,
mblnr TYPE mblnr,
mjahr TYPE mjahr,
zeile TYPE mblpo,
END OF ty_data,
tty_data TYPE TABLE OF ty_data.
TABLES: zz_not,
mkpf,
mseg.
DATA: gs_not TYPE zz_not,
gt_not TYPE TABLE OF zz_not.
DATA: ls_data TYPE ty_data,
lt_data TYPE tty_data.
" Selektion der Daten für das Ergebnis
SELECT-OPTIONS: s_mblnrm FOR mkpf-mblnr,
s_mjahrm FOR mkpf-mjahr.
SELECTION-SCREEN SKIP.
" Selektion der Daten für den Ausschluss
SELECT-OPTIONS: s_mblnrn FOR zmc_inv_fs_not-mblnr,
s_mjahrn FOR zmc_inv_fs_not-mjahr.
START-OF-SELECTION.
SELECT * INTO CORRESPONDING FIELDS OF TABLE gt_not
FROM zz_not
WHERE mblnr IN s_mblnrn
AND mjahr IN s_mjahrn.
SELECT mseg~mblnr
mseg~mjahr
mseg~zeile
INTO CORRESPONDING FIELDS OF TABLE lt_data
FROM mkpf AS mkpf
JOIN mseg AS mseg
ON mkpf~mblnr = mseg~mblnr
AND mkpf~mjahr = mseg~mjahr
FOR ALL ENTRIES IN gt_not
WHERE ( mkpf~mblnr IN s_mblnrm AND mkpf~mjahr IN s_mjahrm )
AND NOT ( mseg~mblnr EQ gt_not-mblnr
AND mseg~mjahr NE gt_not-mjahr
AND mseg~zeile NE gt_not-zeile ) .
WRITE: / 'SY-SUBRC:', sy-subrc.
LOOP AT lt_data INTO ls_data.
WRITE: / ls_data-mblnr, '|', ls_data-mjahr, '|', ls_data-zeile.
ENDLOOP.
Ausgangsdaten:
mseg-belnr:
1
2
3
4
5
6
7
8
9
Ausschlustabelle:
3
4
5
Ergebnis gewollt:
1
2
6
7
8
9
Hat jemand eine Idee wie man das in den select bekommt.
Bin für jede Hilfe dankbar.
VG
Juri
a-dead-trousers hat geschrieben:Hi!
Generell sei aber noch der Hinweis gegeben, dass im Datenbankumfeld Ausschlüsse nicht empfohlen werden, da immer alle EInträge ermittelt werden müssen (Full Table Scan)
Bei großen Tabellen kann das sehr rasch inperformant werden, wenn man nur einige wenige Einträge weglassen möchte.
lg ADT
Ja, stimmt. Ich hab da zwei Aussagen in einem Satz vermischt. Eigentlich meinte ich, dass die Syntax in 7.40 erweitert wurde. Besagte ausschließenden Joins und die Subqueries haben auch einige Verbesserungen erhalten.gtoXX hat geschrieben:Hinweis : Subqueries gehen schon ewig in SAPa-dead-trousers hat geschrieben:Unter 7.40 könntest du dank der neuen Syntax mit ausschließenden JOINs oder SUBQUERY arbeiten.
Ja, schon. Aber wenn man in seinem Programm bereits darauf achtet, dass man keine unnötig komplizierten Abfragen zusammenbaut muss sich der Optimizier nicht damit rumplagen. Unter SAP Hana schaut das ganze zwar wieder etwas anders aus, aber ich glaube selbst da ist es möglich "inperformante" Abfragen zu generieren.gtoXX hat geschrieben:Zum den Teil : Hängt das nicht vom Optimizier ab ? Eine schlaue Datenbank würde doch zumindest "IN" abrufen und dann im internen Prozess "NE" entfernen, was im Speicher geschieht. Somit gäbe es keinen Full Table Scan.a-dead-trousers hat geschrieben:Generell sei aber noch der Hinweis gegeben, dass im Datenbankumfeld Ausschlüsse nicht empfohlen werden, da immer alle EInträge ermittelt werden müssen (Full Table Scan)
Bei großen Tabellen kann das sehr rasch inperformant werden, wenn man nur einige wenige Einträge weglassen möchte.
2 Frage zu diesem Kommentar.gtoXX hat geschrieben: Mal ein paar Anmerkungen zum Code :
[...]
Arbeite mit Feldsymbolen statt mit Arbeitsbereichen, das benötigt nur 20% der Performance
[...]