Special Versioning DEFAULT Figure 2: Versioning allows multiple users to work on the same geodatabase. DEFAULT is the parent version and Project 1 and Project 2 are child versions. Editor 1 Project 1 Editor 2 Project 2 Enterprise ArcSDE geodatabases provide support for many users creating and maintaining large amounts of GIS data in a central location. In many cases, multiple users need to edit the same data at the same time. In other words, they require concurrent multiuser geodatabase editing. The nature of the spatial relationships and connectivity that define geographic data requires that edit sessions for geospatial data typically span long periods of time (e.g., hours, days, or weeks). These long edit sessions can be thought of as long transactions in the DBMS. Additional user requirements include the ability to undo or redo changes, the capability to develop alternative application design proposals without affecting the published geodatabase, and a mechanism to manage how the data and the geodatabase have changed over time. The DEFAULT Version Every enterprise ArcSDE geodatabase has a default version named DEFAULT that is owned by the ArcSDE administrator. The DEFAULT version always exists and cannot be deleted or renamed. It is the root version and, therefore, the ancestor to all other versions in the geodatabase. In many workflow strategies, it is the published version of the geodatabase, representing the current "public" end-user view of the geodatabase. The DEFAULT version is typically maintained and updated over time by incorporating changes to it from other versions. Like any other version, it can also be directly edited. Enterprise ArcSDE geodatabases can have many versions. A new version (child version) is created from an existing version (parent version). When a new child version is first created, it is identical to its parent. However, over time, parent and child versions may diverge as changes are made to each version. In the figures in this article, Project 1 is a child version of DEFAULT, its parent version (Figure 2). When editing geodatabase datasets within the versioned editing environment, each version will seem to have its own copy of the data. As a dataset is edited in one version, it will appear differently when viewed in another version. Regardless of how many versions exist within the geodatabase, each dataset is only stored once in the DBMS. Behind the scenes, ArcGIS leaves each dataset in its original state during editing. All changes to a dataset are recorded in associated tables known as delta tables. Delta tables are also commonly called the A (adds) and D (deletes) tables. Each table or feature class will have an associated pair of these delta tables when they are registered as versioned within ArcCatalog. Every version has an owner, description, parent version, associated database state, and level of user access. There are three levels of access to a version:  Private: Only the owner can view and edit.  Protected: All users can view, but only the owner can edit.  Public: All users can view and edit. The access level for the DEFAULT version is public by default. It is recommended that its access level be set to protected to ensure data in an enterprise ArcSDE geodatabase is not accidentally corrupted or lost. This means that only the ArcSDE administrator can edit or post changes to the DEFAULT version. Versions are beneficial for workflow management in enterprise ArcSDE geodatabases, such as modeling different discrete stages in a GIS project (e.g., each stage is represented by a version) and modeling what-if scenarios without affecting the original datasets. They provide a framework for security management and quality assurance in data editing, and they also support historical archiving and geodatabase replication. Versioning Workflows Versioning supports many complex editing workflows and can be easily adapted and/or customized to meet the business requirements of any organization. Three example business workflows using versions are shown in Figure 3. The simplest workflow is to have concurrent editors directly editing the DEFAULT version (see Figure 3A). Another option is to create a separate version (e.g., multiple projects) for each editor in the geodatabase (see Figure 3B). To ensure that the publication view of the geodatabase is protected from accidental data corruption, many organizations create a quality assurance (QA) version from the DEFAULT version (see Figure 3C). The QA version would be maintained by a data quality manager and would regulate all edits that are applied back to DEFAULT. Note that each versioning workflow strategy has its own advantages and disadvantages. It is important to use a strategy that best meets the requirements of the business workflow. Continued on page 44 www.esri.com ArcUser Winter 2010 43