存档过程
在版本化数据集上启用存档将创建存档类，并用 DEFAULT 版本中存在的当前数据填充存档类。存档类使用 gdb_from_date 和 gdb_to_date 来保存存档更改的时间。
表示时间
理解记录更改时 ArcGIS 如何表示时间十分重要。通常可以用有效时间或事务时间记录历史。有效时间是在真实世界里发生更改的实际时刻，并通常由正在应用更改的用户记录下来。事务时间是在数据库中记录事件的时间。系统会自动生成事务时间。
当将更改保存到或提交到 DEFAULT 版本时，ArcGIS 使用事务时间（基于当前服务器时间）来记录对数据所做的更改。事务时间和在真实世界中发生该事件的时间很少是同一时间。在真实世界中发生的事件和在数据库中记录的事件之间会有时间差。例如，2006 年 5 月 14 日销售了一块宗地，然而直到 2006 年 6 月 5 日才记录此数据更改。针对这一更改，2006 年 6 月 5 日将作为事务时间被记录到存档类。
当发生编辑时，ArcGIS 会将事务存档到存档类。真实世界事件的时间和事务时间之间的区别可能看起来不是很明显，但当根据存档信息执行查询时就会变得十分明显。在生产系统中，编辑和更新数据方面的工作积压是很普遍的事，这将导致有效时间和事务时间之间的时间滞差。
如果许多不同用户或部门编辑数据库，在这种多用户环境中记录历史时，有效时间和事务时间之间的差异也是一个问题。在数据库中执行和记录更改的顺序可能与真实世界中发生这些更改的顺序不一致。
启用存档
当启用存档时，指定类的表示 DEFAULT 版本的所有行都将按同一时间戳被复制到存档类。所有行的 gdb_from_date 属性都带有启用存档操作的日期和时间的时间戳。所有行的 gdb_to_date 属性都带有 12/31/9999 时间戳。无论何时只要一个属性具有 gdb_to_date 12/31/9999，它都是 DEFAULT 版本中对象的当前表示。当将编辑内容保存或提交到 DEFAULT 版本时，地理数据库会自动将更改存档到存档类。这意味着
- 在 DEFAULT 版本中创建的要素在存档类中被表示为带 gdb_from_date 属性值和 gdb_to_date 属性值的行，其中 gdb_from_date 属性值被设置为存档操作的时间戳，gdb_to_date 属性值被设置为 12/31/9999。
- 在 DEFAULT 版本中更新的要素通过将 gdb_to_date 属性值设置为存档操作的时间戳来更新存档中的关联行，并插入带 gdb_from_date 属性值和 gdb_to_date 属性值的新行，其中 gdb_from_date 属性值被设置为存档操作的时间戳，gdb_to_date 属性值被设置为 12/31/9999。
- 在 DEFAULT 版本中删除的要素通过将 gdb_to_date 属性值设置为等于存档操作的时间戳来更新存档类中的关联行。
更新存档表在单个数据库事务中执行。如果在事务过程中遇到了错误，则回滚整个存档操作，因而也不会完成保存或提交操作。一旦改正了错误，就可以再次执行保存或提交操作。
对于每个存档操作，DEFAULT 历史标记使用存档操作的值进行更新。当使用历史版本并选择 DEFAULT 历史标记时，这确保存档类的当前表示等同于事务 DEFAULT 版本中的版本化类的表示。
访问存档类实际上可以比使用等同的版本化类占用较少的数据库资源。
如果应用程序开发者对捕捉存档操作时间的事件感兴趣，可参阅“软件开发者工具包”中的 Iversionevents2 接口上的 OnarchiveUpdated 事件。
对历史版本的查询在存档类上执行：
 |
存档表 |
对事务版本的查询仍然在基表和增量表上执行：
 |
基表、A 表和 D 表 |
添加要素
在地籍数据库中的要素显示宗地号 116 及其在存档类中的对应行。gdb_from_date 显示创建时间和日期，而 gdb_to_date 显示 12/31/9999，因为自从启用存档以来还没有修改或删除要素。
当插入要素（宗地 117）并将编辑内容提交到 DEFAULT 版本时，会在存档类中插入新行，同时 gdb_from_date 通过此提交操作的时间戳进行更新。新行的 gdb_to_date 属性显示 12/31/9999，因为还没有更新或删除该要素。
 |
注:某些编辑操作，例如使用“自动完成面”工具创建要素以及验证地理数据库拓扑，会在现有要素上插入折点来使相邻要素之间保持重合。例如，如果使用“自动完成面”工具创建与现有面相邻的新面，则会在新要素的草图与现有要素交叉的位置为现有面添加折点。
更新要素
当更新要素时，会通过存档操作的时间戳设置 gdb_to_date，并插入新行以显示要素的当前表示。此新行的 gdb_from_date 通过存档操作的时间进行设置，而 gdb_to_date 仍将显示 12/31/9999，因为还没有修改或删除该行。
下图显示执行更新操作前的两块宗地 116 和 117，它们相应的 gdb_from_date 和 gdb_to_date 属性都位于存档类中。
 |
如果扩展了宗地 117 的宗地边界，并将这些编辑内容提交到 DEFAULT 版本，则 gdb_to_date 将通过存档操作的时间戳进行更新，并创建一个新行。该新行的 gdb_from_date 属性将通过存档操作的时间和日期进行设置。
例如，更新时刻 (7/14/2005 5:34:22 PM) 之前的查询将显示宗地 117，因为它在更新前就已经存在。7/9/2005 2:33:43 PM 时刻之前的查询将不显示宗地 117，因为这时它还尚未创建。更新时刻 (7/14/2005 3:45:23 AM) 之后的任何查询将显示带扩展边界的宗地 117 的当前表示。
删除要素
当删除要素时，gdb_to_date 将通过存档操作的时间戳进行更新。下图显示宗地 116 和 117，它们相应的 gdb_from_date 和 gdb_to_date 属性都位于存档类中。
如果现在删除宗地 117，并将这些编辑内容提交到 DEFAULT 版本，则 gdb_to_date 属性将通过存档操作的时间戳进行更新。
关于存档的技术注意事项
下列情况会在存档类中创建时间差：
编辑者正在直接编辑 DEFAULT 版本，并在编辑会话中删除一个对象。
然后，编辑者保存编辑内容，这将通过删除该对象的时间戳来更新存档类的 gdb_to_date 属性。
如果同一对象在子版本中被更新并与 DEFAULT 版本相协调，则将产生一个冲突。
在冲突解决过程中，如果编辑者选择使用该行的更新表示替换冲突，则当提交版本时，在 DEFAULT 版本中将还原该行。该存档操作将新行插入到该存档类，并将 gdb_from_date 属性设置为存档操作的时间戳，将 gdb_to_date 属性设置为 12/31/9999。
因此，当编辑者查看对象的时间谱系时，在 gdb_to_date 和 gdb_from_date 日期之间将包含一个时间差，在这段时间中，DEFAULT 版本中没有该对象。