Transaction management update#

Transfer of change-only updates-Enterprise geodatabases and spatial data infrastructures in which information is shared across a range of organizations are collaborative efforts that require the sharing of updates across the Internet in a well-defined extensible markup language (XML) schema for sharing change-only updates between geodatabases.

Transaction management update#

History-Sometimes it is advantageous to maintain a historical version of each feature in a geodatabase, even after that particular version has been updated, to maintain a copy of the retired and changed features in an archive or to track an individual feature's history-for example, parcel lineage or feature update properties in a national mapping database.Those updates must be posted to the main database. Checkout/Check-in transactions-It is often necessary to check out a portion of a geodatabase for a particular area or district to a personal computer and update that information in a disconnected session that could last for days or weeks or, increasingly, to take into the field for mobile editing and updating.

Eventually, each editor needs to post and reconcile updates with the other editors to identify and resolve any conflicts. Each editor needs to work with a personalized data state, viewing individual updates and ignoring updates by other editors. Multiuser editing-Multiple editors often need to concurrently update the same spatially integrated features.Multiple edit sessions-A single GIS update may require numerous changes that span multiple edit sessions occurring over a few days or weeks.The following are examples of GIS data compilation workflows that require a version-based transaction model:

In most instances, these are made possible through the use of an enterprise geodatabase and ArcGIS to manage updates to the central GIS database using versioning, which you can read more about below. In many cases, long transaction workflows are critical to a GIS. The geodatabase plays a key role during these operations by managing the high-level, complex GIS transactions on the database management system transaction framework. In a multiuser database, the GIS transactions must be managed on the database management system's short transaction framework. Often, the edits must be performed in a system that is disconnected from the central, shared database.Д«ecause GIS workflow processes may span days or months, the GIS database must remain continuously available for daily operations, where each person connecting to the data might have a personal view or state of the shared GIS database. Editing sessions can span several hours or even days. Numerous transactions must span long periods of time (sometimes days and months, not just seconds or minutes).ДЄdditionally, editors need to be able to undo and redo changes.

Often, multiple records are updated in unison as a single transaction.

However, GIS users universally also have some specialized transactional requirements. In many cases, you can use the database management system's transaction framework for managing edits and updates to geodatabases. Geographic information system (GIS) databases, like other database applications, must support update transactions that enforce data integrity and application behavior. Transactions are packages of work that make changes to databases.

The geodatabase transaction model: Traditional versioning.