A versioned view incorporates a database view, stored procedures, triggers, and functions to allow you to use Structured Query Language (SQL) to read or edit data in a geodatabase that has been registered to use traditional versioning. When you query a versioned view, you can see the data in the base (business) table and the edits that are stored in the delta tables. The triggers used by the versioned views update the delta tables when you edit the versioned view using SQL.
Unlike database or spatial views, versioned views are not used to change the table's schema or limit access to it; rather, they are used to facilitate access to a certain version of a table or feature class. Therefore, you do not specify a where clause when creating a versioned view. As a result, versioned views contain the same columns and rows as the base table they represent.
A summary of how versioned views work
Each versioned table or feature class has associated delta tables that record edits made to it. When a versioned table or feature class is accessed through a versioned view, all the records in the base table are selected and merged with records from the delta tables to construct a view that includes all the changes made to the base table in the context of the specified version.
Without versioned views, applications that do not support geodatabase versioning can only directly query the base table of a versioned feature class or table and have no connection with the delta tables. Using versioned views with these applications is useful because it provides the applications with access to the data in the delta tables.
Versioned views do not work with functionality implemented at the geodatabase level. Therefore, they should not be used to edit data that participates in geodatabase behavior. See What type of data can be edited using SQL for more information.
If you query a versioned view without setting the version and state, you are referencing the current state of the DEFAULT version. If other users are committing edits to the DEFAULT version (thereby changing the state that the DEFAULT version references), your subsequent queries will see the latest state of DEFAULT and their edits.
If you specify version to query using the set_current_version function or procedure (names vary slightly depending on your database management system), you are referencing the state that the specified version was referencing when you set the version.
For example, if you run the set_current_version function to set the version to a named version called decedits and decedits is pointing to state 4 in the state tree, all subsequent SQL queries you make against decedits will see state 4 of the data even if other users are posting edits to decedits, causing the current state of decedits to be state 25. To see state 25, run the set_current_version function again to set the version to the current state of decedits.
Versioned view creation
Versioned views are automatically created for tables or feature classes that are registered as versioned in ArcGIS 10.1 or later releases. If you register a feature dataset as versioned, a versioned view is created on each feature class in the feature dataset. The view that is created has the same name as the table or feature class with _evw appended to the end.
If the data was registered as versioned in ArcGIS 10 or earlier, you can create a versioned view from ArcGIS Desktop 10.1 or a later release by right-clicking the table, feature class, or feature dataset, pointing to Manage and clicking Enable SQL Access.