OBJECTID NOT NULL NUMBER(38) CONTINENT NVARCHAR2(13) SHAPE SDE.ST_GEOMETRY GDB_FROM_DATE NOT NULL TIMESTAMP(6) GDB_TO_DATE NOT NULL TIMESTAMP(6) GDB_ARCHIVE_OID NOT NULL NUMBER(38)
CREATE OR REPLACE VIEW CONTINENT_EVW ASSELECT OBJECTID,CONTINENT,SHAPE FROM SDE.CONTINENT WHERE GDB_TO_DATE = to_timestamp('12.31.9999 23:59:59.000','mm.dd.yyyy HH24:MI:SS.FF3');
注意:Versioned views created in ArcGIS 10.2 or later releases follow the naming convention
It is important to understand how ArcGIS represents time when change is recorded. History can be recorded as either valid time, transaction time, or Coordinated Universal Time (UTC). Valid time is the actual moment at which a change occurred in the real world and is typically recorded by the user who is applying the change. Transaction time is the time an event was recorded in the database. Transaction times are generated automatically by the system. UTC is the primary standard used to regulate clocks and time over the Internet. For archiving on versioned data ArcGIS uses transaction time, which is based on the current server time, to record changes to the data when changes are saved or posted to the DEFAULT version. Transaction time and the time the event occurred in the real world are rarely the same time. Time will elapse between an event happening in the real world and its being recorded in the database. For example, a parcel is sold on May 14, 2006; however, the change is not recorded to the data until June 5, 2006. The transaction time of June 5, 2006, is recorded in the archive class for this change.When the edit occurs, ArcGIS will archive the transaction to the archive class. The difference between the time of the real-world event and the transaction time may seem insignificant, but it becomes more apparent when queries are performed against the archived information. Backlogs in editing and updating data are not uncommon in production systems, and they result in the time difference and lag between valid and transaction time.The difference between valid and transaction time is also an issue in situations where history is recorded in a multiuser environment with many different users or departments editing the database. The sequence in which changes are performed and logged in the database may not be the same order in which those changes occurred in the real world.Archiving on nonversioned data uses UTC to represent time. Changes to the data are recorded when edits are saved during an edit session.
最后一行,非版本数据归档使用了UTC时间。版本数据的归档还是服务器时间或者北京时间。
create table CONTINENT( objectid INTEGER not null, continent NVARCHAR2(13), shape ST_GEOMETRY, gdb_from_date TIMESTAMP(6) default sys_extract_utc(systimestamp) not null, gdb_to_date TIMESTAMP(6) default to_timestamp('12.31.9999 23:59:59.000000','mm.dd.yyyy HH24:MI:SS.FF6') not null, gdb_archive_oid INTEGER not null)