nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

No association records found Streetlight key SupportStructureStreetlights

GISP00

After running the the Create Migration Workspace, the log indicates associations were not found. I validated the relationship class in the map by selecting and retrieving related data. Other associations in the Simple Data Mapping sheet seemed to work. These relationship classes are using GlobalID and appear the same as other relationship classes that did work.

See also the attached for association key configurations. The screen shot is filtered only for these three keys, but other associations are configured in the data mapping sheet.

What else can I do to confirm my configuration is correct or debug the issue?

ArcGIS Pro 3.6.2.59527
udms 3.5
Executing from ArcGIS Pro, 5 map(s), activeMap = False
Loading Workbook
Validating data mappings
Calculating new asset types
Extracting source/target mappings
No association records found DynamicProtectiveDevice key SupportStructureDynamicProtDev
No association records found Streetlight key SupportStructureStreetlights
No association records found Transformer key SupportStructureTransformers

relationshipclass.png

associations.png

GeoeventProcessor.JPG

Survey123.png

Vind meer berichten getagd met

Accepted answers

GISP00

After several hours of Pro running the with the Cutoff Distance method, I decided to end the Pro process in Task Manager and try the method from the tutorial you recommended.

Along the way while stepping through each process the log file informed me there were appx 13K rows skipped. I dug into the source GN data and realized there were "orphan" related features. For example in Streetlights the field SupportStructure_GlobalID had a value but the related Support Structure (pole) was not found in the origin-table. On the flip side there were Null values in SupportStructure_GloabID, which should not be true. Every Streetlight should be related to a pole.

So that caused some Null values in C_Associations after running Sync C Table GP Tool.

I modified the definition query in the data reference sheet hoping to avoid this issue. I think I should have set that query in the data mapping sheet instead. So I did some manual cleanup in the C_Associations table.

Anyway, I have a UN, although it does need the typical data clean up and other items such as new rules for the client's environment.

Thank you the guidance. As for the original error. I do want to try Mike's suggestion to see if that works as well. So for now I will not mark this post resolved just yet.

defquery.png

All comments

RobertKrisher

I'll let @MikeMillerGIS handle questions about create migration workspace, but you should also look at a newer way to migrate relationships described in this tutorial: Migrate relationship classes to a utility network | Documentation

This new approach allows you to map the relationship directly to the associations table, which means that you'll get the latest relationships every time you run the data loading tools. The older approach creates a static CSV file when you create your migration workspace, which leads to relationships and features getting out of sync over time.

MikeMillerGIS

Hard to tell without a sample to test it, but I think the direction is wrong. The Streetlight is the destination in the relationship? If you set the association info on the support structure to the streetlight and not the streetlight to the structure, does that work?

GISP00

Thank you @RobertKrisher I will give that a try with another client project. Your tutorial suggests Pro 3.6. I am limited to Pro 3.5 for this current effort. I am trying a different approach until if/when Mike can provide guidance on the original issue.

As a work around to the original issue, I configured the DataMapping sheet to use Cutoff Distance. The Data Loading tool has been running for about two hours (and still going) with this alternative configuration. The other method finished in 30 minutes. I expected this method to take longer as it is now performing a spatial search to create Associations.

Anyway, thanks for posting great tutorials and blogs. You and the rest of the team publish often and I fall behind in my reading list. I like the new method and look forward to trying that this weekend with another client project.

cutoffdistance.png

MikeMillerGIS

I take that back. Streetlight is the destination, which is what we support. I walked through the code and nothing stands out why it would not work.

The logic queries the streetlight class and extracts the parent global ids from the relationship key field. My only guess is it is because the inputs are listed N times. Could one of them not have rows or a valid relationship?

As a test, if you duplicate the relationship lookup key, make it unique for all streetlight subtypes, does the error message list them all, or just a subset?

So try SupportStructureStreetlights1, SupportStructureStreetlights2, etc

MikeMillerGIS

If it was not working for all the streetlight rows, I would expect an error message for each. I am going to add the def query to the error message so if we encounter this in the future, it would help us hunt down the suspect row.

GISP00

I will try the configuration of unique key names when Pro finishes its current operation using Cutoff Distance. Thank you.

RobertKrisher

@GISP00 the tutorial was last tested on 3.6, but it is works for 3.5 as well.

GISP00

After several hours of Pro running the with the Cutoff Distance method, I decided to end the Pro process in Task Manager and try the method from the tutorial you recommended.

So that caused some Null values in C_Associations after running Sync C Table GP Tool.

Anyway, I have a UN, although it does need the typical data clean up and other items such as new rules for the client's environment.

Thank you the guidance. As for the original error. I do want to try Mike's suggestion to see if that works as well. So for now I will not mark this post resolved just yet.

defquery.png

RobertKrisher

@GISP00 glad to hear that worked. that's something I was going to suggest, when you're relying on a foreign key that isn't always populated on a table to migrate a relationship, its a good idea to put a filter to only try and create associations when the field is populated so you don't get any unnecessary warnings. This is especially important when a class can have multiple relationships (transformer > pole, transformer > vault, transformer > pad).

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.