Datenänderungen in DB an einem MS SQL 2012 nachverfolgen?
AdminKnecht (Level 1) - Jetzt verbinden
18.02.2016, aktualisiert 19.02.2016, 1239 Aufrufe, 6 Kommentare
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
Antworten
- Mehr
Auf Facebook teilen
Auf Twitter teilen6 Antworten
- LÖSUNG ukulele-7 schreibt am 18.02.2016 um 15:53:08 Uhr
- LÖSUNG AdminKnecht schreibt am 19.02.2016 um 09:43:07 Uhr
- LÖSUNG ukulele-7 schreibt am 19.02.2016 um 09:57:52 Uhr
- LÖSUNG AdminKnecht schreibt am 19.02.2016 um 09:43:07 Uhr
- LÖSUNG wiesi200 schreibt am 18.02.2016 um 16:21:59 Uhr
- LÖSUNG AdminKnecht schreibt am 19.02.2016 um 09:44:26 Uhr
- LÖSUNG wiesi200 schreibt am 19.02.2016 um 11:20:50 Uhr
- LÖSUNG AdminKnecht schreibt am 19.02.2016 um 09:44:26 Uhr
LÖSUNG 18.02.2016, aktualisiert 19.02.2016
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.
LÖSUNG 18.02.2016, aktualisiert 19.02.2016
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.
LÖSUNG 19.02.2016 um 09:43 Uhr
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
LÖSUNG 19.02.2016 um 09:44 Uhr
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
LÖSUNG 19.02.2016 um 09:57 Uhr
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.
LÖSUNG 19.02.2016 um 11:20 Uhr
