BUG
Executing the compress command while users are connected can mistakenly trim states that are currently locked by connected sessions
Description
Executing the compress command while users are connected can mistakenly trim states that are currently locked by connected sessions.
Once the states are trimmed by the compress operation, if the client applications are still dependent on the state that was removed for reading versioned data, the client's application will fail with an error indicating the state no longer exists.
Cause
The cause of the problem is the compress process is not correctly verifying if the lineage of states being trimmed are locked or not.
State locks are acquired by client applications to ensure the state is not modified, deleted, or trimmed while being used. Shared state locks are obtained for reading and exclusive state locks are obtained while editing for each edit operation and released upon the edit session saving. Shared state locks are released when the client application exits or releases all references to versioned classes in the application.
In this case, the compress process will only trim states with shared locks if the states are not referenced by a version.
Workaround
If client applications are connected and working with versioned data when a compress is executed and the state the application references is trimmed, the client application will encounter an error when displaying or querying a versioned class that the state no longer exists.To continue working, the user should use the 'Refresh' command on the versioning toolbar or alternatively exit the application and then resume using the application.
The 'Refresh' command detects the current state a version references. This state is then used by the client application when working with a versioned class (by setting the state for the version query being executed in the database).
An example of when it is necessary to use the 'Refresh' command is in the case when a user connects to a versioned geodatabase when they arrive to work in the morning. The individual's application uses versioned feature classes from the DEFAULT version for map production. Throughout the day, other users in the organization edit the same versioned classes in the DEFAULT version. The user who connected in the morning will not see these changes until explicitly refreshing the versioned workspace using the 'Refresh' command. Once refreshed, the application will see the current state of the DEFAULT version and all the edits that have been performed by the editors.
This issue has been resolved at version 9.3.1.
Article ID:000010506
- Legacy Products
Get help from ArcGIS experts
Download the Esri Support App
Discover more on this topic
Search for related information
Find training related to this topic
Explore ideas and give feedback