UN version 7, ArcGIS Pro 3.5.4 validation errors - a showstopper?

[DavidSDouglas]

We're planning to upgrade in Production, and have done it in our Test environment. We're having big problems with validation  and can't risk an upgrade in production without a fix. Has anyone one else experienced similar issues? I'm asking before contacting support with the local ESRI partner - it's easier if some else can confirm this issue.

We upgraded from ArcGIS Pro 3.3 and ArcGIS Server 11.1     to 3.5.4 and 11.5
Also Utility Networks upgraded from version 5 to 7 (that took 20 hours)

.NET 8.0 is installed on servers (previously 6.0)

Some functions are running faster than before, faster even than the production environment which has not yet been upgraded - it has most resources. The servers are Windows Server 2022 Datacenter Azure Edition 21H2. The SQL Server database is Microsoft SQL Azure (RTM) - 12.0.2000.8

We have divided Denmark into 27 large polygons and validate these each night using a Python script:

GPextent= ('{} {} {} {}'.format(x1, y1, x2, y2))
arcpy.un.ValidateNetworkTopology(serviceUrlProd,GPextent)

After upgrading, this takes about 30 minutes to run, about half the previous time - also compared to production.

However, interactive validation in ArcGIS Pro using the Validate function on the Utility Network tab times out after 5 minutes even with the smallest extent (a few metres - which took only a few seconds before, and in production). If I attempt to validate again within the next few minutes I get:

Edit operation failed. Message: Unable to complete operation.
Details: Serialization lock in progress [[Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Lock TimeoutX] [Serialization lock in progress - operation not allowed]

Eventually the lock is released - and validation will time out again on the next attempt. This has not been seen in the current production version,even if validation timed out after using too large an extent.

Using Validate Network Topology (Utility Network Tools), these small extents do validate - but it takes 30 minutes!

During editing, no dirty area appears after altering attributes. They do however appear if a feature is deleted.

[samshrma998]

@RobertKrisher . Based on your reply it means whenever the topology goes through enable/disable process new records gets added to the EID_Mapping. 

What is the idle process to maintain the growth of this table while enabling/disabling might be required. 

Is it good practice if the EID mapping table is cleared manually using SQL statement after disabling topology. Assuming mappings will be created again when topology is enabled

[RobertKrisher]

Do not manually run SQL statements to clear out history, that is a sure-fire way to corrupt the versions in your geodatabase. Enabling the network topology populates the table with the new mappings.

The safe way to manage the size of these tables is to

1. Be considerate about how often you are disabling and enabling your network topology or performing bulk updates on branch versioned data.
2. If you need to remove rows, use the Prune branch history tool (read more here). This will safely delete records older than a certain date. If you are not routinely performing other data maintenance tasks with your database, the tool will not be able to remove as much history. I know that sounds vague, read the link I provided above for a more precise description.

[PierreloupDucroix]

Enabling/disabling the topology is an integral part of normal network usage, as it's necessary for tasks such as adding asset types and their associated network rules, categories, or attributes.

Therefore, I understand that we must account for the growth in the EIDMAPPING table each time such an administrative action is performed. This means we must also manage the number of versions persisting in the database and regularly clean up (per scheduled task?) the versions using the Prune Branch History tool.

[RobertKrisher]

@PierreloupDucroix you'll want to ensure that versions are reconciled on a regular basis. You can automate this, but you need to make sure that you don't reconcile a version that already has conflicts! Otherwise, you will automatically accept the conflicts as-is without any record that they existed (the default behavior). If you use Python you can accomplish this with the Reconcile Versions tool by seting the parameter proceed_if_conflicts_not_reviewed to NOT_PROCEED (which isn't the default value).

If you're using REST, or some other means you will need to use the APIs to query for persisted conflicts on the version before you reconcile.