I’m running into an issue that has been unexpectedly difficult to diagnose in a Telecommunications Utility Network (Version 7). We’ve received few reports where features configured with
Cascade Deletion semantics do not always remove their contained elements as expected, and after many attempts we’ve been unable to identify a consistent pattern which helps us to fix it one way or another:
Sometimes the deletion works correctly and removes both the parent device and all its internal content, while other times it only deletes the parent device and leaves all of its internal components in the database. We’ve tested this in an Enterprise Geodatabase (EGDB 11.3), where in certain cases the delete operation enters a long SQL loop querying the Associations table until it times out, resulting in no deletion at all, yet under the exact same conditions it sometimes succeeds.
Validating the topology or saving edits makes no difference, as both success and failure occur regardless of whether it is validated and/or saved. We also replicated the scenario in a mobile geodatabase created from an Asset Package (so the data is identical), and in this environment the delete operation always executes, but with the same inconsistent behavior in which the internal content is sometimes removed and sometimes preserved.
As for Attribute Rules, we do have rules triggered on DELETE and UPDATE, but we disabled them entirely for testing, and the inconsistent deletion behavior still occurs. Also mention that few ways of deleting have been testes (using the Selector and right click > Delente , through the atribute Table deleting the row and using the Attribute Pane)
Has anyone experienced similar issues with Cascade Delete in a Utility Network, or can suggest tests or diagnostics that might help us identify the underlying pattern?
Thanks a lot to everyone who can drop any sort of light 🙂
