Wann kann die Versionierung mit ArcSDE abgebrochen oder abgelehnt werden?

Ich verwende ArcGIS 9.3.1 und versuche, mit einer SDE-Geodatabase (mit einer Polygon-Feature-Class) zu arbeiten, die bereits als versioniert registriert wurde. Ich bin neu in der Versionierung und versuche immer noch, einige der grundlegenden Funktionen herauszufinden. Bisher konnte ich nicht feststellen, ob es möglich ist, bestimmte Änderungen abzubrechen oder abzulehnen, sobald sie in einer übergeordneten Version veröffentlicht wurden.

Angenommen, wir haben drei Versionen: das ursprüngliche SDE.DEFAULT, das erstellt wurde, als es als versioniert registriert wurde, eine untergeordnete Version des Standards mit dem Namen SDE.QA (für Qualitätssicherung) und eine untergeordnete Version der QA mit dem Namen SDE .Edit1 (wo die Änderungen zuerst stattfinden). Wenn bestimmte Funktionen von SDE.Edit1 bearbeitet wurden (z. B. um es einfach zu halten, nehmen wir an, ein Polygon wurde hinzugefügt und eines entfernt), und dann wurde SDE.Edit1 mit SDE.QA abgeglichen und anschließend an SDE.QA gesendet Gibt es eine Möglichkeit, diese Änderung später rückgängig zu machen? Wäre es im Anschluss an diese Frage möglich, nur einige Änderungen abzulehnen ? Akzeptieren Sie beispielsweise das Hinzufügen des ersten Poly, lehnen Sie jedoch das Entfernen des zweiten Poly ab?

Soweit ich weiß, sind alle diese Änderungen nach dem Veröffentlichen von Änderungen in der übergeordneten Version ein "dauerhafter" (mangels eines besseren Wortes) Teil der übergeordneten Version. Mir ist bekannt, dass diese Änderungen alle in zwei Tabellen aufgezeichnet werden, den Tabellen "ADD" und "DELETE" (häufig als "Delta" -Tabellen bezeichnet), und dass die ursprüngliche FC selbst nicht geändert wird. Ich habe überlegt, diese Delta-Tabellen manuell zu ändern, aber ich habe genug Leute gefunden, die davor gewarnt haben, um zu wissen, dass es wahrscheinlich nicht die richtige Lösung ist.

Vielleicht ist es mein Verständnis der Versionierung, das etwas Arbeit erfordert, aber ich konnte anscheinend keinen Weg finden, eine Änderung abzulehnen oder rückgängig zu machen, sobald sie veröffentlicht wurde. Dies kommt mir seltsam vor, da dies bedeuten würde, dass es keine Möglichkeit gibt, einen fehlerhaften Beitrag rückgängig zu machen. Ich kann auch keine Möglichkeit finden, die Herkunft dieser Versionen zu verfolgen (dh welche Version ist das Kind von welchem ​​Elternteil). Während ich mich mit diesem Thema befasse, wäre es sehr dankbar, wenn jemand etwas über besonders nützliche ArcSDE-Verweise (Links, Artikel, Bücher usw.) erfahren würde, die mir beim Verständnis von ArcSDE helfen (und möglicherweise einige dieser Fragen beantworten) !

Obwohl die bisherigen Antworten hilfreich waren (danke für die Links), kann ich immer noch keine Antwort auf den Kern meiner Frage finden. Wieder ist es vielleicht mein eigenes Missverständnis der Situation. Folgendes möchte ich wissen:

Können Sie einen Beitrag rückgängig machen, nachdem er von einer untergeordneten Version in eine übergeordnete Version geändert wurde? In diesem Szenario kann, muss aber nicht, die übergeordnete Version die SDE.DEFAULT-Version sein. Noch besser, ich würde gerne wissen, ob Sie einen Teil eines Posts (z. B. eine einzelne Bearbeitung in einem Polygon) rückgängig machen können , nachdem er veröffentlicht wurde. Ich würde auch gerne wissen, ob dies möglich ist, ohne dass Konflikte festgestellt werden müssen.

Die Tatsache, dass ich keine eindeutige Antwort auf diese Frage (dh "Ja" oder "Nein") finden kann, die irgendwo dokumentiert ist, lässt mich glauben, dass mir etwas Wichtiges an der Versionierung in ArcSDE fehlt. Ich würde es auch vorziehen, die A- und D-Tabellen nicht manuell zu manipulieren.

Pfui. Die Antwort ist wirklich kompliziert und erfordert viel ArcSDE-Hintergrund. Ich werde versuchen, mich so kurz wie möglich zu fassen.

Hinweis: Ich beziehe mich auf einige Diagramme aus dem Super Awesome Versioning Whitepaper, das Sie auf der ESRI-Website finden . Wenn Sie sich mit der Versionierung beschäftigen, empfehle ich Ihnen dringend, diese gründlich durchzulesen.

Dann müssen Sie die Beziehung zwischen einem Zustand (dh einem Knoten aus dem Zustandsbaum) und einer benannten Version (dh einer Bezeichnung, die auf einen Zustand zeigt) verstehen .

Eine typische Datenbank kann wie folgt aussehen:

Hier haben Sie vier Versionen in der Datenbank (Version A, Version B, Version C und DEFAULT). Aber vielleicht bin ich ein bisschen vor mir. Beginnen wir mit dem, was ein Staat ist.

Sie können sich einen Zustand als "Transaktion" vorstellen - eine logische Einheit, die mehrere Änderungen an einer oder mehreren Tabellen enthält. Es kann zwei Einfügungen in "FeatureClass A", eine Löschung aus "Feature Class B" und eine Änderung (effektiv eine Löschung + eine Einfügung) in "Feature Class X" enthalten. Alles in einem zusammengefasst.

Schauen wir uns ein kleines, einfaches ArcSDE-Zustandsdiagramm an, das mit der Zustands-ID 0 beginnt:

Wenn Sie bei Status 0 beginnen und eine oder mehrere Tabellen in einer Bearbeitungsoperation bearbeiten, erstellen Sie einen untergeordneten Status 1 und legen diesen als aktuelle aktive Status-ID fest . Eine weitere nachfolgende Gruppe von Änderungen erstellt den untergeordneten Status 2. Wenn Sie den Vorgang rückgängig machen möchten, müssen Sie die Status-ID in keiner Weise ändern. Sie müssen lediglich die aktuelle aktive Status-ID in 1 oder 0 ändern (je nach Status) wie weit willst du zurück gehen). Ein Redo ist das Gegenteil - verschieben Sie einfach die aktuelle aktive Status-ID nach vorne - so weit nach vorne, wie Sie möchten.

So funktioniert das Rückgängigmachen / Wiederherstellen in der ArcSDE-Versionierung.

OK, mach weiter. Angenommen, Sie möchten eine Bearbeitung permanent machen (dh Sie möchten sie speichern). Was hast du zu tun? Beim Speichern wird lediglich ein Versionsetikett abgerufen und in einen bestimmten Status verschoben. Ein bisschen wie es zu stempeln und zu sagen "So muss Version A aussehen". Wenn Sie also auf das erste Diagramm zurückblicken, werden Sie feststellen, dass es vier benannte Versionen hat .

• Version B zeigt auf Status-ID 1
• Version A zeigt auf ID 3
• Version C zeigt auf Status-ID 5

• Die Version "SDE.DEFAULT" zeigt auf die Status-ID 4

  Bitte beachten Sie, dass dieses Diagramm trotz allgemeiner Überzeugung nichts über die logische Eltern-Kind-Beziehung aussagt, die sie haben. Die logische Parent-Child-Beziehung für das erste Diagramm könnte folgendermaßen aussehen:

Dies ist die Eltern-Kind-Beziehung, die Sie in ArcMap / ArcCatalog sehen. Ziel ist es, die Versionen einzuschränken, mit denen Sie abgleichen können. Zu diesem Zeitpunkt könnten Sie sich (zu Recht) fragen, warum zum Teufel brauche ich das? Die Antwort liegt in der Versionierung von Workflows . Es stellt sich heraus, dass die Leute schon seit einiger Zeit die Versionierung verwenden und es einige bevorzugte Möglichkeiten gibt, diese zu strukturieren, aber das ist ein Thema für einen anderen Tag, da ich Ihre Frage heute beantworten möchte :)

Weitermachen ...

OK, was machen diese benannten Versionen sonst noch? Nun, sie beeinflussen, wie sich dieser als Komprimieren bezeichnete Prozess verhält.

Bei der Komprimierung geht es darum, nicht benötigte Zwischenzustände zu erfassen, unnötige zu entfernen und zu kombinieren. Sie können den ArcSDE-Komprimierungsvorgang über ArcCatalog auslösen, einen Dienst einrichten, der dies von Zeit zu Zeit ausführt, und einige ArcMap-Bearbeitungsvorgänge lösen Minikomprimierungsvorgänge aus (dh nur für kleine Verzweigungen, die verwendet werden).

Das Diagramm links zeigt einen Statusbaum, bevor er komprimiert wird, und das Diagramm rechts zeigt ihn, nachdem er komprimiert wurde:

Ein wichtiges zu verstehendes Konzept (auf das ich Sie später noch verweisen werde) ist, dass jeder einzelne Staat ein potenzieller Kandidat für die Komprimierung ist - mit Ausnahme von Staaten, auf die Labels (dh benannte Versionen) verweisen .

Sie können sehen, dass es vor dem Komprimieren einige unnötige Zustände gibt. Tatsächlich wurde der gesamte [3,4,5] Zweig entfernt. Hätte es bei 5 eine benannte Version gegeben, wäre das Endergebnis sehr unterschiedlich ausgefallen.

Mit Komprimierungsvorgängen können Sie Speicherplatz in Ihrer Datenbank sparen, indem Sie nicht mehr benötigte Datensätze entfernen.

OK, mach weiter.

Das letzte Konzept, das Sie verstehen müssen, ist der Abgleich, der effektiv zwei Zweige zu einem vereint.

Kehren wir also zu unserem ersten Diagramm zurück. Angenommen, Sie möchten Version A mit SDE.DEFAULT abgleichen.

Fassen wir Folgendes zusammen: Vier benannte Versionen, die auf verschiedene Status-IDs verweisen. Das erste, was wir tun müssen, ist, einen untergeordneten Status unter der Zielversion zu erstellen. Daher erstellen wir einen untergeordneten Status unter Status-ID 4. In unserem Beispiel bezeichne ich diesen Status als ID 20.

Der nächste Schritt besteht darin, die Unterschiede zwischen beiden Versionen zu berechnen (die Details sind für diesen Beitrag zu lang, aber ich kann Ihnen sagen, dass sie mit Differenz-Cursorn abgeschlossen sind ) und diese Unterschiede dann auf die neue Status-ID 20 (blaue Linie) anzuwenden.

Angenommen, Sie möchten mehr Änderungen vornehmen oder Sie haben Konflikte festgestellt und wählen Zeilen aus der einen oder der anderen Version aus. Es spielt keine Rolle. Dies sind nur neue Bearbeitungen, die innerhalb eines Bearbeitungsvorgangs vorgenommen werden, wie untergeordnet unter dem Zweig angegeben, den Sie zusammengeführt haben. In diesem Beispiel habe ich nach dem Abgleich zwei weitere aufeinanderfolgende Bearbeitungen vorgenommen.

Schön.

Sagen Sie jetzt, dass Sie bereit sind, die Version zu " posten ". Was bedeutet das? Das heißt, Sie müssen nur die Beschriftungen greifen und auf dieselbe Status-ID verweisen. Hier werde ich Version A in SDE.DEFAULT veröffentlichen. So sieht es aus:

TADAAA! Daher verweisen Version A und SDE.DEFAULT jetzt auf dieselbe Status-ID und sehen daher gleich aus.

OK, jetzt kann ich endlich deine Frage beantworten.

Kannst du einen Beitrag rückgängig machen? In der ArcGIS-Dokumentation wird " Nein" angegeben . Tun Sie es nicht, denn Sie werden mit dieser Logik herumspielen, und wenn Sie nicht wissen, was Sie tun, können Sie Ihre Daten beschädigen.

In Wahrheit ist es jedoch nur erforderlich, ein Update einer der ArcSDE-Versionierungstabellen - der VERSIONS-Tabelle - durchzuführen und den Eintrag der Bezeichnung (auch als benannte Version bezeichnet) zu ändern. Zeigen Sie in unserem Beispiel auf die ID 21, und Sie haben gerade den gesamten Bearbeitungsvorgang rückgängig gemacht. Setzen Sie es auf 3, und Sie haben gerade den gesamten Abgleich rückgängig gemacht. Stellen Sie den Wert auf 5 ein und Sie befinden sich an einem völlig anderen Ort. Ob es Konflikte gibt oder nicht, ist unerheblich.

Dies setzt natürlich voraus, dass keine Komprimierung stattgefunden hat. Betrachten wir den Fall, in dem die Komprimierung genau zum gleichen Zeitpunkt stattfindet, zu dem Sie die SDE-Tabelle aktualisieren. Denken Sie daran, wenn Sie - oder jemand anderes - nach dem Posten eine Komprimierung ausführen, sieht der Baum folgendermaßen aus:

Können Sie den Abgleich nach der Komprimierung rückgängig machen? Nun, in diesem Fall nein . Die Komprimierung hat den gesamten Zweig weggeblasen, sodass Sie nicht mehr rückgängig machen können - diese Daten wurden entfernt. Wenn es eine andere benannte Version in diesem Zweig gegeben hätte, hätte die Komprimierung diesen Zweig nicht zerstört. Ich hoffe, dass das jetzt Sinn macht.

Also solltest du das tun? Wenn Sie nicht wissen, was Sie tun, können Sie nach einer Komprimierung leicht Daten verlieren.

Es gibt ein Tool namens Geodatabase Toolset (GDBT), ein Plug-In für ArcCatalog. Es visualisiert die Zustandslinie und Versionen:

Laden Sie GDBT hier herunter

Kurz die Version und db kennen. Hier sind einige erste Informationen, die Ihnen helfen werden.
Grundlegende
Informationen für Administratoren Hier finden Sie einige Informationen zu rec und post.
Wenn Sie also diese Konzepte anwenden und den Befehl version changes verwenden, haben Sie weiterhin die Möglichkeit, diese Änderungen abzulehnen, wenn Sie rec und post auf die Standardeinstellung setzen.

Sie haben nicht drei Kopien derselben Datenbank.
Sie haben eine Kopie mit Versionen.
Wenn Sie diese Datenbank verwalten, sollten Sie wirklich Zeit (vielleicht sogar Geld) aufwenden und sich mit all dem vertraut machen.
Die versionierten Bearbeitungsworkflows der esri-Klasse für die Multiuser-Geodatabase sind kostenlos und helfen einigen.
Aber die volle Punktzahl würde ich einer Person empfehlen, die einen versionierten SDE-Bearbeitungsworkflow verwaltet.
Diese Klasse ist großartig! zum Verständnis von versionierten Bearbeitungsworkflows für die Multiuser-Geodatabase .

Ich habe einen "schnellen und schmutzigen" Weg. Wechseln Sie zur Standardversion und bearbeiten Sie etwas über das gelöschte Polygon. Wenn Sie sich dann mit dem Standard abgleichen, tritt ein Konflikt auf. Klicken Sie mit der rechten Maustaste auf den Konflikt und weisen Sie ihn an, den Status vor dem Abgleich zu verwenden. Für mich geht das.

Ja, Sie könnten dies tun, aber Sie müssen es mit SQL tun.

Ich mache das nicht, sondern auf eigene Gefahr. SICHERN SIE IHRE DATEN IMMER, BEVOR SIE SDE MANUELL BEARBEITEN.

Sie können die Tabelle sde.versions abfragen, um die state_id aus der Version abzurufen, die Sie mit den Änderungen bereitgestellt haben, die Sie rückgängig machen möchten. Dann können Sie zu den Tabellen A und D gehen und die Einträge löschen, die mit der state_id übereinstimmen.

    SELECT *
    FROM SDE.VERSIONS
    WHERE NAME = 'Version of interest';

Jetzt haben Sie die state_id von Interesse. Jetzt müssen Sie die A- und D-Tabellen für die Feature-Class finden. Sie tun dies, indem Sie das table_registry abfragen. Der Wert ist die registration_id. Um die A- und D-Tabellen zu erhalten, fügen Sie einfach die registration_id zu A und D hinzu.

    REGISTRATION_ID = 1
    A table would be A1
    D table would be D1

Fragen Sie dann einfach sowohl die A- als auch die D-Tabelle ab und löschen Sie die Einträge mit der state_id aus der obigen Abfrage.

Um mehr über die übergeordneten und untergeordneten Beziehungen zu erfahren, fragen Sie einfach in den folgenden SDE-Tabellen ab.

    state_lineages
    versions
    states

Diese haben alle Beziehungen und sollten Ihnen helfen, dem springenden Ball zu folgen.

Es ist nicht möglich, Änderungen rückgängig zu machen, nachdem sie von einer untergeordneten Version in die übergeordnete Version hochgeladen wurden. Siehe: http://help.arcgis.com/de/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

Der Post-Vorgang kann nicht rückgängig gemacht werden, da Sie Änderungen an einer Version vornehmen, die Sie gerade nicht bearbeiten.

Sie können Änderungen überprüfen, die in jeder Version während des Abstimmungsprozesses vorgenommen wurden. Dies ist Ihre Chance, bestimmte Änderungen abzulehnen. Der Abstimmungsprozess wird hier erläutert .

Ja, wie andere gesagt haben, ist die kurze Antwort nein.

Die SDE-Versionierung ist so vielversprechend, aber es ist bedauerlich, dass der Workflow nur Änderungen der Funktionen in der Zukunft voraussetzt.

Die voll funktionsfähige Versionierung in SDE würde Tools bieten, die

• Ermöglicht Rollback (auf Funktionsebene) und Akzeptieren / Ablehnen
• Würde Undos erlauben
• Und würde das Rückgängigmachen früherer Zustände erlauben (dh ab Status 3 die Änderungen von Status 1 rückgängig machen, aber die Änderungen von Status 2 beibehalten).

Dies wäre wie ein Versionsverwaltungssystem für SVN-Quellcodes, jedoch für räumliche Merkmale.

Die einfache Antwort lautet NEIN.

Die Absicht , eine Version der Entsendung ist zu verpflichten , diese Änderungen in die Zielversion.

Das Rollback wird durchgeführt, indem die Version nicht veröffentlicht wird (und es wird empfohlen, solche verlassenen Versionen zu löschen).

Während der Bearbeitung der Version bietet die Bearbeitungsanwendung (z. B. ArcMap) möglicherweise verschiedene Ebenen zum Rückgängigmachen an, und der Benutzer kann festlegen, ob solche Änderungen in der zu bearbeitenden Version gespeichert oder nicht gespeichert werden sollen.

Nach dem Veröffentlichen auf einem Ziel (z. B. sde.default) ist der einzige Weg, dies rückgängig zu machen, über Hacks auf die sde-Systemtabellen.