An overview of disconnected editing

ArcInfo or ArcEditor is required to check data in and out and to edit an ArcSDE check-out geodatabase. You can edit a personal check-out geodatabase with ArcView.
Disconnected editing is supported by two principal mechanisms: checking out andchecking in data. Checking out data from a geodatabase involves taking a copy of some data from one geodatabase, the master geodatabase, and transferring it to another geodatabase, the check-out geodatabase. This copy is undertaken within a framework that allows the data to be reintegrated with the master geodatabase at a later time. Checking in the data from a check-out geodatabase involves establishing whether any changes have been made to the data in the check-out geodatabase and transferring those changes back to the master geodatabase.
OTE: ArcInfo or ArcEditor is required to check data in and out and to edit an ArcSDE check-out geodatabase. You can edit a personal check-out geodatabase with ArcView.
Having identified the data to check out, the check-out process itself involves a number of automated steps. The selected data, along with any related objects, is copied to the designated check-out geodatabase. A new version of the data, the master check-out version, will be created in the master geodatabase as a child of the version to which you are currently connected. This will be created as a public version, accessible to all users in the master geodatabase. This version may be set to private, or hidden from general access, if required. For example, if you are connected to the DEFAULT version, a new version with the same name as the check-out will be created as a child of DEFAULT. This version will receive the changes from a check-out geodatabase when the data is checked in.
If the check-out geodatabase is an ArcSDE geodatabase, then two new versions are created in the check-out geodatabase. The first version, the synchronization version, will be created as a child of the DEFAULT version. This synchronization version will reflect the state of the data at the time the check-out was created and should not be edited. The second version, the check-out version, will be created as a child of the synchronization version. Only the edits made to this version can be checked back into the master geodatabase. Once data has been checked out to an ArcSDE geodatabase, it is automatically registered as versioned. If the check-out geodatabase is a personal geodatabase that does not support versioning, changes to the data are maintained in a separate DBMS table. The check-out process concludes by adding information that describes each check-out to both the master and check-out geodatabases. This information includes the name of the user who created the check-out, the data that has been checked out, the time the check-out was created, and the name of the new check-out version in the master geodatabase.Details about the source of the data, the master geodatabase, are also recorded. This involves storing partial ArcSDE connection information, which will be used during the check-in process. Usernames and passwords are not stored in the check-out geodatabase.
Restrictions
There are some important restrictions to remember when checking out data. First, the version created in the master geodatabase should not be edited while the data it represents is still checked out. Because this check-out version in the master geodatabase is public and, therefore, editable when created, any changes made to this version may be overwritten during the check-in process, since no conflict reconciliation is undertaken at this point.Second, it is not possible to append data to or refresh an existing check-out. You cannot check out an updated version of the same data to a check-out geodatabase while it contains a check-out. You must first check in the original check-out and make a second check-out. Once data has been checked back in, the check-out geodatabase no longer participates in any check-out or check-in relationship with a master geodatabase. However, it is possible to reuse a geodatabase for a new check-out. You can reuse the existing schema in a geodatabase to form a template for a second check-out. If the data to be checked out is complex, reusing the schema in a geodatabase will afford some performance improvements. When creating the new check-out, if the geodatabase to be reused contains an older copy of the data, this will be deleted in preparation for receiving the latest copy of the data from the master geodatabase. If required, additional objects may be included to augment the check-out. Finally, the check-out model does not support schema modifications to data that has been checked out. If the schema is altered in any way, either in the master or check-out geodatabase, for example, by adding a field to a table or feature class, the check-out is rendered invalid, and any attempts to check in the modified schema and data will fail. If a new table has been created in the check-out geodatabase, it will be ignored when the rest of the data is checked in.
Managing check-outs
Once a check-out has been created, any subsequent modifications to the properties of the check-out are made asynchronously. This means that changes made to the properties of a check-out in a master geodatabase are independent of the associated check-out in the check-out geodatabase and vice versa. For example, if a check-out is unregistered in the master geodatabase, this will not unregister the associated check-out in the check-out geodatabase. Similarly, if a check-out is renamed in the master geodatabase, that operation does not rename the check-out in the check-out geodatabase. The name of a check-out in a master geodatabase does not have to match the name of the check-out in the corresponding check-out geodatabase. If a check-out is renamed in the master but not the check-out geodatabase, the data can still be checked in.
OTE: This functionality is not available with ArcView.
As with checking out data, the check-in process involves a number of automated steps. This process begins by establishing what changes have been made to the data in the check-out geodatabase; only these changes will be checked back in to the master geodatabase. If the check-out geodatabase is an ArcSDE geodatabase, a comparison is made between the edited check-out version and the static synchronization version to identify what is different. If the check-out geodatabase is a personal geodatabase, the changes are recorded in a separate DBMS table. The changes are then transferred directly to the check-out version in the master geodatabase; there is no version reconciliation at this point with the check-out version. If the check-out version has been modified since the data was checked out, these changes may be overwritten. Once the data has been checked back in to the master geodatabase, all associated check-out information will be removed, such as the list of datasets checked out, from both the master and the check-out geodatabases. Any versions created in an ArcSDE check-out geodatabase will also be removed. However, the copy of data that was checked out is not removed from the check-out geodatabase. The responsibility for deleting any residual copies of the data once check-in has completed remains with the user or data administrator.The check-in process may optionally involve an additional step of reconciling and posting the changes from the check-out version to its parent version in the master geodatabase. If any conflicts are detected at this stage, they must be resolved using standard geodatabase version reconciliation tools. If no conflicts were detected, the check