Relationships not replicating properly

964
6
10-09-2017 01:34 AM
Highlighted
New Contributor II

Like many organisations, we have an editing database and a publication database, and we use Esri 1way replication to keep the versioned feature classes in sync.  To complicate matters, we have geometric networks and many relationship classes as part of the replica.  

We have long observed that some of the relationships do not make it across - that is feature x is related to feature y on our editing database, but they are not related on the publication database, aka the replica target.  We have never been able to reproduce this, and when investigated in the past, the discrepancy counts were low enough that we didn't think it warranted too much digging.  

However, we found today that at least for one subtype of one feature class, the results are pretty disastrous.  There are approximately 60,000 records of this particular subtype, all of which should have a related feature.  On the editing database, about 600 do not have the required related feature.  These are likely data errors, but only affecting 1% of the data...we can manage that.  But on the publication database, roughly 30,000 of these features are lacking their related feature!  Half!  And I of course expect we will find some similar ratios as we expand our analysis.

So my question for all you out there in GeoNet world - has anyone seen this before??  Any ideas as to what might be happening?

Reply
0 Kudos
6 Replies
Highlighted
Occasional Contributor II

Hi David-

 Sorry to hear about the inconsistent replication issues with related records. A few quick questions for you:

  • What version of ArcGIS Desktop are you currently at and what version(s) geodatabases (parent and child)?
  • What DBMS is used for the parent and child?
  • For data experiencing this behavior- by chance does the name of the relationship class match the name of the related table or feature class that it relates?
  • In the past- has the relationship class or related table name been edited or changed since the replica was created? Doing so will make it seem like items are syncing properly- however they really aren't.
  • Have you attempted to remake/recreate the replica with fresh object registration and try to sync to the child gdb to see if the missing records come through?

Kind regards,

Rex

Reply
0 Kudos
Highlighted
New Contributor II

Thanks for responding Rex.  Answers:

  • What version of ArcGIS Desktop are you currently at and what version(s) geodatabases (parent and child)?
    • 10.2.1 for both clients and gdb
  • What DBMS is used for the parent and child?
    • Oracle 11g
  • For data experiencing this behavior- by chance does the name of the relationship class match the name of the related table or feature class that it relates?
    • The naming scheme for the relationship class is FeatureClassName1_FeatureClassName2.  Important to note - these are featureclass : featureclass relationship classes where we are seeing the problem, not limited to featureclass : table relationship classes.  We only have a couple of the latter, and believe they are OK.
  • In the past- has the relationship class or related table name been edited or changed since the replica was created? Doing so will make it seem like items are syncing properly- however they really aren't.
    • None of these tables names or relationship class names have changed since they and the replica were created.
  • Have you attempted to remake/recreate the replica with fresh object registration and try to sync to the child gdb to see if the missing records come through?
    • No.  That is something we would like to do, but we think the business impact would be too great.  It will take at least 3 days to rebuild the replica.  And we have no confidence this will actually solve anything; we think it will just mask the issue for some time.
Highlighted
Occasional Contributor II

Hi David- thanks for the additional information. Since you are at 10.2.1 are you in the Utility industry or on any of the UTUP patches for 10.2.1? If you haven't already, I'd suggest setting the replica log level to the highest / most verbose setting and attempting a synch to see if any errors or warnings appear in the replica log level as described here: How can I access the Replica log? | Esri Australia Technical Blog and here: The replica activity log—ArcGIS Help | ArcGIS Desktop Perhaps this might shine a little light on the source of the issue. 

 One other question which might be a shot in the dark- do any of these feature classes participate in multiple (2+) relationship classes where the same foreign keys may be shared between relationship classes? For example, let's say we have three feature classes participating in two separate relationship classes but share the same foreign keys? If the foreign key values themselves are not consistent between all three I know there have been issues where this can result in null / missing values after synchronization. However, if all three related tables / feature classes share the same values between the primary / foreign key, the foreign key is not nullified in the child so this behavior is very dependent on the values of the keys themselves.

Reply
0 Kudos
Highlighted
Occasional Contributor

Did you ever solve this issue?  I too am having issues with missing features and tables that are completely empty.  I have manually joined them up to check that the IDs were proper so I am not sure what this issue could be.

I'm using 10.4.1 across the board and even tried an internal direct on the SDE itself checkout and was still missing the same records.  I cleaned up the data and compressed the database and ran all the administration cleanup tools I can find.  I am using SQL Server 2012.

Reply
0 Kudos
Highlighted
MVP Regular Contributor
Highlighted
Occasional Contributor

I discovered this yesterday after posted that.  The problem I had was that the "schema only for tables" is actually the opposite, it's a toggle button and it sucks.  I also rebuilt those 10 records that were in the main feature class and now everything comes through perfectly!!!!!

Reply
0 Kudos