Updating a parcel fabric on the SQL server (enterprise geodatabase)

[BobNoyes]

We have been running a test version on the enterprise geodatabase (Microsoft Sql Server 2022) of a parcel fabric dataset for our taxlot editing here in Oregon. I wanted to update the data with the most current work that the cartographers have completed on the real data. I am looking for the best workflow to accomplish this. The data to update with has been moved from the working sql server geodatabase to a file geodatabase and manipulated by the tools created by the ORMAP folks and is ready to bring into the enterprise environment. At this point I could overwrite the existing data, or I thought I could truncate and append the layers. Unfortunately, I keep running into errors trying to do this. I also used delete rows instead of truncate. This works but it also took over 2 days just to process one layer. Not great. Anyone have any suggestions for a better workflow?

[BobNoyes]

I have another question. What is the best point to enable the attribute rules, before or after coping the data to the enterprise geodatabase? Perhaps it doesn't matter?

[AmirBar-Maor]

When the data is copied from a file to an enterprise geodatabase, the table names used in the expressions should be swizzled to the new names. If the rules use table names that are not available in the source and target, I would disable those rules. If that approach fails, you will quickly find out.

BTW - if you want to create an empty schema quickly, instead of using delete rows, you can export an XML workspace (schema only), delete the data, and then import the XML Workspace to create an empty schema.

[BobNoyes]

So, this leaves me with the question what is the advantage of doing the XML workspace over just deleting the existing layers in the enterprise geodatabase and pasting the data from the file geodatabase (once the scripts are run that convert it to a parcel fabric)? The schema, at this point, should be the same. 

[AmirBar-Maor · Accepted solution]

An XML Workspace is useful when you want to create an identical schema in multiple environments, for example - for digital submission workflows, before the data is appended to a named version.

In your case, you are correct - deleting the dataset and copying the updated data from the file geodatabase is the most straight forward. 

The reason deleting rows is slow is because of the messaging that takes place between related tables (relationship classes), the need to update the dirty areas and error tables every time a feature is deleted, potentially firing attribute rules as well.

[BobNoyes]

Awesome! Thanks for the info.