Utility Network Edit Won't Commit

[JK9]

We have a brand new utility network implementation, and I'm attempting to perform a routine edit: disconnecting a lateral from a main and reconnecting it to another. The line snaps back to it's original position, without any error in Pro or the server log. 

I assumed it was a rule issue and exported the network to a file geodatabase for testing. In the file geodatabase the edit performs just as expected with all of the same rules. 

What could stop the edit from committing in our enterprise database? 

[RobertKrisher]

Do you have any constraint attribute rules configured on the dataset? Check the ArcGIS Server logs for any warnings or errors.

[JK9]

There are no constraint rules, but we do have attribute rules for assigning asset id's and location info. I've set the ArcGIS Server Log to debug, but nothing looks out of the ordinary. 

Although I have just realized I'm unable to change the asset type on a few laterals, so it appears we have something else going on. 

[gis_KIWI4]

@JK9 - It is weird that you are seeing different behavior on the eGDB and after you copy it to the fGDB. 
Can you share some screencaptures of what you are trying to achieve. 

[JK9]

@gis_KIWI4  Screen captures below showing performance in our enterprise geodatabase vs a file geodatabase.

[gis_KIWI4]

@JK9 - Nothing obvious in the screen captures.
The lines seem to be snapping to the devices. 

I think it could be attribute rule that might be failing to evaluate properly

The fact that you mentioned you have attribute rules and it works in the fgdb point suggests that issue maybe tied to database rules that only exist in the EGDB environment 

[PierreloupDucroix]

Are you sure you're not editing in Default that is protected ?

[RobertKrisher]

If edits are failing, there really should be something in the ArcGIS Server Log. Try it with the log level set to warning (to make it easy to find any errors). Setting it to debug level can help you track it down to something like an attribute rule firing, but be prepared to sift through a lot of edits.

If you haven't already, consider logging a case with support on this.