attachments and geoprocessing

1617
6
Jump to solution
05-09-2012 06:50 PM
ZorbaConlen
Occasional Contributor
Hi.
Tried this in a different forum but no response so trying my luck here.

I have a FC which has attachments associated to it - one or more photos per feature. Now, I need to project the FC to a different coordinate system. The output from the projection GP tool is a new FC. This new FC does not have attachments. I suspect that any GP process that creates a new output will likewise drop the attachments. So, is there a way to keep the attachments for the output FC? Or some way to re-connect them after the GP task?

Attachments are pretty cool, but this issue seems like a serious problem unless someone knows a solution.

Thanks.
0 Kudos
1 Solution

Accepted Solutions
DrewFlater
Esri Regular Contributor
I've revisited the steps that I set out in the previous email and realized there was some mistakes. Please refer to the steps below for instructions to transfer attachments.

This workaround is only valid if the geoprocessing operation you are performing does not reorder ObjectIDs (the Project tool DOES NOT reorder ObjectIDs). You can test this by running the tool, then checking the output dataset -- if each of the records in the input dataset have a corresponding record in the output dataset, and the ObjectIDs match, then you should be able to use the steps below.

1. Run the desired geoprocessing tool, like Project (management).
2. Right-click the output feature class and create/enable Attachments. This will create an empty __ATTACH table and a relationship class relating that table to the output feature class.
3. Use the Append (management) tool to append the original feature class' __ATTACH table into the output feature class' __ATTACH table. The __ATTACH table is where the attachments are actually stored (in a BLOB field) so appending these records is a key step. Input Dataset = input__ATTACH; Target Dataset = output__ATTACH.

View solution in original post

0 Kudos
6 Replies
DrewFlater
Esri Regular Contributor
A quick note before my response: for the 10.1 release, 5 new tools have been added to the Data Management Tools toolbox for adding and managing attachments. This will make working with attachments in general much easier, especially when doing batch jobs. With that said, the issue of attachments not being carried over to new geoprocessing outputs has not been addressed, so a workflow like I describe below will still be necessary and applicable.

Learn more about the Attachment toolset

Geodatabase attachments are stored as BLOBs in a table which is connected to your feature class via a relationship class. You can find this associated table and relationship class in the same geodatabase as your feature class (they are named the same as the feature class, but with __ATTACH and __ATTACHREL suffixes). Like you have observed, when a geoprocessing tool creates a new output from the feature class, as the Project (management) tool does, the attachments associated with the input feature class are not carried over to the output feature class. Here are a few steps you can do to "re-relate" the attachment table that stores the attachments with your new output feature class.

1. Add a Long Integer field to the input named 'IN_FID', and calculate it equal to the input's ObjectID field. We want to keep track of these original ObjectIDs since the attachments relationship class uses ObjectIDs as key fields, and many geoprocessing tools may reorder ObjectIDs, especially in the case where there are some values missing.
2. Run the desired geoprocessing tool, like Project (management).
3. Right-click the output feature class and create/enable Attachments. This will create an empty __ATTACH table and a relationship class relating that table to the output feature class.
4. Delete the output__ATTACHREL relationship class.
5. Use the Append (management) tool to append the original feature class' __ATTACH table into the output feature class' __ATTACH table. The __ATTACH table is where the attachments are actually stored (in a BLOB field) so appending these records is a key step. Input Dataset = input__ATTACH; Target Dataset = output__ATTACH.
6. Right-click on the output geodatabase and select to create a new relationship class. The origin will be your output feature class, and the destination will be the output__ATTACH table (the target dataset from Append). This relationship class should be Composite, 1 - M, with No messaging and no additional attributes. Select IN_FID as the primary key field, and REL_OBJECTID as the foreign key field.

That's all! Your output feature class will now have the same attachments as your input.

Let me know if you have any questions, and good luck!
Drew - Esri
0 Kudos
ZorbaConlen
Occasional Contributor
Drew,
Thanks for the response. I will try this approach.
0 Kudos
DrewFlater
Esri Regular Contributor
I've revisited the steps that I set out in the previous email and realized there was some mistakes. Please refer to the steps below for instructions to transfer attachments.

This workaround is only valid if the geoprocessing operation you are performing does not reorder ObjectIDs (the Project tool DOES NOT reorder ObjectIDs). You can test this by running the tool, then checking the output dataset -- if each of the records in the input dataset have a corresponding record in the output dataset, and the ObjectIDs match, then you should be able to use the steps below.

1. Run the desired geoprocessing tool, like Project (management).
2. Right-click the output feature class and create/enable Attachments. This will create an empty __ATTACH table and a relationship class relating that table to the output feature class.
3. Use the Append (management) tool to append the original feature class' __ATTACH table into the output feature class' __ATTACH table. The __ATTACH table is where the attachments are actually stored (in a BLOB field) so appending these records is a key step. Input Dataset = input__ATTACH; Target Dataset = output__ATTACH.
0 Kudos
kevinkent
New Contributor
Hi Drew,

Do you have any suggestions for workarounds when combining feature classes, such as with the merge or append tool. For example if I have 2 feature classes, each with one feature that has a document attached and merge them into a new feature class, as noted the attachments are lost. However, if I re-add the attachments to the _ATTACH table using the append tool, the relationship class says they both belong to the feature with ObjectID = 1. That is to say, the first record in the attribute table gets both attachments, while the 2nd gets none.
Similarly, If I append one dataset to the other, the target's attachments are maintained, but the input's are not. Append the input's _ATTACH table to the targets again assigns the input's attachments to the target's feature with ObjectID = 1.

Any ideas on how to work around this (especially with a scaleable solution), would be greatly appreciated.
0 Kudos
KeithGanzenmuller
Occasional Contributor II
Kevin,
   Did you ever solve the issue concerning appending Featureclasses that contain attachments?

Keith
0 Kudos
MatthewAyres
New Contributor
Hi Drew,

Do you have any suggestions for workarounds when combining feature classes, such as with the merge or append tool. For example if I have 2 feature classes, each with one feature that has a document attached and merge them into a new feature class, as noted the attachments are lost. However, if I re-add the attachments to the _ATTACH table using the append tool, the relationship class says they both belong to the feature with ObjectID = 1. That is to say, the first record in the attribute table gets both attachments, while the 2nd gets none.
Similarly, If I append one dataset to the other, the target's attachments are maintained, but the input's are not. Append the input's _ATTACH table to the targets again assigns the input's attachments to the target's feature with ObjectID = 1.

Any ideas on how to work around this (especially with a scaleable solution), would be greatly appreciated.


I had the same issue when trying to append two feature classes with related attachment tables.  This is the work around I came up with. Hopefully ESRI will address this issue in later releases.

Start by adding both feature classes into your map.  Create two new fields in each feature class. The first, a field labeled indicator (Short integer), the second an OldID field (Long integer) (you want to preserve the old ObjectID-you will use this when joining). To preserve the old ObjectID, field calculate the OldID field to equal the ObjectID field in both feature classes. Next, from the source feature class that you will be copying and pasting to the target, field calculate the indicator field so that all features have the value of 1. Start an edit session, select all features in the source feature class. Copy these features and paste them into the target feature class. All the features should now have a new ObjectID. We still have the old one in the OldID field which is key. Now select by attributes all features that have a value of 1 from the indicator field.  Export these features out as a dbf.  Add that table into Arcmap.  Add the attachment table that was related to the source feature class prior to pasting into the target as well. Join the exported table to the attachment table by RelObjectID (AttachTable) and OldID (Export table). Once joined, field calculate the RelobjectID field to equal the new ObjectID that was assigned after pasting to the target layer.Once this field calculation is complete remove the join. Now add the attachment table associated with the target feature class to the map. Append the two tables- Source to target, just like the copy-paste.  This should solve the issue. I hope this helps and that I made sense.:D
0 Kudos