Das hier ist etwas, das ich gerne auch in der Replikations-FAQ sehen würde, weil es anscheinend noch *nirgendwo* dokumentiert ist. Ich arbeite daran... :-)
Beim Erstellen einer Dropbox für die indirekte Synchronisierung, entweder im Replikations-Manager oder im TSI Synchronizer, kann man nicht nur Werte auswählen in der Form
\\server\share
Es ist auch möglich
\\server\share\path
oder
\\server\share\path\subpath
und ähnliche Dinge. Es gibt keine Doku, die sagen würde, dass es nicht geht, und es ist verständlich und vernünftig solche Dinge zu wollen. Wenn man dem Rat vieler Leute folgen würde und alle Dropboxen (die des Servers und die aller Clients) am Server haben möchte, bräuchte man nicht Unmengen von Shares.
ABER MACHEN SIE DAS BLOSS NICHT!!!
Es scheint, als hätten Teile des Codes von Jet keine Probleme mit solchen Einstellungen und wenn Sie versuchen, eine indirekte Synchronisierung durchzuführen, werden einige Meldungen erscheinen, und der Status der Synchronisierung wird "Fortschritte machen". Das war's dann aber auch, denn andere Teile des Jet-Synchronzers und des Replikationscodes kommen mit dieser Syntax nicht zurecht und die Synchronisierung wird nie zu Ende geführt. Sie werden die "verwaisten" Meldungen in der Dropbox sehen, die nicht mehr abgeholt werden.
Sie müssen sich beschränken auf
\\server\share
ohne zusätzliche Pfade, und jeder Synchronizer muss seinen eigenen, eindeutigen Share für seine Dropbox haben.
Für Leute, die NT auf ihrem Server nutzen und nicht Tonnen von Shares definieren möchten, ist die beste Methode, Shares für die Dropboxen mit
\\Server\ShareName$
zu erzeugen, da $ den Share für die meisten Anwender unsichtbar macht aber zugänglich für jeden, der möchte. Das sorgt bei vielen Shares für Ordnung und stellt einen brauchbaren Workaround dar.
ZUKÜNFTIGE VERSIONEN des TSI Synchronizers werden so programmiert sein, dass sie einen Laufzeitfehler melden, wenn Sie beim Setzen der Synchronizer::IndirectDropbox-Eigenschaft einen solchen Pfad für die indirekte Dropbox angeben. Das wird hoffentlich einigen Leuten helfen. Wenn die FAQ diese Info übernehmen könnte und vielleicht auch die MS-Knowledgebase, würde sie vielleicht von mehr Leuten gelesen (evtl. gibt es einen KB-Artikel darüber, aber ich konnte keinen finden).
Vielleicht würde der Bug ja sogar eines Tages gefixt werden? :-)
