This document is archived and information here might be outdated.  Recommended version.


IImportDataChanges.ImportDataChanges Method (ArcObjects .NET 10.4 SDK)
ArcObjects Library Reference (GeoDatabaseDistributed)  

IImportDataChanges.ImportDataChanges Method

Imports data.

[Visual Basic .NET]
Public Function ImportDataChanges ( _
    ByVal WorkspaceName As IWorkspaceName, _
    ByVal DeltaDataChanges As IDeltaDataChanges, _
    ByVal ReconcileWithParent As Boolean, _
    ByVal acceptDefaultConflictResolution As Boolean _
) As Boolean
[C#]
public bool ImportDataChanges (
    IWorkspaceName WorkspaceName,
    IDeltaDataChanges DeltaDataChanges,
    bool ReconcileWithParent,
    bool acceptDefaultConflictResolution
);
[C++]
HRESULT ImportDataChanges(
  IWorkspaceName* WorkspaceName,
  IDeltaDataChanges* DeltaDataChanges,
  VARIANT_BOOL ReconcileWithParent,
  VARIANT_BOOL acceptDefaultConflictResolution,
  VARIANT_BOOL* pConflictDetected
);
[C++]

Parameters WorkspaceName [in]
WorkspaceName is a parameter of type IWorkspaceName DeltaDataChanges [in]
DeltaDataChanges is a parameter of type IDeltaDataChanges ReconcileWithParent [in] ReconcileWithParent is a parameter of type VARIANT_BOOL acceptDefaultConflictResolution [in] acceptDefaultConflictResolution is a parameter of type VARIANT_BOOL pConflictDetected [out, retval] pConflictDetected is a parameter of type VARIANT_BOOL

Product Availability

Available with ArcGIS Engine, ArcGIS Desktop, and ArcGIS Server.

Remarks

The ImportDataChange method imports edits into geodatabases from delta files. See the DataChangesExporter coclass for more information on delta files.

The WorkspaceName argument refers to the ArcSDE geodatabase into which the changes will be imported. The DeltaDataChanges argument references the delta file.

For delta files generated from check-outs, the edits are placed in the check-out version. For any other type of delta files, the changes are applied to the version referenced by the WorkspaceName provided.

The ReconcileWithParent argument can be used to automatically reconcile with the parent version once the changes have been imported. See the ICheckin::CheckInFromGDB method for a description of how conflicts are handled in cases where edits are automatically reconciled.

The ICheckin::CheckinFromDeltaFile method also checks in changes from delta files generated from check-outs. The ICheckin::CheckinFromDeltaFile method provides some more options than this method, however.

Delta files can be created for 3 different sources:

Check-out - The delta file contains edits applied to the checked out data.

Version Changes - The delta file contains edits between source and target versions to a delta file.

Custom Appliations - Custom applications can be used to create delta files for data sources that are not geodatabases. In order to create these files, the custom application will need create an update-gram using the XML format published by ESRI. The delta database (mdb) format is not a published format.

The process of importing changes depends on the following factors:

Delta file model type: Both full and simple model types are supported for any valid delta file. Delta files generated from check-outs or version changes are full model types since the DataChangesExporter creates full model type delta files. In cases where delta files are generated from custom applications involving non-geodatabase data, the model type is simple. This is because non-geodatabase data is not edited with full geodatabase behavior.

Some types of behavior can’t be applied with simple model type delta files. For example, if a delta file has an update that moves or rotates a feature with feature linked annotation, the annotation is not automatically adjust on import.

GlobalID columns:   In ArcGIS 9.0, data can have a column of type GlobalID  GlobalID columns  contain a unique GUID value for each row which is maintained by ArcGIS. This column is similar to the ObjectID column except the GlobalID value uniquely identifies the row across geodatabases. The GlobalID value is used if it exists to apply the edits, otherwise the ObjectID value is used.

When importing, the ObjectID value for an insert row may be modified to make it unique within the table. The GlobalID value is never modified since it is unique across geodatabases. If you plan on importing changes over several cycles, it may be necessary to add GlobalID columns to your data. Without GlobalID’s, you may insert the same row several times into the database.

Import Version and Geodatabase: When importing a delta file that was generated from a check-out, edits are always imported into the check-out version in the master geodatabase. For delta files generated from version changes or custom applications, the edits can be imported into any version in any geodatabase. The import will succeed as long as the datasets for the data described in the delta file are versioned and editable for your ArcSDE user.

When importing data with a GlobalID column, behavior is applied to ensure that a single GlobalID value refers to the same row throughout the geodatabase, For example, if you are importing an insert that has already been inserted into the geodatabase, it gets applied as an update. The following table describes how inserts, updates and deletes are applied based on conditions in the import version:

Scenario Result A– with a GlobalID Result B – without a GlobalID

INSERT: The delta file insert row already exists in the import version.

The row gets added as an update.

The row is inserted into the import version as a new row with a new ObjectID value.

INSERT: The delta file insert row does not exist in the import version, but exists as in another version in the geodatabase.

A. The insert is skipped if it exists in a non-ancestor version. You can use reconcile and post to move the row into the import version.

B. The Insert is is applied as an update if it exists in an ancestor version.

The row is inserted into the import version as a new row with a new ObjectID value.

INSERT: The delta file insert row  is not found in the geodatabase..

The row is inserted into the import version as a new row with a new ObjectID value.

The row is inserted into the import version as a new row with a new ObjectID value.

UPDATE: The delta file update row already exists in the import version.

The update is applied.

The update is applied.

UPDATE: The delta file update row does not exist in the import version, but exists in another version in the geodatabase.

A. The update is skipped if it exists in a non-ancestor version. You can use reconcile and post to move the row into the import version.

B. The update row gets applied as an update if it exists in an ancestor version.

The update is skipped.
UPDATE: The delta file update row is not found in the geodatabase. The update is skipped. The update is skipped.
DELETE: The delta file delete row is found in the import version. The row is deleted. The row is deleted.
DELETE: The delta file delete row is NOT found in the import version. The delete is skipped. The delete is skipped.
GlobalID and ObjectID values are always consistent for the same row in a geodatabase. It is not possible to have two different GlobalID values referencing the same row in different versions.
For more information on GlobalID's see the IClassSchemaEdit3 interface.

See Also

IImportDataChanges Interface