<\/HEAD>
Als Support-Analyst erhalten wir eine Reihe von interessanten Problemen zur Überprüfung. Diese Probleme können spezifisch für die Umgebung des Benutzers, Daten, Arbeitsabläufe usw. sein. Manchmal bemerken wir einen Anstieg von Anrufen, die sich auf einen einzelnen Workflow beziehen. Wenn dies passiert, überprüfen wir die Ressourcen, die unseren Benutzern zur Verfügung stehen, und stellen sicher, dass die Dokumentation klar beschreibt, wie Workflows ausgeführt werden.<\/P>
Eines dieser Workflow-Probleme, das wir kürzlich im Callcenter gesehen haben, betrifft die Arbeit mit Schemaänderungen in Replikaten. Zum Beispiel stellt man nach dem Erstellen eines Replikats fest, dass man ein Feld zu einer bestimmten Feature-Class hinzufügen oder eine Domain entfernen muss, die nicht mehr erforderlich ist. Dieser Blog soll diesen Workflow mit einigen Tricks intuitiver machen, die den Replica-Gurus da draußen helfen, effizient mit Schemaänderungen umzugehen.<\/P>
Lassen Sie uns überprüfen: wenn ein Replikat erstellt wird, werden die Daten und das Schema der replizierten Objekte in der übergeordneten Geodatabase und der untergeordneten Geodatabase registriert. Die Daten sind als Zeilen in der Tabelle definiert und verwenden die GlobalId-Werte als Verbindung zwischen Eltern- und Kindobjekt, während das Schema aus den Feldern, Domains, Subtypen und anderen Eigenschaften besteht, die die replizierten Daten beschreiben. Denken Sie daran, wenn Sie die Distributed Geodatabase-Symbolleiste in ArcMap verwenden, um das Replikat zu erstellen und die Option "Nur vorhandene Daten registrieren" wählen, kann das Replikat bei der Erstellung unterschiedliche Schemata aufweisen. Dies ist erlaubt, da einige Organisationen dieses Diagramm benötigen. Es liegt also am Ersteller des Replikats sicherzustellen, dass die Daten vor der Erstellung des Replikats auf ihre eigenen Bedürfnisse vorbereitet sind.
Idealerweise sind die Schemata bei der Erstellung des Replikats auf beiden Seiten identisch, aber im Laufe der Zeit können Änderungen an jedem Replikatschema vorgenommen werden. Zum Beispiel benötigt ein Replikat möglicherweise zusätzliche Felder zur Fertigstellung eines Projekts, während das entsprechende Replikat eine neue Domain auf ein bestehendes Feld anwenden muss. Wenn dies geschieht, sind die Schemata der Replikate nicht mehr gleich. Es ist nicht erforderlich, dass die Schemata in der übergeordneten und untergeordneten Geodatabase identisch sind; jedoch können unerwartete Verhaltensweisen auftreten, wenn Unterschiede nicht beabsichtigt sind.
Was kann passieren, wenn es Schemaunterschiede in den replizierten Daten gibt?
- Bearbeitungen werden nicht synchronisiert<\/STRONG> - Die Datensynchronisation importiert nur Änderungen für Tabellen und Felder, die in beiden Replikaten gemeinsam sind.Hinweis: Wenn Schemata beim Synchronisieren der Daten nicht übereinstimmen, wird die Datenübertragung als an das entsprechende Replikat gesendet markiert. Denken Sie daran: Replikate müssen keine übereinstimmenden Schemata haben, aber alle Bearbeitungen werden während der Synchronisation als synchronisiert markiert, unabhängig davon, ob es ein entsprechendes Schema (z.B. ein Feld) im relativen Replikat gibt, um die Bearbeitungen zu empfangen.<\/EM><\/EM><\/LI><\/UL><\/LI>Ungültige Werte<\/STRONG> - Änderungen, die gegen Domains, Subtypen, Konnektivitätsregeln und Beziehungsregeln verstoßen, werden bei der Synchronisierung angewendet. Die <\/STRONG>Validierungstools<\/A><\/STRONG> im Editor können verwendet werden, um die neu importierten Werte zu überprüfen.<\/LI>Fehler bei der Datensynchronisation - <\/STRONG>Dies kann passieren, wenn Sie manuell eine Schemaänderung an beiden Replikaten vornehmen. Zum Beispiel möchten Sie vielleicht ein Feld zu einer Tabelle hinzufügen. Wenn Sie dies tun, stellen Sie sicher, dass Sie dieselbe Schemaänderung in allen Fällen vornehmen. Wenn es Unterschiede gibt (z.B. ist ein Feld in einem Replikat ein String und im anderen ein Integer), tritt ein Fehler bei der Datensynchronisation auf.
<\/A> Synchronisationsfehler aufgrund nicht übereinstimmender Feldtypen zwischen den Replikaten.<\/P><\/DIV><\/LI><\/UL>
- Nicht unterstützte Änderungen - <\/STRONG>Einige Arten von Schemaänderungen können dazu führen, dass die Synchronisation fehlschlägt, ohne dass eine Warnung angezeigt wird. Diese Änderungen sind vom Geodatabase-Replikationssystem nicht erkennbar. Dazu gehören Operationen auf Datenbankebene wie das Ändern von Berechtigungen für Tabellen in der Datenbank. Wenn Berechtigungen für replizierte Daten auf Nur-Lesen geändert werden, tritt beim Importieren von Änderungen aus dem relativen Replikat ein Fehler auf.<\/LI><\/UL>Anwenden von Schemaänderungen über Replikate hinweg - <\/STRONG>Das Ändern des Schemas eines Replikats zur Übereinstimmung mit dem Schema eines relativen Replikats ist ein völlig separater Prozess von der Datensynchronisation. Wenn Sie glauben, dass Sie einige der oben beschriebenen unerwarteten Verhaltensweisen erleben, können Sie folgende Werkzeuge verwenden.
Drei Werkzeuge stehen zur Verfügung, um Replica-Schemata zu aktualisieren:
Export Replica Schema<\/A> <\/STRONG>- Wird verwendet, um das Schema aus der Geodatabase zu exportieren, die das Schema enthält, das auf das relative Replikat angewendet werden soll. Typischerweise nur für getrennte Umgebungen oder Skripting verwendet.<\/LI>Compare Replica Schema<\/A><\/STRONG> - Wird verwendet um Unterschiede zwischen den beiden Geodatabases im Replikat zu finden. Dies wird immer von der Geodatabase aus durchgeführt, auf die die Änderungen angewendet werden sollen. Dies ist der erste Schritt bei Arbeit in einer verbundenen Umgebung.<\/LI>Import Replica Schema<\/A> <\/STRONG>- Wird verwendet um während des Replica-Vergleichs gefundene Unterschiede in die Geodatabase zu importieren auf welche die Änderungen angewendet werden sollen.<\/LI><\/OL>
Die Werkzeuge sind im Kontextmenü per Rechtsklick auf Distributed Geodatabase im Katalogbaum verfügbar sowie in der Distributed Geodatabase-Symbolleiste in ArcMap und als Geoverarbeitungswerkzeuge.
<\/A> Kontextmenü per Rechtsklick auf Distributed Geodatabase in ArcCatalog<\/P><\/DIV>
Distributed Geodatabase-Symbolleiste in ArcMap<\P>
Geoverarbeitungswerkzeuge für Datenmanagement<\P>
Es ist wichtig zu beachten, dass es sehr geringe Unterschiede zwischen diesen drei Methoden gibt. Zum Beispiel listet der Import Replica Schema-Assistent im Kontextmenü per Rechtsklick auf Distributed Geodatabase aus ArcCatalog und in der Distributed Geodatabase-Symbolleiste in ArcMap die Änderungen auf, die der Benutzer anwenden oder nicht anwenden kann. Die Geoverarbeitungswerkzeuge (die häufiger in getrennten Umgebungen oder automatisierten Skriptprozessen verwendet werden) tun dies nicht.
Zuletzt sollte beachtet werden, dass die Geoverarbeitungswerkzeuge typischerweise in einem dreistufigen Prozess (Exportieren, Vergleichen und Importieren) verwendet werden und meist dann zum Einsatz kommen wenn dieser Prozess Teil einer geplanten Aufgabe ist. Die Distributed Geodatabase-Symbolleiste in ArcMap und das Kontextmenü per Rechtsklick auf Distributed Geodatabase können in einer verbundenen Umgebung mit nur zwei Schritten (Vergleichen und Importieren) verwendet werden.
Obwohl das Weglassen des Schrittes Export Replica Schema Zeit sparen kann – falls Zweifel bestehen welches Geodatabase-Schema als Eingabe für die Werkzeuge dienen soll oder welche Änderungen propagiert werden – finde ich persönlich den dreistufigen Geoverarbeitungswerkzeug-Ansatz oft intuitiver. Das erste Werkzeug ist immer das Export Schema Changes-Geoverarbeitungswerkzeug. Dieses Werkzeug hat nur eine Eingabe-Geodatabase (diejenige mit dem Schema welches zum relativen Replikat propagiert werden soll) und erzeugt eine einzelne XML-Ausgabedatei.
Nun führen wir das Compare Replica Schemas-Geoverarbeitungswerkzeug aus wobei unsere Eingabe die relative Geodatabase und die XML-Datei ist, die wir gerade erstellt haben. Die Ausgabe für das Geoverarbeitungswerkzeug Compare Replica Schema ist eine einzelne XML-Datei. Schließlich besteht unser dritter Schritt darin, das Import Replica Schema auszuführen. Unsere Eingabe wird eine Geodatabase sein – relativ zu der Eingabe, die wir im Export Replica Schema-Werkzeug eingeben, und die compare.XML, die wir gerade erstellt haben. Obwohl die Geoverarbeitungswerkzeuge nicht über die organisierte Benutzeroberfläche verfügen, die die erkannten Schemaunterschiede auflistet, kann diese Methode jede Verwirrung darüber klären, woher die Änderungen stammen und wohin sie gesendet werden.Siehe Ressourcendokumente:<\/STRONG>Arbeiten mit Schemaänderungen<\/A><\/STRONG><\/STRONG><\/LI>Schemaänderungen<\/A><\/STRONG><\/STRONG><\/LI><\/UL>Tina M. - Geodaten-Support-Analystin<\/EM>
<\/BODY><\/HTML>
