Need to refresh table views after SDE edits?

1060
9
12-12-2011 10:47 AM
MattSimmons
Occasional Contributor
I've got some table views set up that reference my SDE layers.  When edits are made to the SDE layers they are reflected, but the edits are not reflected in the table views.  My understanding is that table views aren't static, they just reference an SDE layer.  Do I ever need to refresh table views??
0 Kudos
9 Replies
VinceAngelo
Esri Esteemed Contributor
How are you doing these edits?  If you're using versioning, then the changes aren't really
in the tables until after reconcile & post.  If you want the view to reflect other than the
base table contents, you'd need to use multi-version views.

- V
0 Kudos
MattSimmons
Occasional Contributor
Thanks for the reply~  To create the table views I used the sde command:

sdetable -o create_view -T <View_Name> -t <Table_Name> -c <Column 1>,<Column 2>,<Column 3>,<Column 4> -i <> -s <> -u <> -p <>

The table views are now separate feature classes in SDE.  My edits are done using versioning, and there are no edits outstanding.  All edits have been reconciled and posted but are not showing in the table views.  I've verified this by loading the base table into ArcMap and comparing to the table view of the same records.  The table view shows the unchanged data, while the base table reflects the posted edits.
0 Kudos
RobertHu
New Contributor II
You need to compress the SDE GDB.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Doh!  s/reconcile & post/reconcile, post and compress/g

The parts about table contents and MV views were right, though.

- V
0 Kudos
MattSimmons
Occasional Contributor
Did some googling and this seems to be the problem for some - but just tried compressing the DB via ArcCatalog and nothing changed (the compress tool doesn't indicate success or failure - it just runs).  All versions were reconciled/posted and even deleted first, and user connections were severed.  How do I look at the A/D tables to see if there are any changes remaining that didn't make it back to the base tables?

PS - what does "s/reconcile & post/reconcile, post and compress/g" mean?  What do the s and g stand for in your reply?
0 Kudos
VinceAngelo
Esri Esteemed Contributor
It the table has compressed sucessfuly, there will be zero rows in both the A and D
table, and the base table will contain all edits.  You can use any SQL tool to view
these tables (including an ODBC connection through ArcGIS).

The "s{char}{old_pattern}{char}{new_pattern}{char}" syntax is from 'vi' (which
got it from 'ed', as did 'sed').  's' is substitute and 'g' is "global" -- You can interpret
it as "substitute all occurances of old_pattern with new_pattern".

- V
0 Kudos
MattSimmons
Occasional Contributor
I'm using Oracle - what is the actual name of the adds and deletes table I need to look at (via PL/SQL)?
Also, I looked at the compress_log table and can see the compress in the log.  The start state count is 500+, but the end state count is 27.  It indicates "Success" but shouldn't the end state could be zero?
Thanks for your time on this - Hopefully I'm close to getting it figured out~
0 Kudos
VinceAngelo
Esri Esteemed Contributor
It's perfectly valid for a compress to complete without reaching zero rows in the A & D tables.
Keep in mind that ArcSDE versioning uses a tree model to represent potential changes to the
base table -- compress will only reach zero if there are no branches. You need to examine
the tree to see is any states are locked; once the "tree" is a "linked list" all deltas will be
transferred to the base tables by the next compress.

Looking from your Oracle client, identify the table, then look at its indexes; this is one way
(of many) to determine the numeric suffix on the A&D tables.

- V
0 Kudos
MattSimmons
Occasional Contributor
Can you please expand on this?
"You need to examine
the tree to see is any states are locked; once the "tree" is a "linked list" all deltas will be
transferred to the base tables by the next compress."

To my understanding, I need to get the SDE.DEFAULT State_ID back to 0, which I understand indicates all deltas will have been transferred to the base tables.  This is the underlying problem - the SDE layers reflect changes, but the table views (which I believe reference the base tables in Oracle and not SDE) do not see the changes.  Once the deltas are back to base and the State_ID of DEFAULT is 0, my problem should be solved, or so I think...
0 Kudos