"move" Related table records to a new parent feature

bsanders69

I have a case that I have spent over a year developing a Sign Inventory application.  There has been several stumbling blocks along the way with ESRI limitations of functionality from no Android version of Collector, subtypes groups not working in services, could not use Feature to Feature relationship class relationships, etc.

I have another problem that I believe is not going to be an isolated function to me.  This problem is taking related records from the relationship class and moving them to another parent feature.  My example:

I have a pole Feature class (used as the spatial location) for the pole structure.  The Pole has a 1:N relationship with table "Sign" records related to the Pole.  If the Pole is run over or damaged by a storm, etc. the pole is retired and a new pole is put it in the ground and has an "active" status.   There can be up to six signs on one pole (most I have seen).  If the signs are still in great shape, then they are physically removed from the old pole and bolted or riveted to the new pole.  I can not find any possible way to for them to keep these signs and just move the relationship to a new parent feature.  Retiring and adding them all back in is not a logical methodology.  Those signs are not retired, they are still in use, but on a different pole.  I have created the relationship based on GlobalIDs based on ESRI's strongly suggested method.  This goes beyond Collector, but it definitely should reside in remote field collection apps as the field is where everything happens.

I have spent well over a year of my life developing this solution (much of it was data quality, hence trying to simplify the field collection methodology and may be the first to include EVERY sign style in the MUTCD specifications (except for Interstate-related signs as our City does not maintain anything on those highways.) 

Please help,

Brett

Anonymous User

I am working on this with Parcels and attached documents. The reason I have to create a new attachment table and feature class is due to parcel updates that include geometry as well as address changes.

Documents are stored in the PARCELS_ATTACH table and are related in REL_OBJECTID by OBJECTID from the Historic Parcels feature class. Obviously not awesome. 

First step is to add "rel_tax_id" field to the PARCELS_ATTACH table. Next join the Historic Parcel feature class table to the PARCELS_ATTACH table by OBJECTID. After joining, using field calculator while editing, calculate the "rel_tax_id" field in the PARCELS_ATTACH table to equal the joined "Tax_ID" field of the Historic Parcel table. Save your edits and remove the join.

This table is empty after enabling attachments on the feature class and needs to have the PARCELS_ATTACH table data added to it. Add "re_tax_id" field the the DEV_PARCELS_ATTACH table to ensure the fields match in both tables. Use the Simple Data Loader in Arc Catalog to load the PARCEL_ATTACH table data into the DEV_PARCELS_ATTACH table. 

Once loaded, join the DEV_PARCELS_ATTACH table using the "rel_tax_id" to the DEV_PARCELS feature class table's "tax_id" field. Start editing and use the field calculator to calculate the "rel_object_id" field of DEV_PARCELS_ATTACH to equal the "OBJECTID" field of the DEV_PARCELS feature class joined table. By updating the "rel_object_id" field with the DEV_PARCELS feature class "OBJECTID" values the attachments will become available through the relationship class rule that is generated after enabling attachments.

This solution is an absolute lifesaver considering the number of parcels per county and the number of attachments for each parcel. The key is having matching fields for the data load and being able to correlate the feature class "OBJECTID" to the the "rel_object_id" in the DEV_PARCEL_ATTACH table.