Ich glaube zwar nicht, dass das notig ist, aber wenn Du wirklich nachweisen willst, daß ein Datensatz nicht verändert wurde braucht Du eine kryptographische Signatur und diese Signatur muss einen externen Zeitstempel enthalten.
.
Solange ich selbst signiere, kann ich “notfalls” ja immer die komplette Datenbank neu aufbauen. Auch der externe Zeitstempel schützt davor nicht direkt, den könnte ich wiederverwenden oder auf Vorrat speichern. Die externe Stelle bekommt einen kryptographischen hash des Datensatzes und signiert diesen mit Zeitangabe und schickt das zurück. Dies wird in einer zweiten Tabelle gespeichert, die damit beweist, das Tabelle1 unverändert ist.
.
Wir bewegen uns da aber in Bereichen, wo der “analoge” menschliche Buchalter nur unter Aufsicht arbeitet und jede Buchung auf Papier doppelt unterschrieben werden müsste. Ich sehe nicht dass da wirklich das Ziel “ordentlicher Buchführung” ist.
.
Eine Kombination aus einem mit TRIGGER gefüllten Log aller Änderungen sollte zusammen mit einem versionierten Backup reichen. Ansonsten sollte eben das Löschen von Datensätzen im Formular verhindert werden und z.B. eine Storno-Kennung vorgesehen sein. Ich halte in der Buchhaltung eine entsprechende Gegenbuchung fur sinnvoll, die ggfs auch die Storno-Kennung hat, so dass beides bei manchen Übersichten ausgeblendet werden kann (alternativ ST/TS für Storno und Gegenbuchung).
.
Es gibt übrigens noch ein Problem, was gegen ein “nie löschen” spricht: Nach DSGVO muss ich nicht mehr benötigte personenbezogene Daten löschen, wenn die Aufbewahrungsfristen vorbei sind. Und natürlich gibt es verschiedene Fristen (bei mir z.B.: Geldwäschegesetz 5 Jahre, Rechnungen/Transaktionen 10 Jahre, Kulturschutzgesetz 30 Jahre). Also brauche ich die Möglichkeit Teile zu löschen, wenn Ihre Zeit gekommen ist.
Das ist ja grauenhaft, liegt aber an Firebird (außer vielleicht, dass LibreOffice’s Firebird-Treiber entsprechend präpariert sein könnte? das wäre noch schlimmer)
Hier eine befreite HSQLDB mit Auto-Install-Macro. Die Passwörter für “SA” und “Anwender” sind im Formularnamen verewigt. “Anwender” kann alles (GRANT ALL) außer löschen (REVOKE DELETE).
granted.zip.odf (17.5 KB) (.odf vom Dateinamen entfernen)
Genau soetwas habe ich mir vorgestellt.
Zwei Fragen noch:
- Kann man die Passwörter im granted.script noch irgendwie “verbergen”?
- Könnte man auch mehr Anwender im script anlegen? Wahrscheinlich muss man dann das Makro entsprechend anpassen?
[quote=“Wanderer, post:21, topic:111786”]
Ich glaube zwar nicht, dass das notig ist, aber wenn Du wirklich nachweisen willst, daß ein Datensatz nicht verändert wurde braucht Du eine kryptographische Signatur und diese Signatur muss einen externen Zeitstempel enthalten.
.
An einen externen Zeitstempel habe ich auch schon gedacht für meine CALC-EÜR, dann bräuchte ich mit BASE nicht neu anfangen ;-)))
Man kann einen HSQLDB-Server so aufsetzen, dass kein Benutzer diese Datei lesen kann sondern nur das Dienstprogramm. Sollte mit jedem Datenbank-Server so oder ähnlich funktionieren.
Das hat alles überhaupt nicht mit Makros zu tun. Mein Makro passt lediglich die Pfade der Datenbank und des Datenbanktreibers auf Dein System an, wenn Du die Datenbank öffnest.
Bei mir ist das /tmp/test/granted/database/granted.* für die Datenbankdateien sowie /opt/libreoffice24.2/program/classes/hsqldb.jar für den Datenbanktreiber. Nach dem Herunterladen und Entpacken auf Deinem System sind das höchstwahrscheinlich ganz andere Pfade, die das Dokument mit der Datenbank und einem geeigneten Treiber verbinden, nämlich da, wo Du den Kram hingepackt hast sowie ein bestimmter Pfad innerhalb Deines Installationsverzeichnisses.
Du siehst in dem granted.script die Befehle mit denen Benutzer und Passwörter festgelegt werden. Man kann diese Benutzer auch Gruppen (“ROLES”) zuordnen und dann festlegen, was diese Gruppen dürfen oder nicht. In Base nimmt man dafür den SQL-Dialog (Extras>SQL…).
HSQL wird mit ausreichend Dokumentation ausgeliefert.
Vergiss es aus zweierlei Gründen.
Du wirst als Laie nicht den gesetzlichen Anforderungen programmtechnisch nicht gerecht.
Selbst wenn Du programmiertechnisch den gesetzlichen Aforderungen gerecht werden könntest wäre der Arbeitsaufwand viel zu groß.
Ein gut gemeinter Rat:
Kauf’ Dir ein Programm, das den gesetzlichen Anforderungen gerecht wird.
Da musst Du vielleicht mit 100 - 150 € jährlichen Kosten rechnen. Aber dann hast Du mehr Zeit gespart als Du Dir programmtechnisch erarbeiten könntest, Du hast kaum Fehler im Programm und Du bist auf der sicheren Seite, was die finanztechnischen Forderungen betrifft.
Habe ich mir auch schon gedacht, bevor ich hier was geschrieben habe.
.
Aber diese Programme (lexware usw.) speichern alles in der Cloud und ich möchte Herr meiner Daten sein, also alles bei mir auf meinem Rechner haben. Sollte es die Herstellerfirma einmal nicht mehr geben, was ja nicht undenkbar ist, oder ich mir ein anderes Programm aussuchen, dann habe ich keinen Zugriff mehr auf meine Daten, die ich von Gesetzes wegen mindestens 10 Jahre aufbewahren muss.
.
Es gibt auch Lösungen für Excel/CALC, die kosten 49,95 €/Jahr, können aber die GoBS nicht einhalten. Da habe ich mir gedacht, wenn ich sowieso was lernen möchte, baue ich mir mit BASE etwas, was bei mir mit meinen Daten auf meinem Rechner läuft. Im übrigen ist es keine Raketenwissenschaft, die Anlage EÜR als Grundlage für die Buchungen zugrundezulegen und dann, wie Robert und Villeroy vorgeschlagen haben, die Zugänge zum Löschen bzw. Ändern entsprechend abzusichern und dies für die Finanzverwaltung/Betriebsprüfung entsprechend zu dokumentieren.
Natürlich kannst Du dir Dein Firmengebäude selbst errichten, Dach decken, elektrifizieren und verklempnern. Dauert halt und kostet deshalb viel mehr, weil Software nur aus Arbeitskosten besteht. Ich glaube nicht, dass jegliche Finanzsoftware Daten in die Cloud schreibt. Unsere tut das nicht, aber die ist für Arztpraxen.
OK. Hast mich überzeugt.