Ich suche eine Idee, wie ich sicherstellen kann, dass die Zeilen in bestimmte Tabellen nach einem bestimmten Zeitpunkt nicht mehr verändert wurden - auch nicht von mir als "Entwickler".

Ich habe eine Zeiterfassungsanwendung erstellt. Auf Basis dessen werden die Gehälter gezahlt. Bis zu einem bestimmten zeitpunkt dürfen Daten noch geändert werden. Aber ab dem Tag X, geht das über die Anwendung nicht mehr.

Da ich die Anwendung geschrieben habe, weiß ich welche Tabellen die Stunden enthalten und welche GUID "meine" ist - also ratz fatz mit SQL Manager die DB angezogen und meine Überstunden angepasst.

Das soll ich zukünftig nicht mehr dürfen *Warum wohl* *grins*

Alle Ideen, die ich dazu habe, sind irgentwie recht lückenhaft. Wenn ich z.B. ein neues feld einbaue, wo eine Prüfsumme reinkommt, dann brauch ich mir nur ein Tool schreiben, was die Prüfsumme mit meinen Überstunden versieht - dann ändere ich nicht nur die Stunden, sondern auch noch die Prüfsumme.

Daher die Frage: Wie machen dass resivionssichere Datenbankanwendungen. Denn wenn ich steuern kann, wie die Prüfungsmechanismen gehen, kann ich sie wohl auch "umgehen".

Vielleicht hat ja jemand eine Idee dazu

PS: Nur zur Klärung - ich habe meine Überstunden natürlich NIE nachträglich geändert. Es geht mir hier auch eher um die Vorgehensweise und nicht um ein konkretes Beispiel. Außerdem ist die "Arbeitszeiterfassungs-Anwendung" nur als Beispiel genannt, um mein Problem zu verdeutlichen.

Ich würde ein externes Tool erstellen, dass Prüfsummen aus einzelnen Datenbankzeilen erstellt und in eine separate Spalte schreibt. Dieses Tool läuft dann als Job zum Zeitpunkt X. Die Prüfsummenberechnung enthält einen veränderbaren Anteil (Salt), der nur dem Admin (oder wer auch immer autorisiert ist) bekannt ist, so dass Dritte nicht in der Lage sind, eine Neuberechnung durchzuführen, selbst wenn sie Zugriff auf das Tool haben.
Um eine Manipulation zu erkennen braucht man das Tool nur erneut zum Abrechnungszeitpunkt auszuführen und die Zeilen mit abweichender Checksumme identifizieren.

Wenn ich das wirklich nachweislich Revisionssicher machen wollte, würde ich wie folgt vorgehen:
Die Daten am Tag X in ein File exportieren und dieses auf ein (oder zwei) WORM Medium schreiben. Dieses kommt dann beim Chef in den Safe. Sollte es dann Klärungsbedarf geben, kannst Du auf die Daten im Safe verweisen.

Einen Trigger schreiben der die unerwünschten Änderung abfängt und den Trigger selbst mit einem DDL Trigger, der bei Änderung eines Triggers oder des Datenbankschemas ein Mail an den "Chef" schickt (oder eine andere unwiederrufbare Aktion ausführt), vor heimlichen Änderungen schützen... (Ich hab zwar keine Erfahrung mit DDL Triggern, aber das sollte gehen...)