SQL Replikation - neue Spalten nicht replizieren

Hallo,

ich arbeite z.Z. an einem Replikations Modell für eine bzw. zwei NAV Datenbanken.
DB1 ist der Verleger in der z.B. in der Debitortabelle mehr Spalten vorhanden sind als in DB2 (Abo).
Das ganze funktioniert ohne Probleme wenn ich den Spalten die in DB1 "zu viel" sind, über SQL Standardwerte zuweise oder NULL-Werte zulasse.
Füge ich aber nun in DB1 eine neue Spalte hinzu wird diese automatisch mit repliziert und führt dann in DB2 zu einem Fehler da NAV die Spalte nicht kennt.
Gibt es die Möglichkeit neue Spalten autom. von der Replikation auszuschließen?

Desweiteren wüsste ich gerne ob man die SQL Properties "Standardwert" und "NULL-Werte zulassen" mittels NAV setzen kann?
Es gibt zwar die Properties "InitValue" und "NotBlank", aber diese wirken sich nicht auf die SQL Properties der Spalte aus.

Gruß
Christoph

Irgendwie habe ich ein sehr ungutes Gefühl bei der Geschichte ...

Könntest du eventuell uns erklären wie deine Replikation technisch aktuell laufen soll? Wir haben auch eine (Teile davon mit SQL), evtl. brauchst du nur einen etwas anderen Ansatz.

Danke, ich mittlerweile auch :)

Technisch soll das ganze natürlich auch über die SQL Replikation laufen.
Gewisse Tabellen sollen via Merge Replikation abgeglichen werden.

Beispiel:
Debitoren von DB1 in DB2 replizieren, in DB2 werden aber nicht alle Felder benötigt. Änderungen sollen in beiden DBs möglich sein.

Also ihr nutzt auch eine NAV Replikation mittels SQL?
Hey, endlich habe ich mal jemanden gefunden :)

Ich wollte zwar eine genauere Erklärung, aber nun gut ...

Bei uns handelt es sich um eine Replikation zwischen den Mandanten und nicht Datenbanken (das wäre aber auch genauso gut möglich). Ich hoffe doch sehr stark, dass du nicht direkt zwischen den Navision-Tabellen (Bsp.: Debitor T18) replizierst! Bei uns läuft es so: Wird ein Datensatz geändert, angelegt oder gelöscht (teilweise auch Rename), dann wird ein Replikationsdatensatz erstellt, dieser wird über SQL in den anderen Mandanten übertragen (einfach weil es schneller ist als Navision an der Ecke). Dort wird dieser Datensatz dann über einen NAS abgearbeitet.

Ich wollte zwar eine genauere Erklärung, aber nun gut ...

Was fehlt dir denn an Details?

Bei uns handelt es sich um eine Replikation zwischen den Mandanten und nicht Datenbanken (das wäre aber auch genauso gut möglich). Ich hoffe doch sehr stark, dass du nicht direkt zwischen den Navision-Tabellen (Bsp.: Debitor T18) replizierst!

Doch, genau das habe ich vor. Was spricht dagegen?

Bei uns läuft es so: Wird ein Datensatz geändert, angelegt oder gelöscht (teilweise auch Rename), dann wird ein Replikationsdatensatz erstellt, dieser wird über SQL in den anderen Mandanten übertragen (einfach weil es schneller ist als Navision an der Ecke). Dort wird dieser Datensatz dann über einen NAS abgearbeitet.

Wir sprechen aber beide über die in SQL integrierte Replizierung?
Hört sich für mich so an als hättet ihr euch eure eigene Replizierung auf SQL Tabellen Triggern gebaut!?

Jede NAV Spalte ist fix definiert mit "NOT NULL". Da geht kein Weg dran vorbei.

Welche SQL-interne Replikation ist dabei gemeint? Evtl. Log-Shipping?

Mir gefällt das wirklich überhaupt nicht. Es ist eine Unsitte Stammdaten direkt zu übertragen per SQL. Warum? Weil auf diese Weise keine Navision-Trigger ausgeführt werden.

Hi Christoph,

ich muss mich an der Stelle anschließen! Selbst wenn du die SQL Server Replikation benutzt, man schreibt einfach nicht direkt per SQL in NAV Tabellen. Das kann zu massiven Problemen führen!
Gründe gibt es zahlreiche dafür, zum einen werden keine Trigger (und damit keine Prüfungen) durchlaufen und zum anderen umgehst du auch sämtliche ggf. angewandten Change Logs (auch Trigger, ich weiß) und vernichtest ggf. vorgenommene Änderungen unwiederbringlich.

Ich denke der Ansatz von Sebastian ist da schon der richtige. Wenn zu replizierende Änderungen vorgenommen werden, schreibt man diese in eine Art Transfertabelle. Diese Tabelle existiert in der anderen Datenbank auch und wird z.B. über SQL Replikation an den/die Abonnenten verteilt. In der neuen Datenbank angekommen dann über einen NAS abarbeiten lassen und fertig. Das wäre auch hilfreich wenn sich zum Beispiel doch mal "gleichzeitig" in zwei Datenbanken derselbe Datensatz ändert.

Wenn ich so drüber nachdenke, kann man vielleicht auch die Change Log Entry Tabelle (zumindest vom Grundaufbau) als Transfertabelle verwenden um die Replikation durchzuführen und ggf. auftretende Konflikte zu mergen.

@ Sebastian:
Ich denke er meint die Standard SQL Server-Replikation (http://msdn.microsoft.com/de-de/library ... (v=sql.105).aspx)

Gruß,
Chris

P.S. Wir nutzen für die Übertragung übrigens Scribe als Middleware... nicht schön, funktioniert aber.

Welche SQL-interne Replikation ist dabei gemeint? Evtl. Log-Shipping?
Mir gefällt das wirklich überhaupt nicht. Es ist eine Unsitte Stammdaten direkt zu übertragen per SQL. Warum? Weil auf diese Weise keine Navision-Trigger ausgeführt werden.

Nein, ich meine die von Chris genannte SQL Replikation. Die Trigger werden ja vorher bereits durch NAV ausgeführt, anschließend überträgt die Replikation die Änderungen in die andere DB.
Relationale Tabellen die evtl. durch die Trigger geändert wurden müssen dabei natürlich auch repliziert werden.

@Chris: Hi Chris :)
Wir schreiben schon seit Jahren direkt von extern in NAV Tabellen und es ist noch nie zu Problemen gekommen.
Dabei werden aber unter anderem auch "Zwischen-Tabellen" genutzt.
Trigger die ggf. durch NAV ausgelöst werden müssen dann halt händisch in SQL oder in der ext. Anwendung abgebildet werden.
Ich finde die SQL Replizierung eigentlich eine feine Sache.
Deine Lösung hört sich auch gut an, aber stell dir das mal mit mindestens 10 Datenbanken vor so wie es bei uns dann der Fall sein wird.
Konflikte, also Änderungen am gleichen DS, können eigentlich nicht auftreten und wenn hat die SQL Replizierung dafür eine Konfliktlösung.

Gefällt mir immer noch nicht

Wie gesagt, ich würde nur in angelegte Zwischen-Tabellen direkt aus SQL befeuern (lesend ist eine andere Geschichte). Trigger nachzubilden ist auch nicht wirklich schön. Was, wenn jemand etwas in Navision ändert?

Mein Ansatz ist immer noch: Änderungsdatensätze schreiben und per SQL verteilen. NAS dann diese durchführen lassen.

Wie sehen das andere hier?

Hi Christoph,

mir gefällts auch nicht...

Gerade wenn es so viele Datenbanken sind würde ich dazu raten das Ganze nicht direkt in NAV Tabellen reinzuschreiben. Wir haben einen Stammdaten-Transfer (Artikel) mit 6 Datenbanken laufen und das ist quasi eine organisatorische Meisterleistung nach jeder NAV Änderung zu prüfen ob diese auch in den anderen Datenbanken passt. Dabei rede ich auch nicht nur von technischen Änderungen (Neue Felder, etc.) sondern auch von unterschiedlichen Einrichtungen (Buchungsgruppen, etc.), die ggf. nicht in die andere Datenbank übertragen werden können, da es sie dort gar nicht gibt. Mit entsprechenden Zwischentabellen, die sich nicht verändern kann man auch solche "ungeahnten" Konflikte sehr schön abfangen.
Einen großen Vorteil den ich noch sehe, ist dass bei Konflikten diese direkt in NAV aufgelöst werden können und kein weiteres Tool notwendig ist.

Ich hatte heute etwas "Leerlauf" und habe mal eine entsprechende Transfertabelle und die entsprechenden Routinen zusammengebaut um zu testen ob meine Gedanken auch in Wirklichkeit funktionieren. Ich habe dazu quasi die Change Log Entry Tabelle kopiert und befülle dort die Änderungen. Genau wie das Change Log habe ich mich dabei in die Global Trigger (Codeunit 1) reingehangen und konnte so auch konfigurieren und nicht programmieren, was übertragen werden soll.
Die Tabelle habe ich dann via SQL zwischen den Datenbanken ausgetauscht und auf der Empfängerseite per Codeunit (NAS) wieder eingespielt. Ich finde die Lösung jetzt schon sehr elegant, obwohl es noch sehr rudimentär ist.

Wenn du magst kann ich dir die Objekte mal zuschicken und dann kannst du dir ein Bild machen.

Schönes Wochenende
Chris

Hi Chris,

die ChangeLog Funktion kannte ich ehrlich gesagt noch gar nicht und ist auch in unserer DB nicht vorhanden.
Habe sie mir aber gerade mal in der Cronus angeschaut, und es sieht auf jeden Fall interessant aus.

Die SQL Replizierung habe ich aber trotzdem noch nicht ganz aufgegeben
Vielleicht können wir noch mal Telefonieren wenn du ein paar Minuten Zeit hast!?

Ein Treffen wäre ja auch noch mal angesagt oder? ;)

Gruß

Ahh... dann ist das wirklich der richtige Christoph

Klar können wir bei Gelegenheit mal machen... Nummer hast du ja, feel free!

Wenn ein Christoph den anderen findet

wir waren mal Kollegen