6
Datenänderungen in DB an einem MS SQL 2012 nachverfolgen?
Hallo zusammen,
ich arbeite mich zur Zeit in Dynamics NAV 2013 R2 und der dazugehörenden DB auf einem MS SQL 2012 (Express Edition) ein (Testumgebung), und möchte nun die Daten-Änderungen im Client in der DB nachverfolgen können (z.B. welche Felder in welchen Tabellen werden angefasst wenn ich in den Stammdaten die Postleitzahl ändere .......)
Gibt es eine Möglichkeit das ohne große Verrenkungen hinzubekommen, anhand von LOGs o.ä.? Ich bin jetzt nicht der ausgewiesene SQL-Server-Freak....
Danke euch schon mal
Marcus
ich arbeite mich zur Zeit in Dynamics NAV 2013 R2 und der dazugehörenden DB auf einem MS SQL 2012 (Express Edition) ein (Testumgebung), und möchte nun die Daten-Änderungen im Client in der DB nachverfolgen können (z.B. welche Felder in welchen Tabellen werden angefasst wenn ich in den Stammdaten die Postleitzahl ändere .......)
Gibt es eine Möglichkeit das ohne große Verrenkungen hinzubekommen, anhand von LOGs o.ä.? Ich bin jetzt nicht der ausgewiesene SQL-Server-Freak....
Danke euch schon mal
Marcus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 296664
Url: https://administrator.de/forum/datenaenderungen-in-db-an-einem-ms-sql-2012-nachverfolgen-296664.html
Ausgedruckt am: 27.12.2024 um 09:12 Uhr
6 Kommentare
Neuester Kommentar
Die Information wer was wann ändert wird vom SQL Server zunächst mal nicht gespeichert. Man kann das aber bei Interesse mit loggen, dazu wird in der Regel ein Trigger verwendet, der eine Log Tabelle füllt.
So ein Trigger hat ein paar Besonderheiten, ist aber im wesentlichen Fleisarbeit. Je nachdem ob er bei einer Änderung die ganze Zeile loggt oder nur die Einträge, die sich auch wirklich ändern.
So ein Trigger hat ein paar Besonderheiten, ist aber im wesentlichen Fleisarbeit. Je nachdem ob er bei einer Änderung die ganze Zeile loggt oder nur die Einträge, die sich auch wirklich ändern.
Hallo,
schnapp dir ne Testversion vom großen SQL und nutze den Profiler.
Ansonsten hat NAV (zumindest war's beim Classic Client so) nen guten Debugger intern. Da kann man das meiste nachverfolgen.
schnapp dir ne Testversion vom großen SQL und nutze den Profiler.
Ansonsten hat NAV (zumindest war's beim Classic Client so) nen guten Debugger intern. Da kann man das meiste nachverfolgen.
Moin,
ja, das mit dem Einsatz eines Triggers auf den nachzuverfolgenden Tabellen hatte ich auch schon gegoogelt, ist natürlich erstmal machbar, allerdings müsste man dann auf jeder Tabelle einen Trigger errichten, bei der Anzahl von Tabllen in der NAV-DB ein Wochenend-füllendes Unterfangen
Trotzdem vielen Dank erstmal,
Marcus
ja, das mit dem Einsatz eines Triggers auf den nachzuverfolgenden Tabellen hatte ich auch schon gegoogelt, ist natürlich erstmal machbar, allerdings müsste man dann auf jeder Tabelle einen Trigger errichten, bei der Anzahl von Tabllen in der NAV-DB ein Wochenend-füllendes Unterfangen
Trotzdem vielen Dank erstmal,
Marcus
Hallo,
das mit dem Profiler probiere ich mal aus!
Wir setzen den RTC ein, gibt es da auch eine Möglichkeit zu Debuggen? Oder mit anderen Tools aus dem NAV-Werkzeugkasten?
Viele Grüße
Marcus
das mit dem Profiler probiere ich mal aus!
Wir setzen den RTC ein, gibt es da auch eine Möglichkeit zu Debuggen? Oder mit anderen Tools aus dem NAV-Werkzeugkasten?
Viele Grüße
Marcus
Ja Log Trigger sind viel Arbeit, vor allem wenn man jede Spalte seperat sauber loggen will. Das liegt hauptsächlich daran das man Spaltennamen nicht irgendwie dynamisch in Code packen kann. Ich hatte mir in meinem Fall ein SQL Script zum erzeugen von Triggern gebaut, das selbst ist aber schon viel Aufwand da würde ich erstmal eine schmale Lösung empfehlen.
SQL Profiler ist manchmal nützlich aber sehr unübersichtlich wenn die DB viel macht.
SQL Profiler ist manchmal nützlich aber sehr unübersichtlich wenn die DB viel macht.
