3
Änderungsprotokoll in MS Access XP, 2003
Hallo Zusammen,
erstmal noch einen schönen Sonntag und jetzt zu meinem Problem/Frage.
Also, ich hab eine Access-Datenbank. Ich möchte das die änderungen die über ein Formular im Datensatz vorgenommen werden in einer Tabelle mitgeloggt werden.
Die Logg-Tabelle wollte ich in etwa so aufbauen.
Wie würdet ihr das in die Formular integrieren?
Meine Idee wahr das ganze bei jedem feld über Nach Aktualisierung mittels VBA-Script in die Tabelle schreiben zu lassen. Gibt es da nicht noch einen einfacheren weg?
Danke für eure Hilfe im voraus.
mfg
andi
PS: Ich verwende Access XP und 2003
Edit 2006-07-31 16:28
Die Felder im Formular sind Ungebunden und werden über VBA-Script beim Öffnen gefüllt und über einen klick auf einen Butten, werden die änderungen zurück an die Tabelle übergeben.
erstmal noch einen schönen Sonntag und jetzt zu meinem Problem/Frage.
Also, ich hab eine Access-Datenbank. Ich möchte das die änderungen die über ein Formular im Datensatz vorgenommen werden in einer Tabelle mitgeloggt werden.
Die Logg-Tabelle wollte ich in etwa so aufbauen.
| ID | DatensatzID | User | Rechner | Datum | FeldName | alterFeldWert | neuerFeldWert |
Wie würdet ihr das in die Formular integrieren?
Meine Idee wahr das ganze bei jedem feld über Nach Aktualisierung mittels VBA-Script in die Tabelle schreiben zu lassen. Gibt es da nicht noch einen einfacheren weg?
Danke für eure Hilfe im voraus.
mfg
andi
PS: Ich verwende Access XP und 2003
Edit 2006-07-31 16:28
Die Felder im Formular sind Ungebunden und werden über VBA-Script beim Öffnen gefüllt und über einen klick auf einen Butten, werden die änderungen zurück an die Tabelle übergeben.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 36971
Url: https://administrator.de/forum/aenderungsprotokoll-in-ms-access-xp-2003-36971.html
Ausgedruckt am: 01.04.2025 um 22:04 Uhr
3 Kommentare
Neuester Kommentar
Wenn Du es schon nur über einen Button in die Tabelle zurückschreibst, warum dann das Logging nicht in den Button reinprogrammieren?
Bei Nach Aktualisierung würdest Du ja unter Umständen Änderungen loggen, die nachher gar nicht wirklich in die Tabelle geschrieben werden, weil der User das Formular zumacht, anstatt den Speichern-Button zu benutzen.
Bei Nach Aktualisierung würdest Du ja unter Umständen Änderungen loggen, die nachher gar nicht wirklich in die Tabelle geschrieben werden, weil der User das Formular zumacht, anstatt den Speichern-Button zu benutzen.
Moin n4426,
unabhängig von AndreasHosters richtiger Anmerkung halte ich es für absolut überdimensioniert, ausgerechnet bei einem Leicht-Systemchen wie MSACCESS -ohne wirkliche Server-Datenbankengine- irgendwelche Trigger-Implementierungen nachbilden zu wollen.
Und vollkommen unverhätnismäßig ist der Ansatz, jede FELD-bezogene Änderung speichern zu wollen statt jede Datensatz-bezogene.
Da hieße doch, bei einer Tabelle mit 20 Datenfeldern müsstest du bei einer NEU-Anlage und bei einem SATZ-LÖSCHEN jeweils 20 Datensätze in dieser Logdatei schreiben.
Und das alles für jedes (Formular-)Feld einzeln händisch per VBA geprüft und auf ein DB-Feld gemappt (da die Felder ja "ungebunden" sind). Höchst aufwändig, höchst fehlerträchtig, kaum wartbar.
Wozu?
Was steht denn hinter dieser eher abstrakten Anforderung "Ich möchte die Änderungen nachvollziehen können?"
Wollt ihr nur die Änderungsfrequenz der DB zeitweilig protokollieren oder automatisiert die Änderungen eines Zeitraums oder eines bestimmten Users zurückdrehen können?
Wenn es tatsächlich einen stichhaltigen Grund für eine derartig detaillierte Änderungsdokumentation geben sollte, dann kommt ihr um Datenbank-Trigger und damit um eine "echte" SQL-Datenbank nicht herum.
Gruß
Biber
unabhängig von AndreasHosters richtiger Anmerkung halte ich es für absolut überdimensioniert, ausgerechnet bei einem Leicht-Systemchen wie MSACCESS -ohne wirkliche Server-Datenbankengine- irgendwelche Trigger-Implementierungen nachbilden zu wollen.
Und vollkommen unverhätnismäßig ist der Ansatz, jede FELD-bezogene Änderung speichern zu wollen statt jede Datensatz-bezogene.
Da hieße doch, bei einer Tabelle mit 20 Datenfeldern müsstest du bei einer NEU-Anlage und bei einem SATZ-LÖSCHEN jeweils 20 Datensätze in dieser Logdatei schreiben.
Und das alles für jedes (Formular-)Feld einzeln händisch per VBA geprüft und auf ein DB-Feld gemappt (da die Felder ja "ungebunden" sind). Höchst aufwändig, höchst fehlerträchtig, kaum wartbar.
Wozu?
Was steht denn hinter dieser eher abstrakten Anforderung "Ich möchte die Änderungen nachvollziehen können?"
Wollt ihr nur die Änderungsfrequenz der DB zeitweilig protokollieren oder automatisiert die Änderungen eines Zeitraums oder eines bestimmten Users zurückdrehen können?
Wenn es tatsächlich einen stichhaltigen Grund für eine derartig detaillierte Änderungsdokumentation geben sollte, dann kommt ihr um Datenbank-Trigger und damit um eine "echte" SQL-Datenbank nicht herum.
Gruß
Biber
Hi,
@andreashoaster
Klar sollen die änderungen erst gelogt werden, wenn der Speicherbutton gedrückt wird. (hab das Formular erst mit gebunden feldern gemacht und hab das dan geändert).
@Biber
wenn ein Datensatz hinzugefügt wird braucht in der Tabelle nur vermberkt werden User: 123 hat datensatz xy erstellt. Beim löschen ebenso.
Mit dem "Produkol" soll man einzelne fehlerhafte änderungen per hand rückgängig machen können (damti die Feldinhalte in der DB noch vorhanden sind).
mfg
andi
@andreashoaster
Klar sollen die änderungen erst gelogt werden, wenn der Speicherbutton gedrückt wird. (hab das Formular erst mit gebunden feldern gemacht und hab das dan geändert).
@Biber
wenn ein Datensatz hinzugefügt wird braucht in der Tabelle nur vermberkt werden User: 123 hat datensatz xy erstellt. Beim löschen ebenso.
Mit dem "Produkol" soll man einzelne fehlerhafte änderungen per hand rückgängig machen können (damti die Feldinhalte in der DB noch vorhanden sind).
mfg
andi
