Select to view content in your preferred language

delete/append order of operation with relationships.

843
6
Jump to solution
02-06-2024 07:35 AM
Labels (3)
clt_cabq
Frequent Contributor

Is there an order of operations requirement when updating a feature class and related table - such as, do you have to update a feature class first before the related table? I have a geodatabase (sql server backend) with a feature class and a related (1:M) table that I update once a month. I run (manually) a delete/append operation against both of these items after I've updated data in a staging database. I use truncate table to delete the existing rows in the gdb table. I always inspect the table to make sure all records match the source table, especially the field that is used to relate to the feature class. I've found that I can inspect the table and find all values in the related field have updated, but then after I run the delete/append on the feature class, it appears those related values in the table 'disappear' everytime. For instance I ran this update today and had 0 null values in the relate field before updating the feature class but afterwards there were about 96K out of 98K records with null values in the related field in the table. Typically I am running the truncate/append operation first, then the delete/append on the feature class, and if i redo the truncate/append process a second time, everything comes through with no issues.

0 Kudos
1 Solution

Accepted Solutions
MarceloMarques
Esri Regular Contributor

You should

1. truncate the related table

2. then truncate the featureclass

3. then reload the data

4. load the featureclass

5. load the related table

If the geodatabase relationship class 1:M is based on GUI values then nothing to worry.

If you are using ObjectID then you might need to preserve the original objectid value in the featureclass as a new field e.g orig_oid and preserve the related table foreign key value as a new field as well e.g orig_oid_fk, then you can repopulate the related table foreign key value with the new objectid of the featureclass using the original ObjectID values.

I hope this helps.

| Marcelo Marques | Esri Principal Product Engineer | Cloud & Database Administrator | OCP - Oracle Certified Professional | "In 1992, I embarked on my journey with Esri Technology, and since 1997, I have been working with ArcSDE Geodatabases, right from its initial release. Over the past 32 years, my passion for GIS has only grown stronger." | “ I do not fear computers. I fear the lack of them." Isaac Isimov |

View solution in original post

6 Replies
MarceloMarques
Esri Regular Contributor

You should

1. truncate the related table

2. then truncate the featureclass

3. then reload the data

4. load the featureclass

5. load the related table

If the geodatabase relationship class 1:M is based on GUI values then nothing to worry.

If you are using ObjectID then you might need to preserve the original objectid value in the featureclass as a new field e.g orig_oid and preserve the related table foreign key value as a new field as well e.g orig_oid_fk, then you can repopulate the related table foreign key value with the new objectid of the featureclass using the original ObjectID values.

I hope this helps.

| Marcelo Marques | Esri Principal Product Engineer | Cloud & Database Administrator | OCP - Oracle Certified Professional | "In 1992, I embarked on my journey with Esri Technology, and since 1997, I have been working with ArcSDE Geodatabases, right from its initial release. Over the past 32 years, my passion for GIS has only grown stronger." | “ I do not fear computers. I fear the lack of them." Isaac Isimov |
clt_cabq
Frequent Contributor

@MarceloMarques thanks! I'll try this approach next time around. The related field is neither the GUID or Object ID but a unique parcel value.

clt_cabq
Frequent Contributor

Just reporting back - i followed this sequence in my manual processing of these data this morning and it worked perfectly well. Next steps are to automate this process so the comments about wrapping this into a transaction will be helpful.

0 Kudos
clt_cabq
Frequent Contributor

@danaharre I'm not sure what you mean by wrapping the update operations in a transaction, can you give me an example? 

0 Kudos
MarceloMarques
Esri Regular Contributor

@clt_cabq - RDBMS Transactions, see SQL Server example
BEGIN TRANSACTION (Transact-SQL) - SQL Server | Microsoft Learn

Oracle, SQL Server, PostgreSQL support Transactions.

And if you are using ArcGIS Pro Python ArcPy or the ArcGIS Pro .NET SDK then the API also has methods to work with transactions.

Arcpy editor transaction rollback - Esri Community

| Marcelo Marques | Esri Principal Product Engineer | Cloud & Database Administrator | OCP - Oracle Certified Professional | "In 1992, I embarked on my journey with Esri Technology, and since 1997, I have been working with ArcSDE Geodatabases, right from its initial release. Over the past 32 years, my passion for GIS has only grown stronger." | “ I do not fear computers. I fear the lack of them." Isaac Isimov |
0 Kudos
clt_cabq
Frequent Contributor

Thanks @MarceloMarques, currently I'm running this simply in a manual set of procedures, but one of my upcoming tasks is to automate this (using python) as the last step of several procedures, so these references really help.

0 Kudos