Importing Associations leads to Error 31 upon validating service

[VanCityUtility]

Hi there, 

I'm trying to import a set of associations (containment and Junction-junction connectivity) to around 100 features as a test. I am working with an enterprise sde dataset logged in as the Owner and published as a branch service.  I am working on ArcPro 3.1 and Enterprise 11.1.

Here is my workflow:

1. Disable Topology
2. Append new feature data to sde.
3. Import Associations from csv file populated with new Global IDs from appended data
4. Enable Topology
5. Start Service
6. Validate network
7. Receive error 31:  Association record is referencing an invalid to or from global ID.

I have tried various iterations of the above including not disabling the service, importing one type of association at a time, closing Pro at every step, etc., and I still arrive at the same error 31:  Association is referencing an invalid to or from global ID.  The features involved have valid rules for containment and connectivity, I have also checked the Associations table and the associations successfully load and are selectable in the service PRIOR to validating, all with matching global IDs.  Once validated though, the association becomes orange with the error.

Does anyone have experience with this error and may have advice on which step things are falling apart?  My import csvs are an exact replica of the exported data for other features manually added to our service.

Note: I had one successful run on two test features that were manually added to the service first, and the import csv only contained one containment record.

Thanks for your help!

[RobertKrisher]

Can you post some screenshots of the error, features, and associations in question? What do you see in the dirty areas? What do you see in the modify associations tool?

[VanCityUtility]

Hi RobertKrisher, 

Thanks for responding, yes I have some screenshots, all for the same feature, a distribution transformer that's supposed to contain a transformer unit (EJO):

Here's the error in the data inspector:

Associations database table: 

Import csv file: 

Modify associations tool:

And the map.  Note that the dirty areas table does not display a code or message.

Lastly I thought it was interesting that in the attribute pane, I can still navigate through the associations:

This is only containment, so I'm not sure why terminals are adding to the error.  I checked the csv and the terminal fields are null, shown above.  Please let me know if you'd like to see more.

[RobertKrisher · Accepted solution]

It looks like a bunch of your features have no terminalconfiguration (like in the last screenshot). Set their terminal configuration to be default, validate, and see if that fixes the issue.

That value should be defaulted on every feature in the network, and when it is null or invalid it causes many other errors in the model to appear. Make sure that however data is/was being loaded that you initialize that field with the default value.

[VanCityUtility]

Are you referring to the Terminal Path Configuration attribute?  If so.. you might be onto something. I did not validate the features after appending but before importing associations, which might be why this attribute didn't aut-set itself.  That, or I will need to modify the appended tables to set that beforehand.  I will try this and report back.  Thank you very much!

[TrefinaHenry]

Hi Robert, 
When you say every feature in the network should have "default" for the terminal configuration, does that include features like structure lines, electric lines etc.? 

I can't seem to find the "terminal configuration" field for all the features. 

[RobertKrisher]

That field is only on classes that have terminals. Devices and non-spatial junction objects.

[RobertKrisher]

The Terminal Path Configuration attribute needs to be populated when you append the data. If it is not populated when you validate it will not auto populate, it will instead create an error.

[VanCityUtility]

Sorry, you're correct it doesn't auto-populate - I was only looking at the ED features which do have it.  I reviewed the schema coming from the staging gdb and found that this attribute was blank for the EJO records.  I simply bulk edited the service features and validated with success, and a full workflow test was also successful with that fix.  Thank you so much for your help!