2. Versuch spezifischer: Auslesen Tabelle DBTABLOG
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Nachfrage:
Ein letztes Problem hab ich noch. Ich habe zwei Datensätze mit identischem Schlüssel (DBTAB-LOGKEY). Einer mit Kennzeichen I und einer mit U, der Satz wurde also erst hinzugefügt und dann geändert.
Mein Problem ist, dass im Feld LOGDATA des U-Satzes dieselben Inhalte wie im I-Satz. Ich sehe also den U-Satz, wo die DBTABLOG-Daten korrekt sind (Änderer, Datum, Zeit, etc), aber die LOGDATA-Daten übereinstimmen (was definitiv nicht stimmt, ich weiß genau welches Feld von was nach was geändert wurde).
Das Protokoll der SAP (RSVTPROT) zeigt die Daten aber richtig an. Wo die das herholen ist mir ein Rätsel. Ich habe schon geschaut, ob in LOGDATA vielleicht nebeneinander zwei Sätze stehen (eben alt und neu), das ist es aber nicht
Das DBTABLOG-LOGDATA hat bei mir dieselbe Struktur wie die Nicht-Schlüsselfelder der protokollierten Tabelle. Und ich hätte erwartet, dass in LOGDATA des U-Satzes der geänderte Datensatz der protokollierten Tabelle steht. Das ist aber zu meinem Erstaunen definitiv nicht der Fall.
Wer kann mir helfen?
Die Struktur des Codings ist:
Ralf
Nachtrag: Ich hab mir gerade nen Wolf analysiert. Ich denke, es passiert Folgendes: Beim Anlegen eines Satzes wird der Satz zusätzlich als I-Satz in die DBTABLOG geschrieben. Beim Löschen eines Satzes wird der gelöschte Satz zusätzlich als D-Satz in die DBTABLOG geschrieben.
Wird ein Satz geändert, wird der alte Satz als U-Satz weggeschrieben. Das bedeutet, dass ich den nächsten Satz lesen muss, um festzustellen, welche Änderung dabei gemacht wurde. Wenn kein nächster Satz vorhanden ist, muss ich den Satz aus der protokollierten Tabelle auslesen, denn nur dort steht der aktuellste Satz, der ist nicht im DBTABLOG vorhanden.
Zwei Fragen:
1. Kann das wer bestätigen?
2. Bin ich der einzige der das reichlich schräg findet?
Ich würde den Inhalt einer Änderung immer in dem Satz suchen, wo auch Datum und Benutzer der Änderung drinstehen, nicht im Folgesatz oder gar in einer anderen Tabelle. In LOGDATA finde ich auch definitiv keinen zweiten Satz neben dem ersten. Dass man beide reinschreibt bei einer Änderung würde ich ja echt noch verstehen. Aber NUR den alten finde ich bescheuert.
Ein letztes Problem hab ich noch. Ich habe zwei Datensätze mit identischem Schlüssel (DBTAB-LOGKEY). Einer mit Kennzeichen I und einer mit U, der Satz wurde also erst hinzugefügt und dann geändert.
Mein Problem ist, dass im Feld LOGDATA des U-Satzes dieselben Inhalte wie im I-Satz. Ich sehe also den U-Satz, wo die DBTABLOG-Daten korrekt sind (Änderer, Datum, Zeit, etc), aber die LOGDATA-Daten übereinstimmen (was definitiv nicht stimmt, ich weiß genau welches Feld von was nach was geändert wurde).
Das Protokoll der SAP (RSVTPROT) zeigt die Daten aber richtig an. Wo die das herholen ist mir ein Rätsel. Ich habe schon geschaut, ob in LOGDATA vielleicht nebeneinander zwei Sätze stehen (eben alt und neu), das ist es aber nicht
Das DBTABLOG-LOGDATA hat bei mir dieselbe Struktur wie die Nicht-Schlüsselfelder der protokollierten Tabelle. Und ich hätte erwartet, dass in LOGDATA des U-Satzes der geänderte Datensatz der protokollierten Tabelle steht. Das ist aber zu meinem Erstaunen definitiv nicht der Fall.
Wer kann mir helfen?
Die Struktur des Codings ist:
Code: Alles auswählen.
* Struktur <logdata> = Struktur Nicht-Schlüsselfelder
* der protokollierten Tabelle
...
loop at lt_dbtablog into ls_dbtablog.
assign ls_dbtablog-logdata to <logdata> casting.
* Feldzuweisung in Sammeltabelle
endloop.
Ralf
Nachtrag: Ich hab mir gerade nen Wolf analysiert. Ich denke, es passiert Folgendes: Beim Anlegen eines Satzes wird der Satz zusätzlich als I-Satz in die DBTABLOG geschrieben. Beim Löschen eines Satzes wird der gelöschte Satz zusätzlich als D-Satz in die DBTABLOG geschrieben.
Wird ein Satz geändert, wird der alte Satz als U-Satz weggeschrieben. Das bedeutet, dass ich den nächsten Satz lesen muss, um festzustellen, welche Änderung dabei gemacht wurde. Wenn kein nächster Satz vorhanden ist, muss ich den Satz aus der protokollierten Tabelle auslesen, denn nur dort steht der aktuellste Satz, der ist nicht im DBTABLOG vorhanden.
Zwei Fragen:
1. Kann das wer bestätigen?
2. Bin ich der einzige der das reichlich schräg findet?
Ich würde den Inhalt einer Änderung immer in dem Satz suchen, wo auch Datum und Benutzer der Änderung drinstehen, nicht im Folgesatz oder gar in einer anderen Tabelle. In LOGDATA finde ich auch definitiv keinen zweiten Satz neben dem ersten. Dass man beide reinschreibt bei einer Änderung würde ich ja echt noch verstehen. Aber NUR den alten finde ich bescheuert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
So, Problem gelöst, Ticket als erledigt abgehakt.
Zur Lösung:
Es ist tatsächlich so wie im Nachtrag beschrieben. Das macht die Frage "wie war der Datensatz am (Datum)?" natürlich ziemlich komplex.
Ich hab nix dagegen, ich find nur keinen Grund für diese arg merkwürdige Notation.
Ralf *sc hwer erleichtert
Zur Lösung:
Es ist tatsächlich so wie im Nachtrag beschrieben. Das macht die Frage "wie war der Datensatz am (Datum)?" natürlich ziemlich komplex.
Ich hab nix dagegen, ich find nur keinen Grund für diese arg merkwürdige Notation.
Ralf *sc hwer erleichtert
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo Ralf,
Gratulation !
bin erst zum Antworten gekommen, mir geht es jetzt so wie Dir letzte Woche - krank daheim.
dan hätte ich gleich noch ne Frage :
Welches SAP-Rel ?
bei Unicode (ERP2005) gibt es noch das Problem, daß die Daten in DBTABLOG in einem "maschinenunabhängigen Format" vorliegen können und diese dann (Feldweise) in das "maschinenabhängige Format" konvertiert werden müssen, bevor Du sie auswertten kannst dazu gibt es den Baustein: 'DB_CONVERT_FIELD_TO_HOST'.
Gruss Edwin
Gratulation !
bin erst zum Antworten gekommen, mir geht es jetzt so wie Dir letzte Woche - krank daheim.
dan hätte ich gleich noch ne Frage :
Welches SAP-Rel ?
bei Unicode (ERP2005) gibt es noch das Problem, daß die Daten in DBTABLOG in einem "maschinenunabhängigen Format" vorliegen können und diese dann (Feldweise) in das "maschinenabhängige Format" konvertiert werden müssen, bevor Du sie auswertten kannst dazu gibt es den Baustein: 'DB_CONVERT_FIELD_TO_HOST'.
Gruss Edwin
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
4.6, Releasewechsel ist am Jahresende, dein Tipp ist vermerkt. Danke für deine Hilfe.edwin hat geschrieben:Welches SAP-Rel ?
Ralf
P.S.: Kunde hat angerufen, die sind total begeistert
Der Anrufer war selbst mal Entwickler und hat sich mein Coding angeguckt. Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo Ralf,
Sorry habe erst heute Deinen Beitrag gesehen, möchte eine alternative Lösung
anbieten:
Hier der Programm Abschnitt :
jeder read bewegt dabei den Lesezeiger weiter.
Hoffe das alles plausibel ist.
gruß Tron
Sorry habe erst heute Deinen Beitrag gesehen, möchte eine alternative Lösung
anbieten:
Hier der Programm Abschnitt :
Code: Alles auswählen.
DATA log TYPE dbtablog.
DATA ls_log TYPE ylog. " struktur DBTABLOG + Deine Tabelle
DATA:
buffer TYPE xstring,
conv TYPE REF TO cl_abap_conv_in_ce.
*---------------------------------------------------------------------*
* MAIN *
*---------------------------------------------------------------------*
PARAMETERS date TYPE sy-datum DEFAULT sy-datum.
SELECT * FROM dbtablog INTO log
WHERE
tabname = 'Deine Tabelle' AND
logdate GE date.
CLEAR ls_log.
MOVE-CORRESPONDING log TO ls_log.
conv = cl_abap_conv_in_ce=>create(
encoding = 'DEFAULT'
endian = 'L'
input = log-logdata
).
*MANDT 3 Character
CALL METHOD conv->read(
EXPORTING n = 3
IMPORTING data = ls_log-mandt
).
*TPLNR 30 Character
CALL METHOD conv->read(
EXPORTING n = 30
IMPORTING data = ls_log-tplnr
).
*BRGT Decimal Feld
CALL METHOD conv->read(
IMPORTING data = ls_log-brgt
).
etc.
etc.
FREE conv.
APPEND ls_log TO gt_log.
ENDSELECT.Hoffe das alles plausibel ist.
gruß Tron
<:: 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.
Vergleichbare Themen
2
Antw.
Antw.
1853
Views
Views
Versuch Left Join von 2 auf 3 Tabellen zu erweitern
von Domgr » 10.07.2020 16:59 • Verfasst in ABAP® für Anfänger
von Domgr » 10.07.2020 16:59 • Verfasst in ABAP® für Anfänger
0
Antw.
Antw.
140
Views
Views
3
Antw.
Antw.
1034
Views
Views
0
Antw.
Antw.
208
Views
Views
Report zu geänderten Tabellen mit dbtablog
von Hendrik96 » 08.06.2022 07:56 • Verfasst in ABAP® für Anfänger
von Hendrik96 » 08.06.2022 07:56 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
685
Views
Views
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.