Hallo Zusammen,
ich möchte gerne meine Tabelle historisieren um z.b. die Zeitliche Entwicklung von Daten in der Tabelle Später abfragen zu können.
Meine Idee hierzu ist, sobald ein Benutzer in der Tabelle einen Wert ändert, soll der gesamte Datensatz dupliziert werden und mit einem Zeitstempel versehen abgespeichert werden, sodass der ursprüngliche Datensatz erhalten bleibt und der neue eindeutig als aktuellste Version wegen des Datums erkennbar ist.
Habt ihr eine Idee wie ich das in vba implementieren kann?
Da ich Dateneingabe über ein Formular mache, würde ich als "event" - "after update" wählen.
Besten Dank!
Hallo,
müssen wirklich alle Felder der Tabelle historisiert werden ?
jede Änderung soll halt dadurch getrackt werden, dass die zugehörige Zeile in der Tabelle dupliziert wird.
Hallo,
ich habe das schon verstanden, das war ja aber nicht meine Frage.
Ja es soll jedes feld getrackt werden
Hallo,
anders gefragt: Kann auch in jedem Feld etwas geändert werden, oder sind das immer nur bestimmte und gleiche Felder in denen geändert wird ?
bis auf ein feld kann jedes geändert werden
Hallo,
im Einfachsten Fall kopierst Du den Datensatz und fügst diesen als neuen Datensatz an die Tabelle an. Wenn Du das Kopieren über eine Anfügeabfrage machst, kannst Du dabei gleich den Zeitstempel setzen und - sofern bekannt - auch gleich den User schreiben.
Eine Anfügeabfrage kannst Du im Entwurf zusammenklicken. Mit einem Kriterium auf den Primärschlüssel des aktuellen Datensatzes. Der Primärschlüssel darf aber nicht kopiert werden.
Gibt es nicht eine Möglichkeit dies über VBA/ SQL umzusetzen?
Danke!
Hallo,
mein Vorschlag ist VBA/SQL.
Woran scheiterst Du ?
Ich weiß nicht wie ich einen Datensatz über VBA kopiere und einen Zeitstempel hinzufüge...
Mein Problem ist, dass sich in der Zeile, also dem Record, z.b. nur ein Datenfeld ändern könnte. Wenn dies der Fall ist, soll die gesamte Zeile dupliziert werden und mit dem aktuellen Datum versehen in der gleichen Tabelle abgespeichert werden.
Jeder Datensatz ist somit über Datum um Name eindeutig identifizierbar.
Problem ist, ich weiß nicht wie ich nur in dem gerade kopierten/ duplizierten Datensatz das Datum verändern kann.
Public Sub historicize(tblCurr As String, indentifier As String, currRec)
Dim strSQL As String
strSQL = "INSERT INTO [tblProjects]" & _
"SELECT * FROM [tblProjects]" & _
"WHERE [Project_Name]= " & currRec
DoCmd.RunSQL (strSQL)
End Sub
Hallo,
in dem Du das Datum mit in die Anfügeabfrage aufnimmst und auf das heutige Datum setzt.
Datumsfeld = Date()
Statt RunSQL solltest Du besser Execute verwenden, damit erhält man auch zutreffende Fehlermeldungen.
CurrentDB.Execute strSQL, DbFailOnError
PS:
Ist [Project_Name] der Primärschlüssel ?
Du musst erst kopieren und dann den kopierten Datensatz ändern.
Hallo,
Zitatsoll die gesamte Zeile dupliziert werden und mit dem aktuellen Datum versehen in der gleichen Tabelle abgespeichert werden
das ist db_technischer Nonsense...
benutze eine separate Tabelle ("tblProjektHistorie"), in der die ID-Autowertfelder (falls der Primärschlüssel aus einem Autowertfeld besteht) aus "tblProjects" als vom Datentyp LONG deklariert sind. Zusätzlich ist in der Historie-Tabelle ein Datumsfeld mitzuführen ("PH_InsertDatum").
Public Sub historicize( lngPRID as Long)
Dim strSQL As String
strSQL = "INSERT INTO [tblProjects]" & _
" SELECT *, Date() as PH_InsertDatum FROM [tblProjects]" & _
" WHERE [Project_ID]= " & lngPRID
Currentdb.Execute strSQL
End Sub
und
Sub Form_Afterupdate()
Call historicize (Me!PRID)
End Sub
Wenn es eine n-Tabelle zu tblProjects gibt, so ist die natürlich auch passend zu berücksichtigen (kopieren)
Hi,
Zitat von: tobsn121 am September 08, 2015, 10:51:26 strSQL = "INSERT INTO [tblProjects]" & _
"SELECT * FROM [tblProjects]" & _
"WHERE [Project_Name]= " & currRec
so einfach geht es nicht, du musst jedes Feld einzeln angeben und dabei den Primärschlüssel (Autowert?) auslassen.
Nachtrag:
Den Vorschlag von Franz hatte ich auch schon im Sinn. In jedem Fall darf der Datensatzschlüssel natürlich nicht eindeutig indiziert werden, was für die Original-Tabelle wohl eine ziemliche Katastrophe wäre.