Hallo zusammen,
ich bin heute über ein Problem gestolpert, das nur auf Tabellen mit Filestream-Spalten auftritt.
Wenn ich solch eine Tabelle als Artikel in der Merge-Replikation habe, dann erstellt SQL Server eine Konflikttabelle, die anders aussieht als bei denen ohne FILESTREAM-Spalte. Bei letzteren gibt es keinen Primary Key, sondern nur einen zusammengesetzten Schlüssel bestehend aus dem Primary Key der Artikeltabelle und der Spalte data_source_origin. Macht ja auch Sinn - denn nur so können Konflikte aus unterschiedlichen Abonnennten gespeichert werden.
Für den Artikel mit FILESTREAM-Spalte hingegen erstellt die Merge-Replikation auf der zugehörigen Konflikt-Tabelle einen Unique Key auf der Rowguid-Spalte der Ausgangstabelle. Muss ja auch, denn die Regeln für eine Tabelle mit Filestream-Spalten besagen, dass es einen UK auf der ROWGUID-Spalte geben muss - und letztlich entspricht die Konflikt-Tabelle ja der Ausgangstabelle. Die Spalte data_source_origin findet hier hingegen keine Verwendung, was zur Folge hat, dass auf dem Verleger nur ein konfliktierender Abonnent protokolliert werden kann. Kommt ein zweiter mit einer Änderung auf dem gleichen Datensatz, kommt es zur Schlüsselverletzung auf dem UK der Konflikttabelle und der ganze Synchronisationsvorgang schlägt fehl bis der Konflikt manuell aufgelöst bzw. aus der Konflikttabelle entfernt worden ist.
Jetzt könnte man versuchen als Workaround die Tabelle zu droppen und mit eine UK auf ROWGUIDCOL und data_source_origin neu zu erstellen - geht aber auch nicht, weil data_source_origin NULLABLE ist.
Der Hintergrund ist auch klar - unter der ROWGUIDCOL (oder dem UK?) werden die Dateien im FILESTREAM abgelegt - gäbe es zwei mit gleichem Schlüssel, würden die Dateien sich überschreiben.
Hat jemand hierzu schon mal eine Lösung gesehen oder gibt es hierzu vielleicht einen Bugreport bei Microsoft? Ich bekomme das Verhalten in allen Versionen von 2012-2017 - also ein durchaus altes "Feature".