SQL Replikation - neue Spalten nicht replizieren

Bild Speziell fĂĽr Probleme der SQL-Server-Integration in die Dynamics Produkte

SQL Replikation - neue Spalten nicht replizieren

Beitragvon ChristophE » 20. März 2013 14:39

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
Benutzeravatar
ChristophE
 
Beiträge: 131
Registriert: 30. Juni 2008 11:02
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: <=2018

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon Sebastian Pfliegel » 20. März 2013 15:29

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.
Sebastian Pfliegel
 
Beiträge: 792
Registriert: 25. Februar 2008 12:59
Realer Name: Sebastian
Arbeitsort: Schwabach
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 4.0

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon ChristophE » 21. März 2013 08:10

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 :)
Benutzeravatar
ChristophE
 
Beiträge: 131
Registriert: 30. Juni 2008 11:02
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: <=2018

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon Sebastian Pfliegel » 21. März 2013 11:45

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

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.
Sebastian Pfliegel
 
Beiträge: 792
Registriert: 25. Februar 2008 12:59
Realer Name: Sebastian
Arbeitsort: Schwabach
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 4.0

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon ChristophE » 21. März 2013 11:53

Sebastian Pfliegel hat geschrieben:Ich wollte zwar eine genauere Erklärung, aber nun gut ... :mrgreen:


Was fehlt dir denn an Details? :wink:

Sebastian Pfliegel hat geschrieben: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?

Sebastian Pfliegel hat geschrieben: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? :wink:
Hört sich für mich so an als hättet ihr euch eure eigene Replizierung auf SQL Tabellen Triggern gebaut!?
Benutzeravatar
ChristophE
 
Beiträge: 131
Registriert: 30. Juni 2008 11:02
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: <=2018

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon JanGD » 21. März 2013 12:04

Jede NAV Spalte ist fix definiert mit "NOT NULL". Da geht kein Weg dran vorbei.
JanGD
 
Beiträge: 1765
Registriert: 19. März 2008 12:33
Arbeitsort: NRW
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2013R2

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon Sebastian Pfliegel » 21. März 2013 15:07

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.
Sebastian Pfliegel
 
Beiträge: 792
Registriert: 25. Februar 2008 12:59
Realer Name: Sebastian
Arbeitsort: Schwabach
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 4.0

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon Christoph » 21. März 2013 17:26

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. :wink:
Christoph
 
Beiträge: 62
Registriert: 2. August 2007 15:14
Arbeitsort: Bonn
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 3.70 - 2018, BC

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon ChristophE » 22. März 2013 08:36

Sebastian Pfliegel hat geschrieben: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.
Benutzeravatar
ChristophE
 
Beiträge: 131
Registriert: 30. Juni 2008 11:02
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: <=2018

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon Sebastian Pfliegel » 22. März 2013 14:03

Gefällt mir immer noch nicht :-P

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?
Sebastian Pfliegel
 
Beiträge: 792
Registriert: 25. Februar 2008 12:59
Realer Name: Sebastian
Arbeitsort: Schwabach
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 4.0

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon Christoph » 22. März 2013 20:20

Hi Christoph,

mir gefällts auch nicht... :wink:

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. :mrgreen:

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

Schönes Wochenende
Chris
Christoph
 
Beiträge: 62
Registriert: 2. August 2007 15:14
Arbeitsort: Bonn
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 3.70 - 2018, BC

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon ChristophE » 25. März 2013 11:14

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 8-)
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Ăź
Benutzeravatar
ChristophE
 
Beiträge: 131
Registriert: 30. Juni 2008 11:02
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: <=2018

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon Christoph » 25. März 2013 16:39

Ahh... dann ist das wirklich der richtige Christoph :wink:

Klar können wir bei Gelegenheit mal machen... Nummer hast du ja, feel free!
Christoph
 
Beiträge: 62
Registriert: 2. August 2007 15:14
Arbeitsort: Bonn
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 3.70 - 2018, BC

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon Sebastian Pfliegel » 25. März 2013 23:23

Wenn ein Christoph den anderen findet :mrgreen:
Sebastian Pfliegel
 
Beiträge: 792
Registriert: 25. Februar 2008 12:59
Realer Name: Sebastian
Arbeitsort: Schwabach
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 4.0

Re: SQL Replikation - neue Spalten nicht replizieren

Beitragvon ChristophE » 26. März 2013 09:41

wir waren mal Kollegen :wink:
Benutzeravatar
ChristophE
 
Beiträge: 131
Registriert: 30. Juni 2008 11:02
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: <=2018


ZurĂĽck zu Microsoft SQL-Server

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast