[gelöst][CC] fehlende Einträge im Change Log

Wir setzen NAV2009 SP1 (6.00.30647) ausschließlich im CC ein, protokolliert werden einige Tabellen ohne Feldbegrenzung, u.a. die Artikel-Tabelle.
Jetzt haben wir das sporadische Phänomen, dass wenn ein Artikel angelegt wird, dieser anscheinend keinen Inhalt in den Feldern Beschreibung, Beschreibung 2 und einem neu angelegtem Feld Beschreibung 3 hat.
D.h.diese Felder tauchen nicht im ChangeLogEntry auf, ergo wurden diese Felder laut Log nicht gefüllt.
Im Log steht dann, ein paar Stunden später datiert, ein Änderung, bei der das Feld Beschreibung 2 von "XY" auf "XYZ" geändert wird - sehr merkwürdig, da dieses Feld nie gefüllt wurde.
Aufgrund verschieden-zeitiger Drucke eines Report kann man dann noch nachvollziehen, dass Beschreibung 3 seit der Anlage ebenfalls geändert wurde (fehlt nämlich auf dem ersten Ausdruck) - zu diesem Feld gibt es keinen Einträg im Log.

In einem Test (im gleichen System, gleicher Mandant), in dem o.g. Felder gleichzeitig, nacheinander oder in verschiedenen Kombinationen angelegt bzw. geändert wurden, wurden alle Änderungen wie erwartet protokolliert.

Zuletzt geändert von stephan.bosau am 14. März 2013 10:09, insgesamt 1-mal geändert.

Steht in dem Eintrag der Änderung des Feldes ein nachvollziehbarer "von" Wert oder nicht?

Evtl. müssen bei euch nur mal alle Objekte im betroffenem System rekompiliert werden.

1. Steht bei den betroffenen Tabellen auch das Ereignis "Einfügen" auf "Alle Felder"?
   Falls nicht: Haben dort wenigstens die betroffenen Felder (Beschreibung..Beschreibung3) ein Häkchen bei Einfügen?
   
2. Wie werden die Artikel angelegt/eingefügt?
   Wenn dies nämlich per Programmcode geschieht, protokolliert das ChangeLog nichts.
   (Hinweis: F3 kann auch von einem MenuItem abgefangen werden, welches dann den Datensatz per C/AL-Code einfügt.)

[*]Wie werden die Artikel angelegt/eingefügt?
Wenn dies nämlich per Programmcode geschieht, protokolliert das ChangeLog nichts.

Man kann es aber nachprogrammieren, damit auch Datensatzänderungen per Code ins Changelog geschrieben werden.

[*]Wie werden die Artikel angelegt/eingefügt?
Wenn dies nämlich per Programmcode geschieht, protokolliert das ChangeLog nichts.

Man kann es aber nachprogrammieren, damit auch Datensatzänderungen per Code ins Changelog geschrieben werden.

Schon klar, aber seien wir doch mal ehrlich: Das wird sehr häufig vergessen.

Bei uns steht so was wie :

Tabelle 27, Feld 5, kein insert-Satz, andere Felder wie No. stehen aber im Log!?
Tabelle 27, Feld 5, Bearbeiten, alter Wert: XY, neuer Wert: XYZ
... für Feld 50000 gibt es keinen Eintrag, obwohl dieses Feld gefüllt ist.

Und die Artikel werden alle im Dialog eingegeben, also nicht per C/AL o.ä.

Und die Artikel werden alle im Dialog eingegeben, also nicht per C/AL o.ä.

Ja, aber hinter den Feldern steht VALIDATE-Code. Und wenn der ein INSERT oder MODIFY absetzt, kriegt das Änderungsprotokoll dies nicht mit (ohne dass mann noch eine Zeile für das Änd.-Protokoll dranprogrammiert).

Und die Artikel werden alle im Dialog eingegeben, also nicht per C/AL o.ä.

Ja, aber hinter den Feldern steht VALIDATE-Code. Und wenn der ein INSERT oder MODIFY absetzt, kriegt das Änderungsprotokoll dies nicht mit (ohne dass mann noch eine Zeile für das Änd.-Protokoll dranprogrammiert).

Dagegen würde aber die Tatsache sprechen, dass im selben System/Mandanten alles korrekt protokolliert wird, wenn man einen Test-Artikel anlegt - oder?

... allerdings gibt's da dieses modify(true) beim validieren des "Base Unit of Measure", das hab' ich noch nicht bedacht - probier ich gleich mal aus!

Und die Artikel werden alle im Dialog eingegeben, also nicht per C/AL o.ä.

Ja, aber hinter den Feldern steht VALIDATE-Code. Und wenn der ein INSERT oder MODIFY absetzt, kriegt das Änderungsprotokoll dies nicht mit (ohne dass mann noch eine Zeile für das Änd.-Protokoll dranprogrammiert).

Dagegen würde aber die Tatsache sprechen, dass im selben System/Mandanten alles korrekt protokolliert wird, wenn man einen Test-Artikel anlegt - oder?

... allerdings gibt's da dieses modify(true) beim validieren des "Base Unit of Measure", das hab' ich noch nicht bedacht - probier ich gleich mal aus!

Du hast von gleichen Systemen gesprochen und nun sinds doch unterschiedliche?

Das o.g. modify(true) könnte das Poblem sein!
Beim Anlegen einer Artikeleinheit wird das log mit den passenden Werten beschrieben. Nachträgliche Änderungen, z.B. in der Bezeichnung, mit anschließender Änderung der Basiseinheit werden dann nicht protokolliert, außer mit dem Änderungsdatum!

Ich werd' die Protokollierung um dieses modify mal erweitern und dann berichten.

Du hast von gleichen Systemen gesprochen und nun sinds doch unterschiedliche?

Nee, gleiches System - wieso?

... mit Test-Artikel ist ein Artikel (hier im selben System) gemeint, der nur zum Testen (des Loggings) angelegt und später wieder gelöscht wird.

Das Problem wurde definitiv das modify(true) im Feld Basiseinheit verursacht, besten Dank für den Tipp!!!

Im Klartext heißt das, wenn Felder im Artikel geändert werden und danach auch noch die Basiseinheit (z.B. bei neuen Artikeln ohne Posten), werden diese Änderungen nicht protokolliert.
Es hat mich doch sehr verwundert, dass dies auch so mit Standard-Objekten funktioniert und das stellt sich auch schon die Frage:

Wozu dient dieses modify?

Zum einem wird hiermit das letzte Änderungsdatum geschrieben,
zum anderen wird die Routine "Planning Assignment".ItemChange aufgerufen, in der auf den ersten Blick auch kein Bezug zu irgendeiner Einheit besteht.

... kann man sich dieses modify evtl. sparen?

... kann man sich dieses modify evtl. sparen?

Ohne die Frage wirklich zu beantworten (und mir den Code dahinter anzusehen): Erfahrungsgemäß stehen diese "Programmierer-Rätsel" nicht ohne Grund da drin. Die Wahrscheinlichkeit, dass die Löschung dieses MODIFYs ein unerwartetes Folgeproblem verursacht, ist relativ groß.

Besser ist es, du fügst nach diesem MODIFY noch Code hinzu, um die Änderung dem Protokoll mitzuteilen.

... mal sehen welche Lösung wir hier nehmen, das eigentlich Problem ist erst mal gelöst - nochmals besten Dank!