Schleifenwert Ignorieren
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.hi,
ich hab folgendes Problem,
LG erzo
ich hab folgendes Problem,
Code: Alles auswählen.
loop at .. into ..
* Selection von Geschlecht
select single ... into ls_ausgabe-gschl
from ...
IF p_gmann = 'X' AND ls_ausgabe-gschl = 1.
ls_ausgabe-gschl = 'M'.
ELSEIF p_gmann = '' AND ls_ausgabe-gschl = 1.
CONTINUE.
ENDIF.
* Problem ist der Wert, wenn er auf 'M' gesetzt wird, wird dieser weiter bei der nächsten IF Abfrage genutzt wie kann ich das verhindern ?
IF p_gfrau = 'X' AND ls_ausgabe-gschl = 2.
ls_ausgabe-gschl = 'W'.
ELSEIF p_gfrau = '' AND ls_ausgabe-gschl = 2.
CONTINUE.
ENDIF.
IF p_gunb = 'X' AND ls_ausgabe-gschl = 3.
ls_ausgabe-gschl = 'U'.
ELSEIF p_gunb = '' AND ls_ausgabe-gschl = 3.
CONTINUE.
ENDIF.
endloop.
_________________________________________________________________________________
Gruß Özgür
Gruß Özgür
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von JohnLocklay (Specialist / 183 / 30 /
2
)
»
Kombiniere beide If Anweisungen
und setze die 2. Anweisung mit ELSEIF ein.
oder frag den wert mit einer Caseanweisung ab.
was noch geht.. mach einfach 3 seperate loops..
zudem würde ich Dir empfehlen
die select anweisung anders aufzubauen.
SELECT SINGLE * FROM db_tab INTO wa
und setze die 2. Anweisung mit ELSEIF ein.
oder frag den wert mit einer Caseanweisung ab.
was noch geht.. mach einfach 3 seperate loops..
zudem würde ich Dir empfehlen
die select anweisung anders aufzubauen.
SELECT SINGLE * FROM db_tab INTO wa
Folgende Benutzer bedankten sich beim Autor JohnLocklay für den Beitrag:
erzoo24
Code once - Think twice
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Warum?JohnLocklay hat geschrieben:SELECT SINGLE * FROM db_tab INTO wa
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
DeathAndPain
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Was bringt es?JohnLocklay hat geschrieben:nicht?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von JohnLocklay (Specialist / 183 / 30 /
2
)
»
habs so gelernt. aber das andere geht auch. okeee..
Code once - Think twice
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Im ursprünglichen (Native-)SQL der alten Schule MUSSTE das INTO vor dem FROM stehen. (Jedenfalls war das bei Informix so; keine Ahnung, ob die anderne Datenbankhersteller das damals auch so eng gesehen haben.) Als ich das damals gelernt habe, fand ich es auch sonderbar, habe mich aber schnell dran gewöhnt. Ich fand es angenehm, dass ABAP diese dort zwar weniger gebräuchliche, aber eigentlich klassischere Schreibweise auch akzeptiert, da ich mich so nicht umstellen musste.
Nebenbei kann ich so auf einen Blick erkennen, welcher SELECT von mir ist und welchen jemand anderes da reingepfuschelt hat.
Was die originale Fragestellung angeht, so finde ich diese insofern recht unklar, als dass dort kein geänderter Wert in einem weiteren IF-Statement verwurstet wird. Im übrigen finde ich diesen Ketten-IF schon ziemlich schrecklich programmiert. CASE wäre das mindeste, was man da machen sollte. Bei einem Release ab 7.40 sollte der Code völlig anders aussehen; da geht das noch erheblich schöner.
Nebenbei kann ich so auf einen Blick erkennen, welcher SELECT von mir ist und welchen jemand anderes da reingepfuschelt hat.
Was die originale Fragestellung angeht, so finde ich diese insofern recht unklar, als dass dort kein geänderter Wert in einem weiteren IF-Statement verwurstet wird. Im übrigen finde ich diesen Ketten-IF schon ziemlich schrecklich programmiert. CASE wäre das mindeste, was man da machen sollte. Bei einem Release ab 7.40 sollte der Code völlig anders aussehen; da geht das noch erheblich schöner.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Willst du etwa schon wieder Streit anfangen?DeathAndPain hat geschrieben:Bei einem Release ab 7.40 sollte der Code völlig anders aussehen; da geht das noch erheblich schöner.
Ralf *stimmt der Aussage komplett zu
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ich hatte es letztens tatsächlich, dass auf einem System im Quickviewer SQVI die Anweisung SELECT FROM INTO nicht akzeptiert wurde.
Es gab immer eine Fehlermeldung. Erst nach Umstellung auf SELECT INTO FROM funktionierte es.
Habe leider keine Lust und Zeit mehr gehabt, dem genauer auf den Grund zu gehen.
Ich finde aber auch SELECT FROM INTO sinnvoller...
Es gab immer eine Fehlermeldung. Erst nach Umstellung auf SELECT INTO FROM funktionierte es.
Habe leider keine Lust und Zeit mehr gehabt, dem genauer auf den Grund zu gehen.
Ich finde aber auch SELECT FROM INTO sinnvoller...
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Ich auch - weil das der Logik entspricht - "lies etwas VON da NACH da". Andersrum klingt das in meinem Ohr falsch. Ich sag meinem Sohn ja auch nicht "Bring mal die Pumpe in den Garten aus dem Keller".
Auf der anderen Seite steht bei der anderen Variante das FROM näher beim WHERE und das WHERE bezieht sich ja auf die Tabelle(n) im FROM.
Ralf
Auf der anderen Seite steht bei der anderen Variante das FROM näher beim WHERE und das WHERE bezieht sich ja auf die Tabelle(n) im FROM.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Es hat auch Vorteile, wenn man Felder einzeln aufzählt:
Hier wäre die Zuordnung von Datenbankfeld zu internem Feld schwerer zu lesen, wenn das "FROM PA0001" in der Mitte stehen würde. Und nun stelle man sich vor, der FROM-Bereich ist noch durch diverse JOINs aufgeblasen, wodurch er auch mal 20 Zeilen lang werden kann. Oben am Anfang die acht zu lesenden Felder, und 20 Zeilen später unter dem FROM/JOIN-Block dann die Zielfelder, in die sie übertragen werden sollen.
In diese Probleme laufe ich nicht, wenn ich meine Reihenfolge beibehalte. Genauso macht es auch Sinn, den JOIN-Block und den WHERE-Block zusammenzuhalten und nicht die Zielfeldliste dazwischenzuquetschen, denn JOIN-Block und WHERE-Block bilden ja gemeinsam das effektive Selektionskriterium. Das geht so weit, dass man sich bei vielen Vergleichen nach kosmetischen Überlegungen aussuchen kann, ob man sie bei JOIN oder bei WHERE reinschreiben möchte, da es logisch keinen Unterschied macht.
Je länger ich darüber nachdenke, desto mehr gelange ich zu der Überzeugung, dass die alte Notation die bessere ist.
Code: Alles auswählen.
SELECT PERNR WERKS BTRTL INTO (PERSONALNUMMER,PERSONALBEREICH,PERSONALTEILBEREICH) FROM PA0001
WHERE SACHP = '100'.In diese Probleme laufe ich nicht, wenn ich meine Reihenfolge beibehalte. Genauso macht es auch Sinn, den JOIN-Block und den WHERE-Block zusammenzuhalten und nicht die Zielfeldliste dazwischenzuquetschen, denn JOIN-Block und WHERE-Block bilden ja gemeinsam das effektive Selektionskriterium. Das geht so weit, dass man sich bei vielen Vergleichen nach kosmetischen Überlegungen aussuchen kann, ob man sie bei JOIN oder bei WHERE reinschreiben möchte, da es logisch keinen Unterschied macht.
Je länger ich darüber nachdenke, desto mehr gelange ich zu der Überzeugung, dass die alte Notation die bessere ist.
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Da halte ich mich raus - ich habe meinen letzten SELECT geschrieben vor fast zwei Jahren... Der letzte JOIN ist noch länger her.
Ralf
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Immer diese Highlevel-Experten ohne Praxisbezug...
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Das ist ganz interessant, darum führe ich das mal aus: Ich hatte mehrere Kunden, die (nach verschiedenen Konzepten) eine teil-generische Persistenzschicht verwenden (und so einen hab ich jetzt halt auch). Da darf (!) man dann keine SELECTs mehr schreiben, sondern kriegt die Daten von einer Methode gestellt.DeathAndPain hat geschrieben:Immer diese Highlevel-Experten ohne Praxisbezug...
Statt eines SELECT schreibt man einen Einzeiler, etwa in der Art RES = MDL->READ( seldat ), wobei RES die Ergebnismenge ist, MDL die entsprechende Modelklasse für die Tabelle und seldat eine Struktur oder Tabelle, die verschiedene Formen haben kann. Ein oder mehrere Felder dieser Struktur könnte z. B. eine Rangetabelle vom Typ des Feldes sein. Die Klasse muss dann natürlich per RTTI feststellen, was da übergeben wurde und so.
Ganz unten drunter liegt eine Basisklasse, die ein
Code: Alles auswählen.
select *
from (me->tablename)
into corresponding fields of table db_data
where (me->wheretab).Das hat gleich mehrere Vorteile. Insbesondere muss man sich keine Gedanken machen, welche DB unter dem System liegt. Wechselt man auf HANA, schreibt man die Persistenzschicht (auf der entsprechend sinnvollen Ebene) neu und hat schöne, HANA-optimierte Zugriffe mit wenig Aufwand und ohne Testerei.
So kriegt man die Geschäftsobjekte komplett von der Persistenzschicht entkoppelt. Eine Arbeitsweise, die ich in einem Projekt gelernt habe und die mir ausgesprochen gut gefällt. Ist natürlich einmal ein bisschen Arbeit, aber die Entkoppelung ist ein Wert in sich und es erspart auch Arbeit in der laufenden Programmierung, insbesondere durch Wiederverwendung. Oder weil ich die Texte (sofern vorhanden) frei Haus mitgeliefert kriege.
Warum kein BOPF? Einige Kunden kennen es zu wenig, andere Entwicklungen sind schlichtweg älter als das BOPF.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ich schreibs auch schon immer so ^^.DeathAndPain hat geschrieben:Im ursprünglichen (Native-)SQL der alten Schule MUSSTE das INTO vor dem FROM stehen. (Jedenfalls war das bei Informix so; keine Ahnung, ob die anderne Datenbankhersteller das damals auch so eng gesehen haben.) Als ich das damals gelernt habe, fand ich es auch sonderbar, habe mich aber schnell dran gewöhnt. Ich fand es angenehm, dass ABAP diese dort zwar weniger gebräuchliche, aber eigentlich klassischere Schreibweise auch akzeptiert, da ich mich so nicht umstellen musste.
Nebenbei kann ich so auf einen Blick erkennen, welcher SELECT von mir ist und welchen jemand anderes da reingepfuschelt hat.
Was die originale Fragestellung angeht, so finde ich diese insofern recht unklar, als dass dort kein geänderter Wert in einem weiteren IF-Statement verwurstet wird. Im übrigen finde ich diesen Ketten-IF schon ziemlich schrecklich programmiert. CASE wäre das mindeste, was man da machen sollte. Bei einem Release ab 7.40 sollte der Code völlig anders aussehen; da geht das noch erheblich schöner.
"Code lügt nicht ^^"
Vergleichbare Themen
2
Antw.
Antw.
1227
Views
Views
Arbeitsbereiche vergleichen und Felder ignorieren
von Assassin » 22.08.2008 09:11 • Verfasst in ABAP® für Anfänger
von Assassin » 22.08.2008 09:11 • Verfasst in ABAP® für Anfänger
2
Antw.
Antw.
1759
Views
Views
Im if-Teil Groß- und Kleinschreibung ignorieren
von kaim77 » 13.08.2014 11:15 • Verfasst in ABAP® Core
von kaim77 » 13.08.2014 11:15 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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.