Brauche Hilfe für Datenbankabfrage mit InnerJoin
Hallo zusammen,
folgenden Datenbankabfrage habe ich erstellt und finde diese auch richtig.
SAP meldet bei der Programmprüfung allerdings : Falscher Ausdruck "Inner" in from Klausel.
Weiß jemand was an der Abfrage falsch ist und wie ich sie gegebenenfalls umstellen kann.
Vielen Dank
SELECT v~vbeln m~matnr v~kwmeng v~lgort v~netwr
INTO CORRESPONDING FIELDS OF TABLE itab_promo
FROM (
vbak as k INNER JOIN
vbap AS v INNER JOIN
mvke AS m )
ON k~vbeln = v~vbeln
v~matnr = m~matnr
WHERE k~erdat IN s_erdat "Sekundärindex ERD
AND m~vmsta = 'SO'.
folgenden Datenbankabfrage habe ich erstellt und finde diese auch richtig.
SAP meldet bei der Programmprüfung allerdings : Falscher Ausdruck "Inner" in from Klausel.
Weiß jemand was an der Abfrage falsch ist und wie ich sie gegebenenfalls umstellen kann.
Vielen Dank
SELECT v~vbeln m~matnr v~kwmeng v~lgort v~netwr
INTO CORRESPONDING FIELDS OF TABLE itab_promo
FROM (
vbak as k INNER JOIN
vbap AS v INNER JOIN
mvke AS m )
ON k~vbeln = v~vbeln
v~matnr = m~matnr
WHERE k~erdat IN s_erdat "Sekundärindex ERD
AND m~vmsta = 'SO'.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathGuardian (Expert / 759 / 0 /
3
)
»
Probiers mal so:
Bei Joins gehts immer so:
Join-On-Join-On-Join-On....
P.s. das "INNER" musst du nicht angeben.
Code: Alles auswählen.
SELECT v~vbeln m~matnr v~kwmeng v~lgort v~netwr
INTO CORRESPONDING FIELDS OF TABLE itab_promo
FROM vbak as k
JOIN vbap AS v
ON k~vbeln = v~vbeln
JOIN mvke AS m
ON v~matnr = m~matnr
WHERE k~erdat IN s_erdat "Sekundärindex ERD
AND m~vmsta = 'SO'Join-On-Join-On-Join-On....
P.s. das "INNER" musst du nicht angeben.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Warum?babap hat geschrieben:Ich würde ja für sowas spontan eine View anlegen und benutzen.
Wäre das in diesem Fall nicht auch praktischer?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
(du fragst gerne warum, gell??)
weil es, wenn es den gleichen Zweck erfüllt, viel praktischer und übersichtlicher ist als das Rumgewurschtel mit den Tilden, Buchstaben, Tabellennamen, Feldnamen und Vergleichsoperationen ...
Und weil ich sie dann an vielen Stellen mit dem gleichen Ergebnis wiederverwenden kann!
Gruß
babap
(du fragst gerne warum, gell??)
weil es, wenn es den gleichen Zweck erfüllt, viel praktischer und übersichtlicher ist als das Rumgewurschtel mit den Tilden, Buchstaben, Tabellennamen, Feldnamen und Vergleichsoperationen ...
Und weil ich sie dann an vielen Stellen mit dem gleichen Ergebnis wiederverwenden kann!
Gruß
babap
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Der OP machte nicht den Eindruck als wenn er das häufiger braucht und nur in dem Falle hast du Recht. Wenn ich für jeden komplexen Join eine View im DDIC anlegen würde, hätten mich meine Kunden schon zu Recht vor die Tür gesetzt, weil ich schätzungsweise jeden dritten select so schreibe.babap hat geschrieben:Und weil ich sie dann an vielen Stellen mit dem gleichen Ergebnis wiederverwenden kann!
Das mag ja gehen bei Kunden, die fünf eigene Reports in ihrem System haben, ich arbeite für Kunden, die ganze Module und Branchenlösungen programmieren, und da sind DDIC-Elemente genehmigungspflichtig.
In diesem Falle bleibt man dann doch lieber bei der View....
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
jetzt könne wir über Programmiergrundsätze und Kundenbeschränkungen diskutieren ...
Ich schreibe selbst ganze Module, Add-Ons etc.
Wenn mir der Kunde dabei vorschreiben will, wieviele und welche DDIC-Objekte ich benutze, kann er das selber machen ...
Achtung: Sarkasmus, Polemik, Ironie!!!
Lauter verwurschtelte Select-Joins ...
Das sichert Arbeitsplätze. Nämlich den, der es programmiert hat (bis er's nicht mehr blickt) und den Arbeitsplatz für den, der es neu machen muß (meiner!!).
Da lob' ich mir ein paar DDIC-Objekte mehr, für jeden sichtbar, als hunderte verwurschtelte Select-Joins an hundert stellen.
Achtung: Technik!
Die Datenbankview macht "hintenrum" auch bloß Join-on-join-on where ...
Und ich kann schon mit der SE16 oder SE16n nachssehen, was dabei rauskommt !! (Und ich kann sie in einer Suchhilfe benutzen und an vielen anderen stellen und und und).
Gruß
babap
jetzt könne wir über Programmiergrundsätze und Kundenbeschränkungen diskutieren ...
Ich schreibe selbst ganze Module, Add-Ons etc.
Wenn mir der Kunde dabei vorschreiben will, wieviele und welche DDIC-Objekte ich benutze, kann er das selber machen ...
Achtung: Sarkasmus, Polemik, Ironie!!!
Lauter verwurschtelte Select-Joins ...
Das sichert Arbeitsplätze. Nämlich den, der es programmiert hat (bis er's nicht mehr blickt) und den Arbeitsplatz für den, der es neu machen muß (meiner!!).
Da lob' ich mir ein paar DDIC-Objekte mehr, für jeden sichtbar, als hunderte verwurschtelte Select-Joins an hundert stellen.
Achtung: Technik!
Die Datenbankview macht "hintenrum" auch bloß Join-on-join-on where ...
Und ich kann schon mit der SE16 oder SE16n nachssehen, was dabei rauskommt !! (Und ich kann sie in einer Suchhilfe benutzen und an vielen anderen stellen und und und).
Gruß
babap
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Gegenargument: Wenn jeder wie wild Objekte anlegt, wer will da noch durchsteigen? Der Kunde muss das Teil ja mal in Wartung und Betrieb übernehmen.babap hat geschrieben:Ich schreibe selbst ganze Module, Add-Ons etc.
Wenn mir der Kunde dabei vorschreiben will, wieviele und welche DDIC-Objekte ich benutze, kann er das selber machen ...
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
Und es geht hier ja nicht um eine "Nur mal eben"-Programmierung.
Z.B. selbst für interne Tabellen im Programm lege ich lieber einen Typ an. Dann habe ich immer die gleiche Tabelle und wenn da mal ein Feld hinzgefügt wird, ist es "schwupps" überall gleichzeitig drin. Ist doch phantastisch!
Irgendwie muß man doch den Nutzen, der in der ABAP-Entwicklungsumgebung steckt auch anwenden. (Sonst könnte man ja gleich JAVA machen ...)
Bei einen kleinen Projekt habe ich locker 50-100 DDIC-Objekte. Wenn ich da über jedes Ding diskutiere dauert es locker doppelt so lange. Und wenn ich das nicht korrekt machen kann (so wie ich meine, daß es korrekt ist), dauert es eben 3-mal so lange. (Wo soll ich auch Nachts um 23:00 Uhr anrufen, um mir ein DDIC-Objekt genehmigen zu lassen????)
I.d.R. bekomme ich (nach einem guten Vorschlag) den "Freibrief" für meine Arbeit, oder gar die Verwaltung der Entwicklungsobjekte für das Projekt übertragen.
Ich denke, der Kunde hat Anspruch auf eine sauber strukturierte, übersichtliche Entwicklungsarbeit.
Gruß
babap
erstens nicht JEDER, zweitens nur ICH, und gerade WEIL der Kunde Wartung und Betrieb übernehmen soll, mache ich das so.ralf.wenzel hat geschrieben:...
Gegenargument: Wenn jeder wie wild Objekte anlegt, wer will da noch durchsteigen? Der Kunde muss das Teil ja mal in Wartung und Betrieb übernehmen.
...
Und es geht hier ja nicht um eine "Nur mal eben"-Programmierung.
Z.B. selbst für interne Tabellen im Programm lege ich lieber einen Typ an. Dann habe ich immer die gleiche Tabelle und wenn da mal ein Feld hinzgefügt wird, ist es "schwupps" überall gleichzeitig drin. Ist doch phantastisch!
Irgendwie muß man doch den Nutzen, der in der ABAP-Entwicklungsumgebung steckt auch anwenden. (Sonst könnte man ja gleich JAVA machen ...)
Bei einen kleinen Projekt habe ich locker 50-100 DDIC-Objekte. Wenn ich da über jedes Ding diskutiere dauert es locker doppelt so lange. Und wenn ich das nicht korrekt machen kann (so wie ich meine, daß es korrekt ist), dauert es eben 3-mal so lange. (Wo soll ich auch Nachts um 23:00 Uhr anrufen, um mir ein DDIC-Objekt genehmigen zu lassen????)
I.d.R. bekomme ich (nach einem guten Vorschlag) den "Freibrief" für meine Arbeit, oder gar die Verwaltung der Entwicklungsobjekte für das Projekt übertragen.
Ich denke, der Kunde hat Anspruch auf eine sauber strukturierte, übersichtliche Entwicklungsarbeit.
Gruß
babap
Beitrag
von DeathGuardian (Expert / 759 / 0 /
3
)
»
Spätestens wenn du an einem System hockst, wo über 10000 DDIC-Strukturen alleine mit "Z" beginnend vorhanden sind und auf Grund der Unübersichtlichkeit dieser Masse bemerkst, das einige Doppelt und Dreifach vorhanden sind, wird man nicht mehr davon überzeugt sein, das es gut ist "kleinigkeiten" ins DDIC zu verfrachten.
Desweiteren kosten DDIC-Strukturen Plattenplatz (Auch wenns heutzutage nemmer so das Problem ist).
Ausserdem einige Kunden hassen es wegen sowas andauernd vom Coding ins DDic zu springen. Und ich bin sowohl Kunde als auch Entwickler.(Haben genug SAPler wegen Grossprojekte hier, die ich mitunter dann später an der Packe hab zum Weiterentwieckeln.)
Also:
Solange ich weis, das es nicht von mehreren Programmen genutzt werden kann, mach ich sowas lieber lokal im Programm.
Desweiteren kosten DDIC-Strukturen Plattenplatz (Auch wenns heutzutage nemmer so das Problem ist).
Ausserdem einige Kunden hassen es wegen sowas andauernd vom Coding ins DDic zu springen. Und ich bin sowohl Kunde als auch Entwickler.(Haben genug SAPler wegen Grossprojekte hier, die ich mitunter dann später an der Packe hab zum Weiterentwieckeln.)
Also:
Solange ich weis, das es nicht von mehreren Programmen genutzt werden kann, mach ich sowas lieber lokal im Programm.
Hallo,
SAP hat mehr als 10.000 Objekte und das mit allen Buchstaben.
Die haben das DDIC erfunden, um überhaupt irgendwie klarzukommen.
Zur Strukturierung dienen die Pakete (ehemals Entwicklungsklassen).
Kleine Namenskonvention, kleine Systematik bei Paketen und Unterpaketen und schon ist das ganze einfach und übersichtlich.
Wer sich damit nicht beschäftigen kann oder will ...
(... nee, ich muß nicht weiter drüber nachdenken oder schreiben ...)
Gruß
babap
SAP hat mehr als 10.000 Objekte und das mit allen Buchstaben.
Die haben das DDIC erfunden, um überhaupt irgendwie klarzukommen.
Zur Strukturierung dienen die Pakete (ehemals Entwicklungsklassen).
Kleine Namenskonvention, kleine Systematik bei Paketen und Unterpaketen und schon ist das ganze einfach und übersichtlich.
Wer sich damit nicht beschäftigen kann oder will ...
(... nee, ich muß nicht weiter drüber nachdenken oder schreiben ...)
Gruß
babap
Beitrag
von DeathGuardian (Expert / 759 / 0 /
3
)
»
Wirklich!babap hat geschrieben:Zur Strukturierung dienen die Pakete (ehemals Entwicklungsklassen).
Kleine Namenskonvention, kleine Systematik bei Paketen und Unterpaketen und schon ist das ganze einfach und übersichtlich.
Wer sich damit nicht beschäftigen kann oder will ...
OH, JA!
Das Problem ist nur:
Bring das mal allen bei die in einem System etwas entwickeln!
Bei ca 300 Entwicklern(Interne) + 50 Externen Entwicklern die bei jeden Projekt wechseln(sprich andere Personen) ist das nicht mehr so einfach da auf Dauer im DDIC eine klare Struktur beizuhalten.(Vorallem dank den wechselden Externen die gerne auf unsere Namenskonventionen im warsten Sinne des Wortes scheissen)
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Eben. Darum gibt es Abnahmeprozesse und Regeln, die selbigen zugrunde liegen, zum Beispiel die, dass DDIC-Objekte genehmigungspflichtig sind.DeathGuardian hat geschrieben:(Vorallem dank den wechselden Externen die gerne auf unsere Namenskonventionen im warsten Sinne des Wortes scheissen)
Externe Dienstleister, die sich daran nicht halten. werden konsequent vor die Tür gesetzt, da kann babap schreien wie er will. Er will ans Geld der Kunden, also muss er sich an deren Regeln halten.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4090 / 127 /
940
)
»
Die Diskussion ist doch müßig.
Hat halt jeder seinen eigenen Stil. Und sich kategorisch auf die eine oder andere Weise festzulegen halte ich sowieso für nicht grade hilfreich. Die Situation ( programmtechnisch oder auch vorgabetechnisch vom Kunden gegeben) kann sowohl die eine als auch die andere Methode bevorzugen.
Ein Programm kann man in jedem der beiden oben angesprochenen Stile schreiben. Ob es nachher lesbar ist hängt dann eher vom Autor ab und nicht für welchen Stil er sich entscheidet.
Und was Abnahmeprozesse, Richtlinien etc. angeht. Das macht doch jeder Kunde anders.
Vielleicht solltet ihr mal drüber nachdenken, dass der jeweils andere evtl. in einem anderen Umfeld arbeitet als ihr es gewohnt seid.
Ich zumindest war sowohl bei Kunden mit sehr rigiden Vorschriften als auch bei solchen mit de facto gar keinen.
Hat halt jeder seinen eigenen Stil. Und sich kategorisch auf die eine oder andere Weise festzulegen halte ich sowieso für nicht grade hilfreich. Die Situation ( programmtechnisch oder auch vorgabetechnisch vom Kunden gegeben) kann sowohl die eine als auch die andere Methode bevorzugen.
Ein Programm kann man in jedem der beiden oben angesprochenen Stile schreiben. Ob es nachher lesbar ist hängt dann eher vom Autor ab und nicht für welchen Stil er sich entscheidet.
Und was Abnahmeprozesse, Richtlinien etc. angeht. Das macht doch jeder Kunde anders.
Vielleicht solltet ihr mal drüber nachdenken, dass der jeweils andere evtl. in einem anderen Umfeld arbeitet als ihr es gewohnt seid.
Ich zumindest war sowohl bei Kunden mit sehr rigiden Vorschriften als auch bei solchen mit de facto gar keinen.
Vergleichbare Themen
5
Antw.
Antw.
1915
Views
Views
25
Antw.
Antw.
11870
Views
Views
Brauche HIlfe beim Coding :( Anfänger....
von Trulchen » 03.09.2012 15:50 • Verfasst in ABAP Objects®
von Trulchen » 03.09.2012 15:50 • Verfasst in ABAP Objects®
4
Antw.
Antw.
2757
Views
Views
Brauche Hilfe zu Update nach Join in ITAB
von laola » 23.07.2008 16:42 • Verfasst in ABAP® für Anfänger
von laola » 23.07.2008 16:42 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
2995
Views
Views
Warum bleibt Spalte leer? Select innerjoin
von c oco » 06.12.2012 09:11 • Verfasst in ABAP® für Anfänger
von c oco » 06.12.2012 09:11 • 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.