Unlike other versions, the default version always exists and cannot be deleted. In most workflow strategies, it is the published version of the database, representing the current state of the system being modeled. You maintain and update the default version over time by posting changes to it from other versions.
Depending on the access permission set, you can also edit the default version directly, just like any other version. It may be necessary to modify the access permission for the default version to be protected to prevent accidental edits. For more information, learn how to protect the default version for branch and traditional versioned workspaces. A geodatabase can have many versions. You can use the Versions view to create versions, modify version properties, and delete versions in an enterprise geodatabase.
When versions are created, they are considered children or branches of an existing version. When a version is created, it is identical to the parent ancestor version. Over time, the versions diverge as changes are made to the ancestor and user versions. As more versions are created, a tree-like architecture begins to develop. This is called a version tree. For simplicity and geodatabase management considerations, a recommended best practice is to maintain a flat version tree where the default version is the ancestor for all user versions.
Note: With branch versioning, all versions are created with the default version as the ancestor; only one version level is allowed. For more information on version management, see Manage branch versions or Manage traditional versions.
When you first make a connection to an enterprise geodatabase, you automatically connect to the default version. Depending on the versioning type used and data source, you can change the version you are connected to by right-clicking the geodatabase in the Catalog pane and opening the Geodatabase Connection Properties dialog box.
Note: Upgrades from beta versions of the geodatabase are not supported. There is no formal mechanism to downgrade a geodatabase to a previous version. If after upgrading to a newer version you decide you need the older version of the geodatabase, use the backup copy of the old geodatabase that you created. Connect to the folder that contains the file geodatabase you want to upgrade. If you do not already have a backup of your data, make a backup copy of the geodatabase before proceeding. When setting access on versions, consider your version workflow strategy along with the needs of the various users working within that framework.
You should use version access along with dataset permissions to control access to the data. The DEFAULT version is the ancestor of every other version in a geodatabase and usually represents the published version of a geodatabase. Any features or rows that are deleted from the DEFAULT version, even though they are recorded in the version delta files, cannot be restored unless the dataset is unregistered as versioned assuming the database has not been compressed beforehand.
Unregistering a dataset as versioned restores the dataset to its configuration at the last database compression; however, all uncompressed edits are lost.
Versioning allows multiple editors to alter the same data in an enterprise or workgroup geodatabase without applying locks or duplicating data. To edit feature classes that participate in a topology, network dataset, or geometric network, or edit a parcel fabric, you must register the data as versioned. This is because when you edit a feature in a network, topology, parcel fabric, not all the features lock, which means other editors can edit another part of the network, topology, or parcel fabric in a way that conflicts with your edits.
You always access an enterprise or workgroup geodatabase through a version. When you connect, you specify the version to which you will connect. By default, you connect to the Default version. A version is a sort of view of the geodatabase that compartmentalizes edits.
Versions allow you and all other users connected to the same version to see your changes. Uers connected to other versions do not see your changes until you reconcile and post them to an ancestor version.
The Default version is the root version and, therefore, the ancestor of all other versions. Unlike other versions, the Default version always exists and cannot be deleted. In most workflow strategies, it is the published version of the geodatabase, representing the current state of the system being modeled.
You maintain and update the Default version over time by posting changes to it from other versions. You can also edit the Default version directly, just like any other version.
You create a version by creating children or branches from any existing version. You create the first version by making a child version of the Default version. When the new version is created, it is identical to the Default version. Over time, the versions diverge as changes are made to the Default version and the new version.
A geodatabase can have many versions. This example shows the tree view of the dialog box, depicting the Default version and four other versions, and how the versions are related. The Cases and Base versions are children of the Default version, and the Case1 and Case2 versions are children of the Cases version. Creating a version gives you the impression that you are creating a copy of the entire geodatabase, but you are not.
Regardless of how many versions you have, each table and feature class is stored only once in the database.
0コメント