How to load data with Attachments from one feature class to another

[kendiekenmoe]

I use ArcGIS Desktop 10.5 and PostgreSQL 9.5.

I have created enterprise GDB and all my feature classes have attachments. I have some feature classes which have more than 1000 rows and many polygons have two attachments. I want to load data with attachment into another feature class automatically. Is this possible. If yes, how?

https://community.esri.com/groups/geodatabase?sr=search&searchId=e9ab92b0-f351-45ee-b5b4-62d2cb03979...‌ https://community.esri.com/community/gis/managing-data?sr=search&searchId=8e526dc5-7677-4f44-9aff-d0...‌

[George_Thompson]

https://community.esri.com/groups/geodatabase?sr=search&searchId=62cf5844-29a7-41db-b3ee-2aba1dfb4c2...‌  to add a wider audience.

[JayantaPoddar]

Did you try Appending the features, with Maintain Attachments enabled in Environment Setting?

[ValerieHanson]

I had a contractor help me with moving attachment files from the old standardized fc's (SDSFIE) in SQL to a new standardized fc that held the same data but had different field names.  Many of the features had multiple attachments, mostly photos.  My head was swimming as she lead me along during a screen share session.  Argh!  Its the join process that weird's me out.  Hopefully it will help YOU! 

Warning: Before following these steps make sure you have a backup of both the old and new geodatabases!

Steps provided below are for buildings, but the same steps can apply to any other feature classes with attachments.

buildingOrig: refers to the Building feature class in the old SDSFIE schema

buildingNewSchema: refers to the Building feature class in the new SDSFIE schema

Steps:

1. Add OBJECTIDNEW field (long int) to the buildingOrig attachment table.
   
2. Do spatial join between buildingOrig and buildingNewSchema feature class - outputs to a new feature class containing both the old and new OBJECTID.
   
3. You may have to remove and add the spatial join feature class back in - I had a weird issue with the field names until I did this.
   
4. Do a join between the buildingOrig attachment table and the spatial join feature class:

• attachment table join field: REL_OBJECTID
• spatial join feature class join field: OBJECTID

• Keep only matching records
  
  

1. Do a calculate on the OBJECTIDNEW field -> OBJECTIDNEW = joinFC.OBJECTID_1
   
2. Remove join
   
3. Add IGNORE field (short int) to buildingOrig attachment table - This field is used to indicate which buildings already have attachments in the new table.
   
4. Do a calculate on the IGNORE field to 0 for all records (had to do this bc the query during the load data to get all rows not equal to 1 or equal to null didn't work).
   
5. Do a join between the buildingOrig attachment table and the buildingNewSchema attachment table:

• buildingOrig attachment table join field: OBJECTIDNEW
• buildingNewSchema attachment table join field: REL_OBJECTID

• Keep only matching records

1. Do a calculate on the IGNORE field -> IGNORE = 1
   
2. Remove join
   
3. Load Data on buildingNewSchema attachment table
   1. Source data to load: buildingOrig attachment table
   2. Target and Matching Fields

• REL_OBJECTID=OBJECTIDNEW
• CONTENT_TYPE=CONTENT_TYPE
• ATT_NAME=ATT_NAME
• DATA_SIZE=DATA_SIZE
• DATA=DATA      

1. Load only the rows that satisfy a query: IGNORE = 0
   

The following steps will change the attachment relationship to use GlobalIds instead of ObjectIds. This will make it easier to move attachments in the future.

1. Add GlobalId to buildingNewSchema
   
2. Add GlobalId to buildingNewSchema attachment table (if it hasn't already been added automatically)
   
3. Run the Migrate Relationship Class tool