Table with Attachments to Feature Class

[MatthewMassey]

I'm struggling with a problem and I feel like I'm missing something obvious. I'm trying to migrate a non-spatial table with attachments to a feature class with those same attachments. I'm working in ArcGIS Pro 2.9.1, and the non-spatial table has the X and Y fields. I've tried several things...

1. "Display XY data" with the non-spatial table. Unfortunately, this doesn't maintain attachments.
2. "XY table to Point". Same problem...unable to maintain attachments
3. Editing the relationship class between the non-spatial table and attachment table. Unable to change origin from non-spatial table to new feature class.

Any recommendations without going back to the original attachment images, creating new match tables, etc?

[HuubZwart · Accepted solution]

Going back to the original images may be quicker 🙂 

But it is possible... 

1. In your original table, make sure you have some sort of unique ID field

2. In the original attachments table, join this ID field to the attachment table using objectid

3. Use Display XY data as described on the original table

4. Enable attachments on the now created new feature class

5. Add the ID field to the new attachment table

6. Append the old attachment table to the new feature class attachment table

7. Join the objectids from the new feature class to the new attachment table using the ID field

8. Recalculate the parent objectids 

9. Delete the excessive fields from the feature class

Your new feature class now has the correct attachments!

[MatthewMassey]

Yes, this worked! One of my problems was that I had GlobalIDs in the original tables, which were causing problems when trying to migrate attachments to a new feature class. But after creating a new GDB and deleting GlobalID, this worked perfect. Thanks!

[Allie]

Whew, took some mental aerobics but I got it too! Thanks!

[FourCornersMapping]

This is what I ended up with, which worked well if a little clunky.

In the end, I need to create an Attachment Viewer Instant App, so I need a layer with attachments, not related records. Also, I wanted to have a "backup" of the data from a Survey123 survey, instead of working with the original feature layer.

Here was my workaround, the steps of which you can likely do programmatically rather than piecemeal:

1. Run the script in this Notebook. The script creates: 1) a spreadsheet containing the records from the survey containing two sheets: the attribute table of the feature layer and the related photo table, 2) a csv describing what attachments correspond to each record, and 3) a folder for the attachments (photos, in my case).
2. I used XY Table to Point to create a feature class from the xy values of the attribute table sheet (in the spreadsheet).
3. Using the Add Join tool, I joined the related photo table (from the spreadsheet) and the attachment csv by the ObjectID and Parent objectId fields, in that order. 
4. Finally I used the Add Attachments tool with the input dataset being the XY Table to Point results, and the match table being the joined table from the previous step. The input join field is the GlobalID and the match join field is ParentGlobalID. The match path field is one of the fields created by the script in the attachment csv ("Attachment path"), and the working folder is the directory set up by the script (i.e. C:\Users\etc).
5. Boom. Eat a sandwich, drink a beer, continue with your life.

I hope this helps some others in the same boat.

[MandP]

To add on some further help for the next person coming along also...

We had a feature class with photo attachments populated using field maps but surveyed accurately separately to the app. So we had a X, Y and Z fields to which the data needed to be shifted to put it in the correct location. As above, the 'XY Table to Point' tool worked fine for this but didn't carry across the attachments. We've created the attached (pun intended) toolbox with each tool working together to update the locations of data and carry across the attachments (for some reason it wasn't working within the single model for the XY Table to Point part but splitting it worked). This solution is based on the above methodologies.