Latest Contributions by EdwardBlair

Thank you, Heather!   We tried and failed when connecting as SDE.   Worked fine when we connected as the data owner Ed ... View more

Great.  Thanks for the info! ... View more

Doh!   I had made a number of changes and neglected to re-enable network topology.    Re-enabling allowed me to trace. In my (meager) defense, sometimes just by writing out a description of the problem helps lead to a solution. Sorry! Ed ... View more

Hi gis_KIWI4! This is just what I was looking for.  Thanks! Ed ... View more

So... suspecting that the issue was rooted in SQL*Server permissions, I granted additional permissions to all users involved and systematically checked in ArcGIS Pro after each change to see if this allowed the process to complete.   None of the permissions changes made a difference. Then, at the suggestion of Jeff Buturff, master of all Geodatabase knowledge, I started SQL*Profiler before opening ArcGIS Pro with the hope of capturing the offending call.    For whatever reason, after starting SQL*Profiler and then starting ArcGIS Pro I was able to create a new version without error.  I suspect that starting the profiler somehow put the previous permissions changes into effect -- but that's just a guess.  At any rate, I can now create versions. Ed   ... View more

Walked through the steps with ESRI Tech Support.  Still stumped.   Here's what we observed/tried: We have a Branch versioned service published to ArcGIS Enterprise 11.2 from Utility network data in an enterprise geodatabase. We encounter the mentioned error when we create new versions on the service. Confirmed from the ArcGIS enterprise portal that the user with which we are connected to the portal in ArcGIS Pro has administrators privileges, has Advanced editing user type extension. From the server manager we confirmed that the service has version management capabilities enabled. We published a new service from the same data and observed that we encounter the same error message. We created a new polygon feature class in the enterprise geodatabase and registered it as branch versioned. We published yet another branch versioned service from the new feature class created with the version management capabilities enabled however when creating the versions encountered the same error message. From the server manager we observed that in the server logs we do not get any additional error rather the same error is mentioned there as well. Tech support is going to research further.   Will post a resolution when we get to one. Ed ... View more

Michael - Thanks for your suggestion to use "Save A Copy".   I tried this and it worked for one of my MXDs (though not all). So... many thanks! But (and I don't mean to look a gift horse in the mouth) is there a way know what "wasn't being used"?    These MXDs are complex animals.   With joins, relates, definition queries, excluded features, etc. etc.  Is there a way for me to know what got left behind? BTW - I found that an MXD *not* resolved by your suggestion was one that had a definition query based on a join - and the join was not updated.   And now I at least know to account for that case. Thanks again for you suggestion.   Much appreciated.   Ed ... View more

Rhett - Thanks for the insights.    Out of curiosity I tried both MXD Doctor and the Defragmenter and, as you suspected, neither of these identified or fixed the problem.     Ed ... View more

Hi Chris - Just wanted to let you know that I tried the python script you suggested.   It didn't find anything broken, but we still get prompted for a database connection when opening the MXD. Ed ... View more

Hi Chris - Thanks for the reply. The thing is, there are no broken data sources in the MXD.  All layers are hooked up correctly to sources.   But we still get prompted for a database connection. Ed ... View more