DBT in eine itab zum bearbeiten und zurück schreiben

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
19 Beiträge • Seite 1 von 2 (current) Nächste
19 Beiträge Seite 1 von 2 (current) Nächste

DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von Bubbleboy (ForumUser / 15 / 13 / 0 ) »
Guten Morgen ABAP Gemeinde,

ich bin etwas häufiger hier in diesem Forum unterwegs und habe schon die ein oder andere Idee mitgenommen.

Gedanke Nummer 1
Folgendes und wahrscheinlich ein Dauerbrenner, in meinem Report soll ein FB eingebunden werden der die zu ändernde Daten aus einer DB sucht, diese in eine itab übergibt, anschließend die Werte in der itab ändert und dann die geänderten Werte wieder in die DBT zurück schreibt, dabei werden die geänderten Daten nicht nur als neuer Eintrag in die DBT zurück geschrieben sondern ersetzt den alten Wert durch einen neuen.

Leider schreibt mir die sy-subrc den Fehler 4 zurück was bedeutet, dass ein Schlüssel fehlt und hier kommt auch schon die Frage dann dazu: Was übersehe ich? Wo liegt mein Fehler? Mein Ansatz, ich müsste, ähnlich wie bei dem Select wahrscheinlich beim Update sagen "Where" genau oder?

Gedanke Nummer 2
Mein zweites Problem wo ich mich gedanklich noch schwer tue, wenn im FB alles erledigt ist, dann soll er die Werte in den Report zurück geben, so dass man mit WRITE ein paar Ausgaben generieren kann.

Meine Frage wäre, wozu den Export in den Report wenn die Änderung des Wertes im FB passiert, den er als erstes aufruft im Report, die Werte sind im FB geändert und müssen damit nicht doch noch exportiert werden, ich könnte doch also im Report dann direkt mit einem WRITE die Daten dann abrufen.

Hier der FB, Function und EndFunction habe ich hier erst einmal unkenntlich gemacht.
Als Werte werden aus dem Report 3 Eingaben exportiert und in den FB importiert:
iv_na_ist
iv_na_soll
iv_pv_ne_id

Die WRITE Anweisung in der IF ist zu ignorieren, da eigentlich eine Fehlermeldung dann ausgegeben wird.
Datei1.jpg

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Kurze Frage - warum gehst du überhaupt über eine ITAB, wenn das Ganze was du das machst doch auch direkt geht.

Code: Alles auswählen.

UPDATE hrp5133 SET canid = @iv_na_soll where otype = 'NE' 
  AND .... (s.o.)

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
Bubbleboy

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von Bubbleboy (ForumUser / 15 / 13 / 0 ) »
Hallo Stefan,

damit hast Du recht. Es ist der einfachere Weg den Du da empfiehlst. Meine Vorgaben verbieten mir direkte Änderungen an einer DBT daher muss diese erst einmal in eine itab gelesen, geändert und zurück geschrieben werden.

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Bubbleboy hat geschrieben:Hallo Stefan,

damit hast Du recht. Es ist der einfachere Weg den Du da empfiehlst. Meine Vorgaben verbieten mir direkte Änderungen an einer DBT daher muss diese erst einmal in eine itab gelesen, geändert und zurück geschrieben werden.
ARGH - "Direkte Änderungen an einer DBT" sind ALLE UPDATE, MODIFY, DELETE -Befehle . Auch wenn du das in einem LOOP machst ist das eine direkte Änderung. Die Vorgabe sagt, dass du einen SAP-Fuba oder eine SAP-Methode verwenden sollst und nicht selber hart auf die Datenbank schreibst.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
DeathAndPainBubbleboy

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
black_adept hat recht; der richtige Weg für das, was Du tun willst, ist dieser FB hier:

http://www.se80.co.uk/sapfms/r/rh_u/rh_update_infty.htm

Davon abgesehen sollte Den Code aber syntaktisch funktionieren. Den SY-SUBRC = 4 wirst Du beim UPDATE möglicherweise zurückbekommen, wenn Dein SELECT gar keine Sätze gefunden hat, so dass es für den UPDATE nichts zu updaten gibt.

Du solltest aber den SELECT sauberer formulieren. Zum einen würde ich in der WHERE-Bedingung die Felder nicht wie Kraut und Rüben aufführen, sondern in der Reihenfolge des Primärschlüssels der Tabelle (womit Du dann auch besser siehst, wenn Du ein wichtiges Feld vergessen hast), zum anderen solltest Du INTO TABLE anstelle von INTO CORRESPONDING FIELDS OF TABLE schreiben. Das ist nicht nur performanter, sondern signalisiert dem Leser auch, dass Dein Zielbereich exakt vom selben Datentyp ist wie Deine Tabelle. Und das ist notwendig, wenn Du die interne Tabelle später als Quelle für den UPDATE nutzen willst.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Bubbleboy


Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von Bubbleboy (ForumUser / 15 / 13 / 0 ) »
Ich werde mich versuchen erst einmal in den Link einzulesen.

Meine Frage, es erschließt sich für mich nicht ganz warum ich immer noch mit meinem FB einen direkten Zugriff im LOOP auf die DBT habe... es wird doch in eine ITAB geschrieben?

Mit der Syntax werde ich dann ebenfalls berücksichtigen.

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Der LOOP schreibt in eine Itab, aber der dahinterstehende UPDATE schreibt dann hart in die Datenbank. Damit ist nichts gewonnen, das ist nicht weniger verwerflich, als wenn Du Dir den LOOP sparen würdest. (Dass er syntaktisch unnötig ist, ist Dir hier ja schon nachgewiesen worden.)

Ich glaube, Du hast nicht verstanden, warum man nicht direkt in eine DBT schreiben sollte. Abgesehen davon, dass ich keinen Hinweis darauf sehe, dass Du irgendwelche Sperrkonzepte berücksichtigst (was ist, wenn zeitgleich ein anderer Sachbearbeiter eine zu Deiner inkompatible Änderung an dem Mitarbeiter durchführt?), musst Du immer davon ausgehen, dass Du nie sicher sein kannst, die ganzen Rahmenbedingungen und Konsistenzkriterien zu kennen. Was ist, wenn nach den internen Unterlagen der SAP jede Änderung in der Tabelle HRP5133 mit entsprechenden Änderungen in zwei anderen Tabellen einhergehen muss? Dann schaffst Du mit Deinem Update eine Inkonsistenz in Deinem Datenbankstand. Hinterher hat die Datenbank einen ungültigen Zustand, und es ist nicht vorhersagbar, wie sich dieser auswirken wird. Du kannst Dir Deinen ganzen Personalstamm (bzw. in diesem Fall Organisationsmanagement-Stamm) auf diese Weise zerhauen! Auch ggf. auditrelevante Logs (z.B. Änderungsbelege im Personalstamm) werden auf diese Weise ggf. nicht geschrieben.

Das kannst Du nur ausschließen, wenn Du bei der SAP arbeitest und Zugriff auf alle relevanten internen Unterlagen hast. Da das bei unsereins typischerweise nicht der Fall ist, gilt die Regel, dass man aus SAP-Tabellen zwar lesen darf, jedoch niemals mit Befehlen wie UPDATE, MODIFY, INSERT oder DELETE Änderungen darin durchführen darf. Für solche Änderungen steht Dir eine Vielzahl an FBs und Klassen/Methoden zur Verfügung, die die SAP Dir bereitstellt. Diese Bausteine enthalten alle relevanten Konsistenzabprüfungen und stellen sicher, dass Deine Änderungen erstens inhaltlich valide (konsistent) sind und zweitens in einer Art und Weise in die Datenbank eingepflegt werden, die dem entspricht, was passieren würde, wenn Du die Änderung manuell mit den entsprechenden SAP-Standardtransaktionen durchführen würdest. Gibt es keinen derartigen Baustein, kannst Du Dich noch retten, indem Du einen Batch Input programmierst.

Es gibt auch FBs/Methoden zum Lesen von Daten, und viele verwenden die auch. Das halte ich aber für weit weniger kritisch. Hier geht es häufig nur darum, die SAP-Pufferung zu nutzen, also unnötige Datenbankzugriffe zu vermeiden. Häufig haben diese FBs aber so viel Overhead, dass ihre Nutzung deutlich langsamer ist als ein direkter SELECT, und wenn Du gewissenhaft programmierst, kannst Du Dir häufig Deine eigenen, programmspezifischen, sortierten internen Puffertabellen machen, die Du einmal zu Programmstart füllst und dann nur noch daraus liest.

Manchmal sind freilich geänderte Daten noch nicht auf die Datenbank geschrieben. In dem Fall holt der SAP-FB die neuen Daten korrekt aus dem Puffer, während ein direkter SELECT Dir alte Daten liefern würde. Damit habe ich aber nur sehr selten ein Problem.

Anders sieht es aus, wenn Du auf eigene Tabellen (also solche, die mit Z anfangen) oder eigene APPENDs an SAP-Standardtabellen (unter Hinzufügung von Z-Feldern) zugreifst. Deine eigenen Tabellen haben keine Abhängigkeiten im SAP-Standard, weil der SAP-Standard sie weder kennt noch nutzt. Damit kannst Du auf Deine eigenen Tabellen sorglos mit beliebigen Schreibbefehlen zugreifen und bist für inhaltliche Richtigkeit selbst verantwortlich. Bei per APPEND an SAP-Standardtabellen angefügten Feldern ist es ähnlich, wobei Du hier mit einem direkten Zugriff immerhin riskierst, dass die Tabelle gerade in einem Schreibpuffer hängt und Deine Änderung Sekunden später wieder weg ist, wenn der Verbucher die Tabelle auf die Datenbank zurückschreibt.

Nochmal: Ob Dein UPDATE in einer LOOP-Schleife oder außerhalb derselben sitzt, ist so egal, das glaubst Du gar nicht, wie egal das ist. Allenfalls könnte man sagen, dass eine LOOP-Schleife wie die Deinige es erlaubt, mit dem Debugger die einzelnen Sätze nochmal zu kontrollieren, bevor sie auf die Datenbank wandern, wohingegen ein UPDATE WHERE gnadenlos alles ändert, was der WHERE-Bedingung entspricht, ohne dass Du im Debugger nachvollziehen könntest, was er da geändert hat. Diese Kontrolle reicht aber nicht mal ansatzweise aus, um die oben geschilderten Gesichtspunkte zu entkräften.

Wer immer Dich mit einem Entwicklerschlüssel an ein SAP-System rangelassen hat, hätte Dir das eigentlich vorher erklären müssen. Dieses Wissen gehört zu den absoluten Grundlagen.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Bubbleboy


Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von Bubbleboy (ForumUser / 15 / 13 / 0 ) »
Hallo nochmal,

ich danke erst einmal für die Mühen und werde mich da mit meinen Mitarbeiter noch einmal hinsetzen müssen. Die Erklärung ist schlüssig und nachvollziehbar. Leider so nicht in der bisherigen Literatur drauf hingewiesen worden.

Werde dann bei Gelegenheit die überarbeitete Version noch einmal zum drüber schauen hier hinein stellen.

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
ich danke erst einmal für die Mühen
Gibt hier auch einen Danke-Knopf... ;-)

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Bubbleboy


Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Im übrigen ist Deine zweite Frage noch nicht beantwortet.
Mein zweites Problem wo ich mich gedanklich noch schwer tue, wenn im FB alles erledigt ist, dann soll er die Werte in den Report zurück geben, so dass man mit WRITE ein paar Ausgaben generieren kann.

Meine Frage wäre, wozu den Export in den Report wenn die Änderung des Wertes im FB passiert, den er als erstes aufruft im Report, die Werte sind im FB geändert und müssen damit nicht doch noch exportiert werden, ich könnte doch also im Report dann direkt mit einem WRITE die Daten dann abrufen
Woher soll der Report die Werte kennen? Der Werdegang war ja Dirzufolge:
in meinem Report soll ein FB eingebunden werden der die zu ändernde Daten aus einer DB sucht, diese in eine itab übergibt, anschließend die Werte in der itab ändert und dann die geänderten Werte wieder in die DBT zurück schreibt
Bedeutet im Klartext:

Report:

Code: Alles auswählen.

REPORT x.

CALL FUNCTION 'FB'.
Funktionsbaustein:

Code: Alles auswählen.

FUNCTION FB.

  DATA ITAB TYPE STANDARD TABLE OF whatever.

  PERFORM READ_DATA_INTO_ITAB TABLES ITAB.
  PERFORM MESS_WITH_THE_DATA TABLES ITAB.
  PERFORM WRITE_DATA_BACK_TO_DB TABLES ITAB.

ENDFUNCTION.
Wir Du siehst, ist ITAB nur innerhalb des Funktionsbausteins definiert. Im Report ist die Tabelle gar nicht bekannt. Selbst wenn Du sie auch dort per DATA definieren würdest, wäre ihr Inhalt dort trotzdem nicht bekannt. Daten, die der Report nicht kennt, kann er aber auch nicht per WRITE ausgeben.

Also musst Du die Tabelle ITAB als Parameter aus dem FB hochreichen lassen, damit die Werte auch im Report zur Verfügung stehen.

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Bubbleboy


Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von Bubbleboy (ForumUser / 15 / 13 / 0 ) »
Guten Morgen,

das im FB dementsprechend Import und Exportparameter festgelegt werden müssen ist bereits passiert und soweit klar.

Ggf. ist meine Frage 2 zu ungenau gewesen.

Wird im FB die Daten einer DBT geändert dann bräuchte er doch die Werte nicht noch exportieren und der Report die Werte importieren. Auf die DBT kann doch, soweit mein bisheriges Verständnis geht, quasi überall, entsprechende Rollen vorausgesetzt, drauf zugegriffen werden.

Dein Beispiel mit einer ITAB ist klar.

Vermutlich beantwortet sich meine Frage 2 aber mit der Frage 1, dzw. Eure bisherigen Klarstellungen das der/das Grundgedanke/-verständnis ggf. falsch sein wird.

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Ggf. ist meine Frage 2 zu ungenau gewesen.

Wird im FB die Daten einer DBT geändert dann bräuchte er doch die Werte nicht noch exportieren und der Report die Werte importieren. Auf die DBT kann doch, soweit mein bisheriges Verständnis geht, quasi überall, entsprechende Rollen vorausgesetzt, drauf zugegriffen werden.
Wenn ich das richtig verstehe, dann argumentierst Du jetzt, dass der Report ja nach Beendigung des Funktionsbausteins selber einen SELECT auf die Datenbanktabelle machen und sich die Daten auf diese Weise beschaffen könnte.

Klar, das kannst Du machen. Aber zumindest solange Du nicht auf einem HANA-System arbeitest, sind Datenbankzugriffe mit deutlichem Abstand das, was am meisten Rechenzeit beansprucht. Bei fast allen Programmen geht beinahe die gesamte Rechenzeit für Datenbankzugriffe drauf; was ABAP selbst braucht, ist im Vergleich dazu "ferner liefen". Das siehst Du sehr schön, wenn ein Programm länger rechnet und Du derweil in einem zweiten Fenster mal die Transaktion SM50 startest und Dir (mit immer-wieder-refreshen) anschaust, was das rechnende Programm gerade macht. Fast immer wirst Du da irgendeine Form von Datenbankzugriff sehen.

Wenn Du also die benötigten Daten ohnehin schon innerhalb des Funktionsbausteins in einer internen Tabelle hast, dann wäre es performancemäßig verwerflich, wenn Du Dir den einen Übergabeparameter sparst und dafür alles nochmal von der Datenbank liest. Überdies ist das, was auf der Datenbank steht, nicht unbedingt das, was der Funktionsbaustein ermittelt hat (denn die Datenbanktabelle könnte auch vorher schon Einträge enthalten haben). Wenn Du also sicher sein willst, dass Du nur genau das mit WRITE ausgibst, was Dein FB in diesem Programmlauf errechnet hat, dann solltest Du es auch aus dem FB holen und nicht irgendwo anders her. Das hilft auch bei der Fehlersuche, denn wenn Du auf der Datenbank andere Werte vorfinden solltest als die, die Du erwartet hast, dann ist doch die erste Frage, welche Werte hatte der FB denn ermittelt?

Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Bubbleboy


Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von Bubbleboy (ForumUser / 15 / 13 / 0 ) »
Ok Danke,

ich verstehe.

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von Bubbleboy (ForumUser / 15 / 13 / 0 ) »
Hallo zusammen,

ich habe mir also nun eure Informationen noch einmal durch den Kopf gehen lassen und von vorne angefangen. Mein Ansatz nun. Überprüfungen über FB's im Report.
Ziel am Ende ist im Report nur noch ein FB zuhaben (wie ursprünglich gedacht). Meine Probleme die ich habe:

- Aktuell wird ein Dump ausgelöst im zweiten FB (Siehe letzter Anhang ) wahrscheinlich wieder ein simpler Fehler der zu ändern wäre. Der Dump ist klar aber ich wüsste nicht auf Anhieb wo ich da ansetzen könnte..
- Man meinte, um das Ganze abzurunden sollten die Fehlermeldungen bzw. Erfolgsmeldungen über eine BAPITAB gemacht werden. Hätte ggf. da jemand ein kleines veranschaulichendes Beispiel ?
C1.gif
C2.gif
C3..gif
Zuletzt geändert von Bubbleboy am 02.02.2018 15:31, insgesamt 1-mal geändert.

Re: DBT in eine itab zum bearbeiten und zurück schreiben

Beitrag von Bubbleboy (ForumUser / 15 / 13 / 0 ) »
Der DUMP

C4.gif

Vergleichbare Themen

2
Antw.
1672
Views
itab ins memory schreiben
von Max2 » 08.02.2006 16:21 • Verfasst in ABAP® Core
2
Antw.
1717
Views
Bestimmte Anzahl Datensätze in ITAB schreiben für Anzeige.
von Mavrix » 18.01.2007 15:32 • Verfasst in ABAP® für Anfänger
3
Antw.
1731
Views
Daten aus einer Tabelle in eine itab schreiben
von zitroneHR » 30.03.2017 11:17 • Verfasst in ABAP® für Anfänger
30
Antw.
12682
Views
move itab 1 nach itab 2 mit bedingung
von c oco » 17.04.2012 14:39 • Verfasst in ABAP® für Anfänger
2
Antw.
1282
Views
Zurück zu Selectionsbildschirm
von holderda » 11.03.2014 13:38 • Verfasst in ABAP® für Anfänger

Ü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

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 72
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141