Registered as versioned and moving edits to base - No data in base table (Oracle11g)

219
6
12-11-2013 12:27 AM
Highlighted
New Contributor
I've got problem with save edits into main table.

The problem is as follows:
- Database: Oracle 11g
- ArcSDE Version: 9.3.1
- Main table: SDE.TestTable - Registered as versioned and moving edits to base
- Delta tables: A921 and D921
- Versions: Default (only)

When I made edition (add, delete Feature; edit atributes; etc.) all changes are saved in delta tables.
As I know, it should be save in base table (like I make it on MS SQL), however it doesn't.

I read in other post, that I should to make Full Compression of geodatabase.
Because I dont have any other version than Default, I didnt make Reconcile, Post and Delete other versions. I'm sure that no one user is connected.
I performed Compression.

At the end, nothing is happen, I have still added feautures in delta tables.

Therefore, where is the problem? What could I do to be sure that all data are in base table.
Reply
0 Kudos
6 Replies
Highlighted
MVP Regular Contributor
Please run SELECT * FROM SDE.VERSIONS to verify that SDE.DEFAULT is the only version. 

Please also run SDEGDBREPAIR -O DIAGNOSE_TABLES -V ALL (refer to esri help for remainder of command) to check if there might be issues in your state lineage

Please also run SDEGDBREPAIR -O DIAGNOSE_METADATA (refer to esri help for remainder of command)
Reply
0 Kudos
Highlighted
MVP Regular Contributor
Also you may wish to run SELECT * FROM SDE.COMPRESS_LOG ORDER BY START_TIME DESC to see if your compress is finishing or failing.
Reply
0 Kudos
Highlighted
New Contributor
Test 1
SELECT * FROM SDE.VERSIONS

DEFAULT SDE 1 1 7289 Instance default version. (null) (null) (null) 13/07/22

Test 2
SELECT * FROM SDE.COMPRESS_LOG

120379 5312 N 13/12/11 7068 13/12/11 2 SUCCESS
120381 9580 Y 13/12/11 2 13/12/11 2 SUCCESS
120381 9580 Y 13/12/11 2 13/12/11 2 SUCCESS
120382 4012 N 13/12/11 2 13/12/11 2 SUCCESS


Test 3
sdegdbrepair -o diagnose_tables -d ORACLE11G -V all

143 rows referencing nonexistent states found in SDE.A261 (SDE.GIT_OS_ULICY_PRE)
464 rows referencing nonexistent states found in SDE.A869 (SDE.GIT_OS_ULICY)
Diagnose Tables: 12 multiversioned tables examined, 2 multiversioned tables had orphaned, duplicate, missing or redundant rows.

(Remind: I have problem with SDE.A921(SDE.TestTable)

Test 4
sdegdbrepair -o diagnose_metadata -d ORACLE11G

ESRI ArcSDE Server Repair Utility Wed Dec 11 13:41:59 2013
---------------------------------------------------------------
All versions reference valid states.

All states have valid parent ids.

All lineage entries have valid state ids.

All states have valid parent ids.
Reply
0 Kudos
Highlighted
MVP Regular Contributor
Per your results from step 3, please go ahead and run sdegdbrepair -o repair_tables -d ORACLE11G -V ALL (with the rest of your connection information).  Doing so should fix the issue uncovered with your A table.  Once complete, please perform another compress and let me know if records begin appearing in the base table as expected.
Reply
0 Kudos
Highlighted
New Contributor
Thanks for your help, everything works fine.
I found old connection (from October) which could not be delete. After delete this connection (restart machine and sde kill) Compression resolve my problem.
However, when I edit with ESRI client (ArcMap), edits go to main table, edition from GeoTools still write edits in delta tables.

I think that I will have to make schedule Compression proces.
Reply
0 Kudos
Highlighted
MVP Regular Contributor
You need to verify which transactional version to which you are connecting when making edits using the tools you mention as well as when editing via ArcGIS Desktop.  You may be seeing edits appear in the base tables because you're editing SDE.DEFAULT directly, which is bad practice in any editing environment.  Regarding what you said for a scheduled compress operation, yes I agree that you should run a compress regularly.  Create a batch file that does this and emails you the current state ID from before and after the compress so that you know what is going on with your geodatabase each day/week depending on your compress frequency.
Reply
0 Kudos