This is a run down of things to be aware of if you are trying to edit attribute data stored in ArcSDE via Multi-Version Views.
I’m writing this up because the ESRI documentation on
using multi-version views is rather lean, particularly with respect to
managing ObjectID’s and dealing with versions after you’ve made your
updates.
Editing Data Via Multi-Version Views
Multi-version
views can be used to edit attribute data stored in ArcSDE via SQL
statements, but some very specific conditions must exist for this to
occur. The most important condition being that when doing inserts
(creating new records, which will lack a spatial representation), the
multi-version view can not be referencing a version currently in use by
ArcMap. This is explicitly stated in the Multi-Version View documentation.
While
no explanation is given, my investigation leads me to believe that this
is related to the fact that ArcSDE controls the value of the ObjectID
column, but that inserts through the multi-version view’s do not
automatically utilize this functionality. Rather, the developer must
manage the ObjectIDs. The easiest way to deal with this is to use SQL
and get MAX(ObjectID) from the multi-version view , and add 1. However,
if there is an ArcMap session that is also editing this same layer in
the same version, this scheme does not work. This is because ArcMap
“checks out” a block of ObjectIDs as soon as an edit occurs on a
feature in a particular feature class. (This is what those
i[reg#]_get_ids stored procedure is for).
Thus, if edits are
occurring in ArcMap, and an multi-version view is used to insert a
record, assigning ObjectID to MAX(ObjectID) +1, this feature will be in
conflict with any newly added features that are created in the ArcMap
editing session.
Overcoming ObjectID Issues
After
some digging around, I believe that you can use the i[reg#]_get_ids and
i[reg#]_return_ids stored procedures to “check out” a block of
ObjectID’s just like ArcSDE does. I say “believe” because the
application I’m building does not require this because of it’s business
process (inserts go into another set of tables, which are never loaded
into ArcMap or anyother ArcSDE client – thus Max(ObjectID) + 1 works
just fine. Anyhow, as long as you “get” a block of ID’s (I’d suggest 1
at a time so that you avoid having to “return” them) you should be able
to insert records.
Named Versions
Another wrinkle,
which is noted in the documentation, is that you can not make edits
into a version currently in use by ArcGIS. If you try to run an UPDATE
or INSERT query against the MVV while the version is open in ArcMap, an
error is returned. If you run the query in SQL Analyzer, you’ll get
something like this:
Server: Msg 2627,
Level 14, State 2, Procedure SDE_state_def_insert, Line 21 Violation of
UNIQUE KEY constraint ’states_uk’. Cannot insert duplicate key in
object ‘SDE_states’. The statement has been terminated.
Thus,
if there is any chance that there may be an edit session underway, you
will need to create a named version and run the queries against that
version. This works as shown in the documentation – just make a call to
the sde.CREATE_VERSION stored procedure. What the documentation leaves
out is how to then post & reconcile this named version back into
the version that you actually wanted to work with!
While there
are not stored procedures that can deal with this, the developer kit
has is a sample which can help out with this part – check out the “Versioning Service” sample.
Essentially,
you need to use some ArcObjects code to actually post and reconcile the
newly created version. Again, this can be pretty simple, but if there
are edits occuring in ArcMap, then there is a chance you will have
conflicts, which leads to the question of how to resolve them. For my
application, this is not a real problem the data being added via the
multi-version view’s is field data, and thus more correct than anything
that would result from ArcMap edits. Additionally, the user who is
adding this data into the system is the only user who actually has edit
permission to the features that would be effected. (maybe I’ll cook up
a post on feature level security…) Anyhow, if a conflict occurs, the
data from the multi-version view version always overwrites the other
data.. However, this is just another fluke of our client’s business
process.
Summary
While Multi-Version views support
editing, the limitations are onerous, and I suspect by design (I
suspect someone wants you to use a pricy ArcSomething license to edit
your ArcSDE data). However, for read-only usage, they are a really
powerful way to create reports against your enterprise geodatabase.
[UPDATE]
In a comment on the original post when this was on ArcDeveloper.net, Neil noted the following:
Here’s some additional stuff on the objectids issues you mentioned, at
least for the version of sde I’m working with – 9.1 SP1 with MSSQL
2005.
It looks like you can just leave the OBJECTID column out of the insert statement.
There is an insert trigger on the multi-version view that calls the
_get_ids & _return_ids stored procedures that you mentioned to
generate the objectid.