Buchungsnummer in DB sflight,spfli,sbook ausgeben.
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
Hallo,
im zuge einer Einschulung haben wir folgendes Programm zu schreiben begonnen und ich soll nun die Bookid zu den einzelnen Flügen ausgeben. (Nebenbei wäre noch gut wenn die Parameters (carrid und carr2 tagsächlich die Fluglinien eingrenzen würden :D)
Ich schaffe die Bookid abfrage, jedoch ist die ausgabe immer ganz unten und funktioniert oder wenn ich sie weiter oben in ein Unterprogramm einfüge gibt die Ausgabe/Abfrage 000000 aus.
Wäre nett wenn mir jemand sagen könnte wo und vorallem wieso/warum das passiert.
im zuge einer Einschulung haben wir folgendes Programm zu schreiben begonnen und ich soll nun die Bookid zu den einzelnen Flügen ausgeben. (Nebenbei wäre noch gut wenn die Parameters (carrid und carr2 tagsächlich die Fluglinien eingrenzen würden :D)
Ich schaffe die Bookid abfrage, jedoch ist die ausgabe immer ganz unten und funktioniert oder wenn ich sie weiter oben in ein Unterprogramm einfüge gibt die Ausgabe/Abfrage 000000 aus.
Wäre nett wenn mir jemand sagen könnte wo und vorallem wieso/warum das passiert.
Code: Alles auswählen.
PARAMETERS P_carrid TYPE sflight-carrid.
PARAMETERS p_carr2 TYPE sflight-carrid.
DATA: lt_einzelfluege TYPE TABLE OF sflight.
DATA: ls_flugverbindungen TYPE spfli.
DATA: ls_einzelfluege TYPE sflight.
DATA: ls_buchung TYPE sbook.
DATA: lt_buchung TYPE TABLE OF sbook.
START-OF-SELECTION.
DATA: lt_flugverbindungen TYPE TABLE OF spfli.
DATA: lt_fluege TYPE TABLE OF spfli.
DATA: lv_ergebnis TYPE i.
SELECT * FROM spfli INTO TABLE lt_flugverbindungen.
PERFORM ausgabe_flugverbindungen USING lt_flugverbindungen.
SELECT * FROM sbook INTO TABLE lt_buchung
WHERE carrid = p_carrid.
PERFORM bookid USING lt_buchung.
FORM ausgabe_flugverbindungen USING pt_flugverbindungen LIKE lt_flugverbindungen.
DATA: lt_einzelfluege TYPE TABLE OF sflight.
DATA: ls_flugverbindungen TYPE spfli.
DATA: ls_einzelfluege TYPE sflight.
LOOP AT pt_flugverbindungen INTO ls_flugverbindungen.
SELECT * FROM sflight INTO TABLE lt_einzelfluege
WHERE carrid = ls_flugverbindungen-carrid
AND connid = ls_flugverbindungen-connid.
PERFORM ausgabe_flugverbindung USING ls_flugverbindungen.
LOOP AT lt_einzelfluege INTO ls_einzelfluege.
PERFORM ausgabe_einzelflug USING ls_einzelfluege.
ENDLOOP.
ENDLOOP.
ENDFORM.
FORM ausgabe_flugverbindung USING ps_flugverbindungen TYPE spfli.
WRITE: / 'Flugverbindung:'.
WRITE: / ' ', ps_flugverbindungen-carrid, ps_flugverbindungen-connid.
ENDFORM.
FORM ausgabe_einzelflug USING ps_einzelfluege TYPE sflight.
WRITE : / 'Einzelflug'.
WRITE : / ' ',ps_einzelfluege-carrid, ps_einzelfluege-connid,
ps_einzelfluege-fldate.
WRITE: / ' ','Preis' ,ps_einzelfluege-price.
WRITE: / ' ','Seatsmax', ps_einzelfluege-seatsmax.
ULINE.
"perform berechne offene_plätze using ps_einzelfluege changig lv_anzahl_frei
"write: / ' ','Offene Plätze', lv_anzahl_frei
ENDFORM.
FORM substraktion USING p_nummer1 TYPE i p_nummer2 TYPE i CHANGING ergebnis TYPE i.
ergebnis = p_nummer1 - p_nummer2.
ENDFORM.
FORM bookid USING ps_buchung LIKE lt_buchung.
LOOP AT lt_buchung INTO ls_buchung.
WRITE: ' ', 'Buchungsnummer'.
WRITE: / ls_buchung-bookid.
ENDLOOP.
ENDFORM.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi,
Warum dies 2 mal?
PARAMETERS P_carrid TYPE sflight-carrid.
PARAMETERS p_carr2 TYPE sflight-carrid. --> wofür?
SELECT * FROM spfli INTO TABLE lt_flugverbindungen. --> fehlt da nicht ein where ... = P_carrid
SELECT * FROM sbook INTO TABLE lt_buchung --> direkt nach SELECT * FROM spfli
ggf. noch um ein Where .. in Table ...lt_flugverbindungen ergänzen
das hier verschieben
PERFORM bookid USING lt_buchung.
nach innerhalb des Loops nach PERFORM ausgabe_einzelflug USING ls_einzelfluege.
(PER)FORM bookid USING lt_buchung ergänzen um ls_einzelfluege
LOOP AT lt_buchung INTO ls_buchung ergänzen um where CARRID... CONNID...
FLDATE... mit EQ auf den Werten aus ls_einzelfluege
WRITE: ' ', 'Buchungsnummer'.
WRITE: / ls_buchung-bookid.
ENDLOOP.
Grundsätzliches:
Deine Nomenklatur ist gewöhnungsbedürftig LT..., LS... steht eigentlich für Lokal. Das sind aber alles globale Variablen.
Hier machst du eine Parameterübergabe, nutzt aber die globalen Variablen
FORM bookid USING ps_buchung LIKE lt_buchung.
LOOP AT lt_buchung INTO ls_buchung.
sollte eher so aussehen
FORM bookid USING pt_buchung LIKE gt_buchung.
Data ls_buchung type sbook.
LOOP AT pt_buchung INTO ls_buchung.
Warum dies 2 mal?
PARAMETERS P_carrid TYPE sflight-carrid.
PARAMETERS p_carr2 TYPE sflight-carrid. --> wofür?
SELECT * FROM spfli INTO TABLE lt_flugverbindungen. --> fehlt da nicht ein where ... = P_carrid
SELECT * FROM sbook INTO TABLE lt_buchung --> direkt nach SELECT * FROM spfli
ggf. noch um ein Where .. in Table ...lt_flugverbindungen ergänzen
das hier verschieben
PERFORM bookid USING lt_buchung.
nach innerhalb des Loops nach PERFORM ausgabe_einzelflug USING ls_einzelfluege.
(PER)FORM bookid USING lt_buchung ergänzen um ls_einzelfluege
LOOP AT lt_buchung INTO ls_buchung ergänzen um where CARRID... CONNID...
FLDATE... mit EQ auf den Werten aus ls_einzelfluege
WRITE: ' ', 'Buchungsnummer'.
WRITE: / ls_buchung-bookid.
ENDLOOP.
Grundsätzliches:
Deine Nomenklatur ist gewöhnungsbedürftig LT..., LS... steht eigentlich für Lokal. Das sind aber alles globale Variablen.
Hier machst du eine Parameterübergabe, nutzt aber die globalen Variablen
FORM bookid USING ps_buchung LIKE lt_buchung.
LOOP AT lt_buchung INTO ls_buchung.
sollte eher so aussehen
FORM bookid USING pt_buchung LIKE gt_buchung.
Data ls_buchung type sbook.
LOOP AT pt_buchung INTO ls_buchung.
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Hm. Ich verstehe die Frage nur bedingt. Die Abfrage und Ausgabe der bookid hat ja mit dem Rest des Programms gar nichts zu tun und sollte daher funktionieren, egal wo sie steht.
Ich habe aber auch noch dringende Anmerkungen an ocb:
PARAMETERS P_carrid TYPE sflight-carrid.
PARAMETERS p_carr2 TYPE sflight-carrid.
...
SELECT * FROM sbook INTO TABLE lt_buchung
WHERE carrid = p_carrid.
Damit würdest Du genau die Eingrenzungsmöglichkeit bekommen, die Du haben möchtest.
Ich habe aber auch noch dringende Anmerkungen an ocb:
- Hinter jedem DATA-Befehl hast Du einen Doppelpunkt geschrieben. Ist Dir bewusst, was dieser Doppelpunkt überhaupt bedeutet? Ist Dir klar, dass Du all diese Doppelpunkte (bei Deinen DATAs, nicht aber bei Deinen WRITEs) ersatzlos weglassen könntest, so wie Du Dein Programm geschrieben hast?
- Welchen Zweck verfolgt Deine FORM substraktion? Mal abgesehen davon, dass ihr Name falsch geschrieben ist und sie überhaupt nicht aufgerufen wird, kommt sie mir ausgesprochen sinnlos vor. ABAP hat einen Befehl SUBTRACT bereits eingebaut, der genau das tut, was Du mit Deiner Form nachprogrammiert hast.
- Ist Dir bewusst, was der Stern hinter Deinen SELECT-Befehlen bedeutet und dass Du dort besser die wenigen tatsächlich benötigten Spalten aufzählen solltest? (Kann natürlich sein, dass ihr noch nicht so weit seid in eurem Kurs.)
Dein carr2 ist vom Ansatz her falsch. Was Du da brauchst, ist kein Parameter, sondern eine SELECT-OPTION. Also(Nebenbei wäre noch gut wenn die Parameters (carrid und carr2 tagsächlich die Fluglinien eingrenzen würden :D)
PARAMETERS P_carrid TYPE sflight-carrid.
PARAMETERS p_carr2 TYPE sflight-carrid.
Code: Alles auswählen.
DATA dummy_carrid TYPE sflight-carrid. " Aus technischen Gründen notwendig. Dieses Feld brauchst Du später nicht mehr.
SELECT-OPTIONS s_carrid for dummy_carrid.SELECT * FROM sbook INTO TABLE lt_buchung
WHERE carrid = p_carrid.
Code: Alles auswählen.
SELECT * FROM sbook INTO TABLE lt_buchung
WHERE carrid IN s_carrid.Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
ocb
Danke für eure Antworten.
Zu meinem Verständnis von Doppelpunkten bei DATA: So wie ich das verstehe sind Doppelpunkte für Kettensätze. Da ich bei DATA keine verwende könnte ich sie weg lassen, finde die Formatierung aber mit den Doppelpunkten übersichtlich. Bei den Writes kann ich sie nicht weg lassen, da ich dort mehrere Dinge schreiben möchte.
* Sagt meines wissen aus das ALLE Spalten gelesen werden sollen, in meinem Fall würde bookid auslesen aber reichen, stimmt.
Zu meinem Verständnis von Doppelpunkten bei DATA: So wie ich das verstehe sind Doppelpunkte für Kettensätze. Da ich bei DATA keine verwende könnte ich sie weg lassen, finde die Formatierung aber mit den Doppelpunkten übersichtlich. Bei den Writes kann ich sie nicht weg lassen, da ich dort mehrere Dinge schreiben möchte.
* Sagt meines wissen aus das ALLE Spalten gelesen werden sollen, in meinem Fall würde bookid auslesen aber reichen, stimmt.
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Wirklich? Was bringen die?Zu meinem Verständnis von Doppelpunkten bei DATA: So wie ich das verstehe sind Doppelpunkte für Kettensätze. Da ich bei DATA keine verwende könnte ich sie weg lassen, finde die Formatierung aber mit den Doppelpunkten übersichtlich.
Übersichtlich wäre in meinen Augen, wenn Du den Doppelpunkt bei DATA verwenden, aber dann auch nutzen würdest, also nicht immer wieder DATA schreiben würdest, sondern:
Code: Alles auswählen.
DATA: abc TYPE i,
def TYPE string,
ghi TYPE boolean_flg.Die Last auf der Datenbank ist wesentlich höher, weil sie alle Felder transferiert, obgleich Du davon nur einen Bruchteil brauchst. Spürt man heute nicht mehr so; in früheren Zeiten waren Programme mit SELECT * erheblich langsamer. Bei S/4 HANA ist * meines Wissens sogar verboten (sage ich, ohne HANA-Programmierer zu sein).* Sagt meines wissen aus das ALLE Spalten gelesen werden sollen, in meinem Fall würde bookid auslesen aber reichen, stimmt.
Zugleich verbrauchst Du auch ein Vielfaches an Arbeitsspeicher, wenn Du die ganzen nutzlosen Felder in den Arbeitsspeicher lädtst. Und zuguterletzt wird Dein Programm auch schlechter verständlich und schlechter debuggbar, denn im Debugger sieht der Leser einen Haufen nutzloser Spalten, von denen er aber gar nicht weiß, dass sie nutzlos sind, weil er ja gerade erst versucht, Dein Programm nachzuvollziehen. Definierst Du die interne Tabelle so, dass sie nur die Spalten enthält, mit denen Du tatsächlich was machen möchtest, dann ist allein daran schon erheblich besser verständlich, was Du da machst. Zugleich sieht man im Debugger dann nur aussagekräftige Spalten und nicht vorne eine Flugnummer, dann 10 gefüllte Müllspalten, dann eine benötigte Spalte (der man das aber nicht ansieht) und dann nochmal 15 Müllspalten.
Der Fleiß, vorne im Programm einmal einen kleinen TYPES-Block zu schreiben, mit dem Du Deine interne Tabelle passend maßschneiderst, ist so groß nicht, und durch Vermeidung des oben Genannten kannst Du damit später ein Vielfaches der investierten Zeit wieder einsparen. Nicht nur bei fremden Lesern, sondern auch bei Dir selbst, wenn Du nach einem halben oder ganzen Jahr mal wieder an das Programm ranmusst und nicht mehr im Kopf hast, was Du da genau gemacht hast und mit welchen Gedankengängen. Man sieht auch Bugs viel schneller, wenn man im Debugger nur relevante Werte angezeigt bekommt.
Ich kann Dir nur empfehlen, Dir von Anfang an eine professionelle Geisteshaltung anzutrainieren. Die ist (neben der Erfahrung) letztlich das, was einen Seniorentwickler von einem Junior unterscheidet.
https://github.com/SAP/styleguides/blob ... clarations
Ich nehme die auch nicht, aber mein Kollege mag die sehr. Hatten letzten eine lange Diskussion darüber. Aber laut CleanCode der SAP, soll man die nicht mehr wirklich nehmen.
Über die Verwendung von Doppelpunkten kann man trefflich streiten. 😄
Ich verwende sie kaum, sondern nur bei der Definition mit TYPES, weil dann die definierte Struktur übersichtlicher ist.
Ich hasse es, wenn ich beim Reorganisieren des Codes einzelne Variablen oder Types kopiere und jedes Mal DATA, Punkte und Kommas anpassen muss. Deswegen mag ich das eclipse-Quickfix-Plugin von Lukasz mit den Funktionen "combine statements" und "split statements". Insbesondere natürlich "split statements"... 😎
Ganz schlimm finde ich:
Gerade habe ich Code folgendes gesehen:
Doppelpunkte kann man quasi überall hin setzen:
Ich verwende sie kaum, sondern nur bei der Definition mit TYPES, weil dann die definierte Struktur übersichtlicher ist.
Ich hasse es, wenn ich beim Reorganisieren des Codes einzelne Variablen oder Types kopiere und jedes Mal DATA, Punkte und Kommas anpassen muss. Deswegen mag ich das eclipse-Quickfix-Plugin von Lukasz mit den Funktionen "combine statements" und "split statements". Insbesondere natürlich "split statements"... 😎
Ganz schlimm finde ich:
Code: Alles auswählen.
DATA: eins
, zwei
, drei
.
Code: Alles auswählen.
eins := zwei.
Code: Alles auswählen.
DATA:eins:TYPE:c:LENGTH:1::::.
Beitrag
von DeathAndPain (Top Expert / 1961 / 261 /
415
)
»
Ja, aber sowas ist doch idiotisch.
Insofern richtet sich meine Kritik nicht dagegen, dass der Threadersteller DATA mit Doppelpunkten verwendet hat, sondern dass er die Wirkung der Doppelpunkte dann nicht genutzt, sondern trotzdem einen DATA-Befehl in jede Zeile geschrieben hat. Damit sind seine Doppelpunkte dann genauso nutz- und sinnlos wie die in ewx' Extrembeispielen.
Ich persönlich finde Komma bei DATA durchaus schön, genau wie auch bei TYPES. Häufig definiert man ja auch eine Struktur direkt mit DATA (nämlich dann, wenn man sie nur in der lokalen Routine, also nicht in Interfaces, benötigt und auch keine interne Tabelle daraus konstruieren möchte). Aber auch bei WRITE sind Kommas mehr als nützlich.msfox hat geschrieben: ↑02.03.2023 17:28https://github.com/SAP/styleguides/blob ... clarations
Ich nehme die auch nicht, aber mein Kollege mag die sehr. Hatten letzten eine lange Diskussion darüber. Aber laut CleanCode der SAP, soll man die nicht mehr wirklich nehmen.
Insofern richtet sich meine Kritik nicht dagegen, dass der Threadersteller DATA mit Doppelpunkten verwendet hat, sondern dass er die Wirkung der Doppelpunkte dann nicht genutzt, sondern trotzdem einen DATA-Befehl in jede Zeile geschrieben hat. Damit sind seine Doppelpunkte dann genauso nutz- und sinnlos wie die in ewx' Extrembeispielen.
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
8800
Views
Views
SFLIGHT,SCARR Tabellen Füllen (gelöst)
von beterman » 17.10.2011 18:35 • Verfasst in ABAP® für Anfänger
von beterman » 17.10.2011 18:35 • Verfasst in ABAP® für Anfänger
8
Antw.
Antw.
4377
Views
Views
write ausgeben vor Selektionsbildschirm ausgeben
von bohne » 14.02.2006 12:50 • Verfasst in ABAP® für Anfänger
von bohne » 14.02.2006 12:50 • 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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 23 Stunden von a-dead-trousers 5 / 471
vor 23 Stunden von a-dead-trousers 5 / 471
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 23 Stunden von a-dead-trousers 5 / 471
vor 23 Stunden von a-dead-trousers 5 / 471