Select mit unterschiedlichen Ergebnissen
Hallole Community,
ich habe ein Problem bei folgenden Selects: der erste liefert mir 24 Ergebnisse, der zweite 27. Selektionseinschränkungen und Join sind identisch. Die 27 aus dem 2. Select sind korrekt. Ich such mir seit Freitag bereits nen Wolf, wo liegt mein Denkfehler.
[code] SELECT b~ilart c~wogbtr
INTO CORRESPONDING FIELDS OF wa_zinstand
FROM aufk AS a INNER JOIN afih AS b
ON a~aufnr = b~aufnr
INNER JOIN coep AS c
ON a~objnr = c~objnr
FOR ALL ENTRIES IN it_proj
WHERE a~pspel = it_proj-pspel
AND ( b~ilart EQ 'ZAI'
OR b~ilart EQ 'ZGA' ).
COLLECT wa_zinstand INTO it_zinstand.
ENDSELECT.
SELECT *
INTO CORRESPONDING FIELDS OF table it_zinstand
FROM aufk AS a INNER JOIN coep AS b
ON a~objnr = b~objnr
inner JOIN afih AS c
ON a~aufnr = c~aufnr
FOR ALL ENTRIES IN it_proj
WHERE a~pspel = it_proj-pspel
AND ( c~ilart EQ 'ZAI'
OR c~ilart EQ 'ZGA' ).[/code]
Danke und Ciao
Jens
ich habe ein Problem bei folgenden Selects: der erste liefert mir 24 Ergebnisse, der zweite 27. Selektionseinschränkungen und Join sind identisch. Die 27 aus dem 2. Select sind korrekt. Ich such mir seit Freitag bereits nen Wolf, wo liegt mein Denkfehler.
[code] SELECT b~ilart c~wogbtr
INTO CORRESPONDING FIELDS OF wa_zinstand
FROM aufk AS a INNER JOIN afih AS b
ON a~aufnr = b~aufnr
INNER JOIN coep AS c
ON a~objnr = c~objnr
FOR ALL ENTRIES IN it_proj
WHERE a~pspel = it_proj-pspel
AND ( b~ilart EQ 'ZAI'
OR b~ilart EQ 'ZGA' ).
COLLECT wa_zinstand INTO it_zinstand.
ENDSELECT.
SELECT *
INTO CORRESPONDING FIELDS OF table it_zinstand
FROM aufk AS a INNER JOIN coep AS b
ON a~objnr = b~objnr
inner JOIN afih AS c
ON a~aufnr = c~aufnr
FOR ALL ENTRIES IN it_proj
WHERE a~pspel = it_proj-pspel
AND ( c~ilart EQ 'ZAI'
OR c~ilart EQ 'ZGA' ).[/code]
Danke und Ciao
Jens
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Dann nimm halt diesen korrekten Select.Prego hat geschrieben:Die 27 aus dem 2. Select sind korrekt.
Von aussen ist es recht schwer zu "debuggen" und wir wissen auch nicht, welche drei einmal zuviel und eimal zu wenig sind.
Super, darauf wär ich jetzt nie gekommen.
klar kann ich den nehmen. Nur warum soll ich hunderte Felder selektieren, wenn ich nur 2 brauch und dadurch die Summierung je Instandhaltungleistungsart bereits includiert habe. Ich knall dann halt den Speicher zu, wenn das in der Massenverarbeitungs läuft. Außerdem muß es ja eine Ursache geben, dass, sobald ich eine Feldeinschränkung mache, 3 Sätze nicht gezogen werden. Das ihr die Daten nicht kennt und dies nicht unbedingt debuggen könnt, ist mir auch klar. Manchmal liegt es aber an den einfachsten Dingen, die man selbst nicht sieht.
klar kann ich den nehmen. Nur warum soll ich hunderte Felder selektieren, wenn ich nur 2 brauch und dadurch die Summierung je Instandhaltungleistungsart bereits includiert habe. Ich knall dann halt den Speicher zu, wenn das in der Massenverarbeitungs läuft. Außerdem muß es ja eine Ursache geben, dass, sobald ich eine Feldeinschränkung mache, 3 Sätze nicht gezogen werden. Das ihr die Daten nicht kennt und dies nicht unbedingt debuggen könnt, ist mir auch klar. Manchmal liegt es aber an den einfachsten Dingen, die man selbst nicht sieht.
Beitrag
von ralf.wenzel (Top Expert / 3955 / 202 /
281
)
»
IMHO im Inner Join.Prego hat geschrieben:ich habe ein Problem bei folgenden Selects: der erste liefert mir 24 Ergebnisse, der zweite 27. Selektionseinschränkungen und Join sind identisch. Die 27 aus dem 2. Select sind korrekt. Ich such mir seit Freitag bereits nen Wolf, wo liegt mein Denkfehler.
Wenn du also Kombinationen hast, wo diese Bedingung nicht erfüllt ist, kannst du je nach Reihenfolge unterschiedliche Ergebnisse herausbekommen. Ich würde (weil mich das an deiner Stelle auch interessieren würde) mir die Teilmengen der einzelnen SELECTS ansehen und den Join gedanklich nachvollziehen (am Besten mit einer kleinen Treffermenge).SAP-Hilfe hat geschrieben:Ergebnismenge beim inneren Join
Der innere Join verknüpft die Spalten jeder selektierten Zeile der linken Seite mit den Spalten sämtlicher Zeilen der rechten Seite, die die Bedingung join_cond gemeinsam erfüllen. Für jede solche Zeile der rechten Seite wird eine Zeile in der Ergebnismenge erzeugt, wobei der Inhalt der Spalten der linken Seite gegebenenfalls dupliziert wird. Wenn keine Zeile der rechten Seite die Bedingung join_cond erfüllt, wird in der Ergebnismenge keine Zeile erzeugt.
Über einen Bericht deinerseits würden wir uns freuen, wenn du was herausgefunden hast. Schon beim LEFT OUTER Join solltest du bemerken, dass die Unterschiede zwischen den beiden SELECTs vollkommen anders aussehen.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Neuer Artikel über BRF+ in der neuen iX 05/25!
Ich versteh das nicht, nehm ich die Select einzeln und teste das über se16n bekomm ich genau die 27. Ergebnisse. Kopiere ich den 1. Select und ändere ihn auf select * ab. Kommen auch die 27. Sobald ich 1 Feld explizit angebe bekomme ich nur 24 Treffer. In der AUFK werden 2 Sätze selektiert, in der AFIH ebenfalls und in der COEP sind es dann 27.
Das selbe Konstrukt als Query oder Quickview, bringt mir auch 27 Treffer.
Das selbe Konstrukt als Query oder Quickview, bringt mir auch 27 Treffer.
Wie genau sind denn wa_zinstand bzw it_instand aufgebaut?
Bestehen diese nur aus den 2 Feldern? Poste mal bitte die Datendeklaration dafür, ich will mal nachprüfen, ob meine ins Blaue hineingeratene Idee überhaupt Sinn macht, auch wenn ich da nicht mehr dran glaube
Bestehen diese nur aus den 2 Feldern? Poste mal bitte die Datendeklaration dafür, ich will mal nachprüfen, ob meine ins Blaue hineingeratene Idee überhaupt Sinn macht, auch wenn ich da nicht mehr dran glaube
Moin,
gruß Jens
.. Dann hol Dir doch den Join aus dem Sourcecode vom Query.Das selbe Konstrukt als Query oder Quickview, bringt mir auch 27 Treffer.
gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Der sieht wie folgt aus, ist also, bis auf das Where, identisch
select COEP~WOGBTR AFIH~ILART
from AUFK
inner join COEP
on COEP~OBJNR = AUFK~OBJNR
inner join AFIH
on AFIH~AUFNR = AUFK~AUFNR
where AUFK~PSPEL in SP$00002
and AFIH~ILART in SP$00001 .
select COEP~WOGBTR AFIH~ILART
from AUFK
inner join COEP
on COEP~OBJNR = AUFK~OBJNR
inner join AFIH
on AFIH~AUFNR = AUFK~AUFNR
where AUFK~PSPEL in SP$00002
and AFIH~ILART in SP$00001 .
Du bist doch der Einzige, der alle Daten sieht und alle Datensätze mit diesen drei fehlenden Vergleichen kann.Prego hat geschrieben:Super, darauf wär ich jetzt nie gekommen.
klar kann ich den nehmen. Nur warum soll ich hunderte Felder selektieren, wenn ich nur 2 brauch und dadurch die Summierung je Instandhaltungleistungsart bereits includiert habe. Ich knall dann halt den Speicher zu, wenn das in der Massenverarbeitungs läuft. Außerdem muß es ja eine Ursache geben, dass, sobald ich eine Feldeinschränkung mache, 3 Sätze nicht gezogen werden. Das ihr die Daten nicht kennt und dies nicht unbedingt debuggen könnt, ist mir auch klar. Manchmal liegt es aber an den einfachsten Dingen, die man selbst nicht sieht.
Das Problem liegt glaube ich an dem "FOR ALL ENTRIES". Wenn ich diese Werte nicht in eine normale interne Tabelle schreibe, sondern mir damit eine Select-Options Tabelle aufbaue und wie folgt selektiere funktioniert es. Es liegt also nicht an dem Join an sich. Warum der Select mit "SELECT-OPTION" anders reagiert als mit "FOR ALL ENTRIES", kann ich nicht sagen
[code]
data: begin of it_proj OCCURS 0,
SIGN(1) type c,
OPTION(2) type c,
LOW type string,
HIGH type string,
end of it_proj.
...
...
...
SELECT b~ilart c~wogbtr
INTO CORRESPONDING FIELDS OF wa_zinstand
FROM aufk as a INNER JOIN afih as b
ON a~aufnr = b~aufnr
INNER JOIN coep as c
ON a~objnr = c~objnr
WHERE a~pspel in it_proj
AND ( b~ilart EQ 'ZAI'
OR b~ilart EQ 'ZGA' ).[/code]
Den COLLECT verwende ich, da ich die Beträge in Objektwährung je Instandleistungsart aufsummieren möchte.
[code]
data: begin of it_proj OCCURS 0,
SIGN(1) type c,
OPTION(2) type c,
LOW type string,
HIGH type string,
end of it_proj.
...
...
...
SELECT b~ilart c~wogbtr
INTO CORRESPONDING FIELDS OF wa_zinstand
FROM aufk as a INNER JOIN afih as b
ON a~aufnr = b~aufnr
INNER JOIN coep as c
ON a~objnr = c~objnr
WHERE a~pspel in it_proj
AND ( b~ilart EQ 'ZAI'
OR b~ilart EQ 'ZGA' ).[/code]
Den COLLECT verwende ich, da ich die Beträge in Objektwährung je Instandleistungsart aufsummieren möchte.
Beitrag
von a-dead-trousers (Top Expert / 4457 / 227 /
1198
)
»
hi!
Schimpft mich jetzt bitte nicht aus wenns nicht so ist:
Kann es sein, dass bei SELECT-OPTIONS vorher noch ein CONVERT der Daten durchgeführt wird und bei FOR ALL ENTRIES mit den tatsächlichen Werten gearbeitet wird. Ich denke da jetzt an ==ALPHA usw. der ja bei Zahlen diese rechtsbündig mit führenden Nullen usw. speichert und das auch bei CHAR Feldern. Wenn man das dann nicht berücksichtigt findet man den Wert '1' nicht weil er intern als '0001' gespeichert wurde. Dieses Verhalten wird ja z.B. bei der SE16 berücksichtigt.
lg ADT
Schimpft mich jetzt bitte nicht aus wenns nicht so ist:
Kann es sein, dass bei SELECT-OPTIONS vorher noch ein CONVERT der Daten durchgeführt wird und bei FOR ALL ENTRIES mit den tatsächlichen Werten gearbeitet wird. Ich denke da jetzt an ==ALPHA usw. der ja bei Zahlen diese rechtsbündig mit führenden Nullen usw. speichert und das auch bei CHAR Feldern. Wenn man das dann nicht berücksichtigt findet man den Wert '1' nicht weil er intern als '0001' gespeichert wurde. Dieses Verhalten wird ja z.B. bei der SE16 berücksichtigt.
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
Nö, damit kann es eigentlich nichts zu tun haben, er hat ja Daten gefunden, nur eben 3 Sätze zu wenig. Allerdings hatten diese die identischen PSPelement und Auftragsnummern wie die, die gefunden wurden. Das ganze ist ziemlich undurchsichtig. Aber jetzt funktioniert es ja. Danke für Eure Hilfe.
Vergleichbare Themen
3
Antw.
Antw.
2245
Views
Views
0
Antw.
Antw.
1117
Views
Views
ATC-Browser Eclipse: Ausfiltern von Ergebnissen
von ralf.wenzel » 13.05.2020 06:59 • Verfasst in ABAP® Core
von ralf.wenzel » 13.05.2020 06:59 • Verfasst in ABAP® Core
1
Antw.
Antw.
4913
Views
Views
Exportieren der Ergebnissen einer View
von Fenghuang » 31.08.2020 08:25 • Verfasst in SAP HANA für Anfänger
von Fenghuang » 31.08.2020 08:25 • Verfasst in SAP HANA für Anfänger
3
Antw.
Antw.
2928
Views
Views
Parameter für maximale Anzahl an Ergebnissen (like se16n)
von Mockingbird » 19.03.2020 12:49 • Verfasst in ABAP® Core
von Mockingbird » 19.03.2020 12:49 • Verfasst in ABAP® Core
4
Antw.
Antw.
2334
Views
Views
Selektionen von unterschiedlichen matnr
von Gottschall » 13.02.2014 19:04 • Verfasst in ABAP® für Anfänger
von Gottschall » 13.02.2014 19:04 • 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.