Audit von Änderungen

Selbstverständlich wäre eine zentrale Lösung am besten. Nur konnte ich darauf leider nicht ewig warten. Spätestens bei Mappingtabellen gerät das selbst erstellte Auditsystem an sein Limit. Soll heissen, wenn ich in einer Maske mehrere Werte zuweisen kann, werden diese Änderungen nicht im eigentlichen Datensatz, sondern in der Mappingtabelle abgelegt. Das zugehörige Auditfenster des Datensatzes zeigt solche Änderungen aber nicht an. Wäre sicher auch lösbar, aber nur mit weiteren Views. Also ja, bitte eine zentrale Lösung schaffen.

Da kann ich dem Oliver nur beipflichten: wenn auf einer table (tHosts) z.B. durch diverse Dienstleister etliche Trigger rattern: wer kümmert sich um das DEBUG wenn etwas schräg läuft?

Hallo zusammen, es ist bekannter Ansatz und er wird in kleineren Umgebungen und ohne viel customizing bestimmt auch realisierbar sein. Ich halte es aber für ein Problem das wir (customizer) uns alle irgendwelche Lösungen für ein eigentlich zentrales Thema hier "selbst basteln" Zum einem sollten wir ggf. auch unterscheiden wo der genaue Anwendungszweck die Anforderung liegt :
per Scan erfasste Daten zu tracken vs Änderungen an Stammdatenpflege, etc.
Ersteres schließe ich hier mal aus. Die Scandaten (dynamisch) sehe ich persönlich grundsätzlich nicht sinnvoll . (spätestens bei Herstelleränderungen , neue Felder Inhalte , etc.) Es geht und i.d.R. darum wer und wann er Änderungen an Stammdaten gemacht hat. (zumindest in unseren Customizings)
Wir haben bei unserem Customizingpaket mittlerweile ca. 100+ Kundentabellen (inkl. Wertehilfen Tabellen) ca. 200+ Kundenviews ca. 1500+ Kundenfeldwerte (eigene Tabellen und Herstellertabellen)
Die Trigger auf die 100 Kunden Tabellen müssen auch um eigene Trigger für einige Herstellertabellen erweitert werden. Und genau das kann dann auch zu Problemen führen. Herstellertrigger gibt es ja auch schon ;-) Und bitte nicht vergessen das im Trigger i.d.R. Insert, update, delete behandelt werden.
Mir wäre wirklich sehr daran gelegen die Thematik mit entsprechenden anderen "Customizern" in passender Runde zu besprechen und ggf. mit dem Hersteller eine sinnvolle Lösung abzustimmen. Diese vielen Insellösungen können ja auch nicht im Sinne des Herstellers sein ;-) Gruss aus Köln Oliver Hepp

Mittlerweile habe ich eine zentrale Audittabelle in Betrieb, welche über Trigger in den einzelnen Tabellen befüllt wird. Der jeweilige Tabellenname wird in einem eigenen Feld gespeichert und kann somit als Filter in den Metaobjekten verwendet werden. Neue Trigger und Metaobjekte zur Auswertung sind damit bei Bedarf in wenigen Minuten erstellt.

Guten Morgen,
gerade aktuell fragt mich ein guter Kunde (ISMS im Krankenhaus-Sektor) dazu an. Es sollen alle Changes am Invenatr in Docusnap geloggt sein.
Mal schauen, ob die Funktion irgendwann kommt....

Hallo,
ich habe das selbe Anliegen, es sollte möglich sein nachzuvollziehen, wann/wer/wo etwas geändert hat. Immer nur den Ist Stand sowie ein Paar Snapshots davor bringt mir eigentlich nicht viel. Für Zertifizierungen und Audits werden diese Dinge gefordert.
Bei einem Gespräch mit eurem Supportern kam die Idee auf, eine Tabelle zu erstellen, wo jedes mal der aktuelle Snapshot mit dem vorigen verglichen wird und nur alle Änderungen vermerkt werden. Das könnte man auch nur für Zeitraum X machen. Somit wäre die Datenmenge nicht so groß aber trotzdem alle Daten verfügbar.
Ich habe auch unter meinen Kollegen jemand der auch Docusnap nutzt und dachte das würde schon so gemacht werden, weil er genau dies benötigt.

Vollkommen nachvollziehbar :-) ich schrieb ja bereits: "Wir bauen schon seit Jahren in unseren Customizings bei bestimmten Datenmodellen mit sehr großem Aufwand eine solche Funktionalität mit ein. Eine herstellerseitige Lösung wäre auf jeden Fall anzustreben."
Es ist aber vermutlich leider auch relativ aufwändig so etwas zu realisieren. Aber wichtig wäre es definitiv. Thema Customizing: Gerade wenn es dann noch eigene Tabellen oder eigene Felder in Default Tabellen sein sollten. Es müsste vermutlich somit jedes Feld (default Auslieferung/Kunde) ein Flag mitgegeben werden, wenn es protokolliert werden soll. Dazu dann auch die passenden Feldhistorien des Wertes und Änderer/Datum. Die dynamischen Tabelleninhalte , also alles was über Snapshot mit Inhalten gefüllt wird, könnten allerdings wahrscheinlich ausgeschlossen werden. Solange es aber wie aktuell zu sehen nur 4 Personen hier voten (=40 Punkte) wird es vermutlich leider nicht durch den Hersteller als notwendig eingestuft. Sehr Schade.

Ich melde mich hier mal rein und möchte kurz darstellen, warum ich im Forum nach dem Logging gefragt habe. Ich habe in DocuSnap ein Schlüsselbuch angelegt und möchte nachhalten können, wer, wann, welche Änderung gemacht hat.
Ich stimme FO zu, dass nicht generell alles geloggt werden muss. Daher wäre mein Wunsch Auswahl was geloggt werden kann/soll (basierend auf Table) Verweildauer der Logfile/LogDB sollte angegeben werden können in Tage/Wochen/Monate Anzahl der Änderungen (z. Bsp. die letzten 3 Änderungen) Berechtigungsrolle, damit nicht jeder auf die Logs zugreifen kann

deshalb schrieb ich ja: "oder die Protokollierung ausgeschaltet lassen" ist beim Passwort ja im Übrigen schon lange so geregelt :-) Da gibt es ja quasi schon die Funktion der Protokollierung

@Oliver: wegen SQL-Express immer daran danken, das nicht jeder Docusnap-Anwender ein Enterprise-Kunde ist! Und da spielt Budgetierung eine völlig andere Rolle als in dem Sgement wo du und ich meist unterwges ist ;-) Daher: unbedingt OPTIONAL und nicht als Standard-Option.

Gerade in der Zeit wo immer mehr Revisionssicherheit im Bereich von Normen / Audits gefordert wird, wäre eine solche Funktion übergreifend wichtig. Wir bauen schon seit Jahren in unseren Customizings bei bestimmten Datenmodellen mit sehr großem Aufwand eine solche Funktionialität mit ein. Eine herstellerseitige Lösung wäre auf jeden Fall anzustreben. Ob es auch damit ein Undo geben sollte steht sicherlich dann noch zur Diskussion. (Auch das müsste ja wieder nachvollzogen werden können...) Den Einwand mit Speicherplatz Problme bei SQL Express kann ich nur bedingt teilen. Wenn eine Kunde solche Anforderungen (Änderungen nachzuverfolgen) hat , sollte er in der Regel dann auch das passende Konstrukt (SQL Edition) wählen, oder die Protokollierung ausgeschaltet lassen. Die Protokollierung betrifft ja nicht die dynamischen Snapshot Infos sondern die statischen Werte eines Assets

Eine Option, mit der man soeben getätige Änderungen wenigens einen Schritt zurücksetzen könnte, falls mal etwas falsch eingegeben wurde, wäre auch schon hilfreich. Zum Beispiel eine falsche Standortänderung. wenn man da nicht aufpasst, hat man schnell falsche Daten. Ein Undo wäre also schon mal ein Anfang.

Hallo, allerdings sollte man wenn dann selektiv festelegen können was genau geloggt wird. Bitte auch bednenken: die Datenbankgröße, Logging "FRISST" Speicherplatz!!!! Nicht jeder Kunde hat Budget für echten SQL-Server. Daher: selektive Festlegung andenken. Aber ja, das ist immer wieder Thema, daher Dauemen hoch von mir!