Versioning, Editing, Reconciling Related Tables with ArcSDE/Server and ArcPad

[GreigOldford]

The saga continues. 

Editing related tables using ArcSDE/Server versioning, relationship classes, and ArcPad 8 or below is a nightmare, to put it bluntly.  I have a number of questions/issues about this process and I'm sure many other people do too.  Let me first distill what could be a long rant into a sentence:  why has ESRI treated relationships among non-spatial and spatial tables as an afterthought when creating software for distributed database editing? 

[INDENT]I'm using:
ArcGIS Desktop 9.3
ArcPad 8 with ArcPad Studio
ArcServer on an Oracle database

My database:
two spatial feature classes
at least 16 related tables. [/INDENT]

Here's why I have related tables: because one point can have many surveys - different survey types and/or different survey dates.  My hunch is that many more people have a similar database setup than ESRI acknowledges.  This quote may sum up the philosophy at ESRI
[INDENT]
"For most reconcile operations, no conflicts should be encountered. This is because in most organiza... [/INDENT]

Sure, but what if two users are editing the same non-spatial table?  This does not happen often with versioned and distributed related tables among multiple field data collectors - it happens every time a new feature is created.

I hope you great folks out there working on this stuff have encountered a few issues that I have.  Here are a couple specific issues I've encountered with ArcPad. 

[INDENT]1) To check out a feature class using the ArcPad Data Manager toolbar and bring the related tables there needs to be relationship classes created.  However, when checking out the actual data (not just the data schema) multiple relationship classes relating two tables will cause much of the data to be left behind.  For example, say table A relates 1:M with table B, Table A relates 1:M with table C, and table B also relates 1:M with table C.  This is often a rational schema in normalized database design.  But, a setup like this will cause much of the data to be left behind upon export.  I had to delete the third relationship class in this case.  

2) Any tables "parent" to the feature class or "parent" to "child" related tables exported are left behind.  For example, if the feature class is called 'SITES' and each SITE is a member of one SYSTEM (the parent table) then 'SYSTEMS' table is left behind when you 'Get data for ArcPad.'  Secondly, if a "child" table of SITES, say SURVEY1 has a "parent" table called SURVEY_TYPE then SURVEY_TYPE gets left behind. 

3) Just generally, how does the check-in / reconcile process work with related tables when there's a conflict? I am just struggling through this but am I wrong to assume that if there is a conflict between a primary key value in one table and that value is then changed, the changes are only perpetuated to the other related tables if the relatioship class is a 'composite' relationship?  Or are these changes synchronized through 'message propagation' in the relationship class? 

Many thanks in advance for any discussion/help!
[/INDENT]

[BobSolley]

have you figured out the problem with editing conflicts on related tables?

[RolfBroch]

Correct me if I am wrong but I thought that in ArcPad 8 and later versions, 1:M relationships from a featureclass to a table are supported but not table to table relationships.

Are you trying to have table to table relationships?

Rolf

[JasonTipton]

Correct me if I am wrong but I thought that in ArcPad 8 and later versions, 1:M relationships from a featureclass to a table are supported but not table to table relationships.

I know for a fact that if Feature Class "F" is related to Table "Ta" and "Ta is related to Table "Tb", you cannot set that up in ArcCatalog. When you try to relate Tb to Ta it complains that it already is involved in a relationship.

You can actually do it as long as you make the relationships "simple" instead of "composite" but NEVER under any circumstances should you ever use "simple" relationships when using ArcPad if you are using the Data Manager to check-in/out data.

I never tried just a table to table that wasn't already related to a feature class though.