View on versioned ArcSDE feature class

[ab1]

Hi,
I created a view on a versioned ArcSDE feature class and a versioned ArcSDE table. The view is a join between the two elements.
The feature class is registered as versioned without the option to move edits to base.

sdetable -o create_view -T VG_PSI -t psi,pdi -c pdi.id_pdi,psi.id_iti,pdi.shape -p psswd -u user -i sde:oracle11g:fero -w pdi.id_pdi=psi.id_pdi

The created view contains some fields of the table and some fields of the feature class in addition to the geometry (shape) of the feature class.
When I modify the table, the changes are made in the view.
But when I change the geometry of a feature in the feature class, that geometry change doesn't happen in the view.
I did some investigations and I concluded that the view does read the geometry from the "final object table" and not from the delta tables (A and D)! Normally, the opposite shoould happen. And since the feature class is registered as versioned without the option to move edits to base, the "final object table" doesn't contain the newest version of the feature class.

Is there a way to make the view read from the delta tables? Or do you have any suggestion to avoid this problem?

Regards.

[LeoDonahue]

Hi,
I created a view on a versioned ArcSDE feature class and a versioned ArcSDE table. The view is a join between the two elements.
The feature class is registered as versioned without the option to move edits to base.

sdetable -o create_view -T VG_PSI -t psi,pdi -c pdi.id_pdi,psi.id_iti,pdi.shape -p psswd -u user -i sde:oracle11g:fero -w pdi.id_pdi=psi.id_pdi

The created view contains some fields of the table and some fields of the feature class in addition to the geometry (shape) of the feature class.
When I modify the table, the changes are made in the view.
But when I change the geometry of a feature in the feature class, that geometry change doesn't happen in the view.
I did some investigations and I concluded that the view does read the geometry from the "final object table" and not from the delta tables (A and D)! Normally, the opposite shoould happen. And since the feature class is not registered as versioned with the option to move edits to base, the "final object table" doesn't contain the newest version of the feature class.

Is there a way to make the view read from the delta tables? Or do you have any suggestion to avoid this problem?

Regards.

Is it registered as versioned or not?

[VinceAngelo]

There is no way to make a simple view read from delta tables.  If you're
using ArcGIS 10.1, multi-version views are replaced by versioned views.

- V

[ab1]

@ldonahue: It is registered as versioned but without the option to move edits to base. I've corrected my first post.
@vangelo: with mv_view I can't create a join between two tables. I'm using ArcGIS 10.0 SP 5.

[LeoDonahue]

I was under the impression that if you were creating sde views on versioned data that once you reconcile/post/synchronize, that your sde view will be updated.

[MarcoBoeringa]

@ldonahue: It is registered as versioned but without the option to move edits to base. I've corrected my first post.
@vangelo: with mv_view I can't create a join between two tables. I'm using ArcGIS 10.0 SP 5.

I was under the impression that if you were creating sde views on versioned data that once you reconcile/post/synchronize, that your sde view will be updated.

This section of the ArcGIS Help page "What are versioned views?" may be of relevance:

"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."

[LeoDonahue]

I think this is an apples to oranges comparison.  I wasn't talking about versioned views.  I'm not clear the OP is talking about versioned views either.  The OP indicated that they created a view on a versioned featureclass and a versioned sde table, which you can still do with the sdetable -o create_view command.  We are doing this on versioned featureclasses at 10.0  It's no different than creating a view on non-versioned data.

From this discussion, it looks like at 10.1 versioned views can point to various states.  Sounds interesting.

[ab1 · Accepted solution]

I found an interesting solution that works fine for me.
I created a multiversioned view on the feature class and on the table following what is said here : http://forums.arcgis.com/threads/23833-How-To-Create-a-Multi-versioned-Spatial-View.
Then I created a "join" view on the two mv views. It works perfectly.