Ist das Änderungsbelegobjekt bekannt? Wenn nicht dann mit dem TabNamen in der TCDOB nach den Änderungsbelegobjekt lesen.ralf.wenzel hat geschrieben: Beispielfall: Nachvollziehen von Änderungen in einer Bestellung. Bekannt ist der Name der Tabellen (EKKO/EKPO) und die Nummern der zu untersuchenden Bestellungen (Tabellenschlüssel obiger Tabellen).
Das Performanteste ist immer noch selber lesen. Erst die CDHDR mit vollem Index (Änderungsbelegobjekt + Key) und dann mittels For All Entrys über die Änderungsbelegnummer auf die CDPOS. Unperformant wird es immer dann wenn nach nur einem Feld im Änderungsbelg gesucht wird, da dann auf die CDPOS ohne Index zugegriffen werden muss.ralf.wenzel hat geschrieben: Gibt es einen performanten(!!!!) Weg, das herauszufinden?
Schau dir mal das Programm RSSCD100 an. Das sollte auch schon zu 4.6 im Standard vorhanden sein. Dieser verwendet den freigeben FuBa CHANGEDOCUMENT_READ. Der ist gut dokumentiert. Wobei ich keine Aussage zur Performenc machen kann.ralf.wenzel hat geschrieben: Wenn nicht? Welcher der unperformanten Wege ist der am wenigsten steinige?
Das sind die Tabellenprotokollierungen, die haben nichts mit den Änderungsbelegen zu tun. Schau dir mal die TA SCU3 an, dies ist die Tabellenhistorie.ralf.wenzel hat geschrieben:Hm, ich hab den Report RSVTPROT gefunden, da gibt man einen Tabellennamen ein und kriegt dazu die Änderungsprotokolle (wohl aus den Tabellen OBJH und OBJS).
Keiner nen Tipp wie ich das lesbar dekodiert kriege?ralf.wenzel hat geschrieben:Die Daten stehen offenscihtlich in DBTABLOG, genauer: Im Feld LOGDATA.
Das ist ein LRAW-Feld. Kann mir jemand sagen, wie ich das "dekodiere"? Offensichtlich sind die Nutzdaten nicht im Klartext gespeichert.
Daran zweifle ich nichtxxxx hat geschrieben:jhm hat das schon beschrieben -> über die transaktion scu3 wird die tabelle DBTABLOG ausgewertet -> und hier werden die Tabellenänderung "lesbar" dargestellt -> somit Feld LOGDATA "dekodiert"!