Latest Contributions by EdwardBlair

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

For what it's worth, I also tried assigning the editor user the User Type "ArcGIS Advanced Editing", and got the same result. ... View more

David - Thanks much for the suggestion.   I've considered this as well and I thought I had my bases covered, but maybe not.   I'm using SQL*Server.  Here are the permissions granted to my editor user: - Server Roles: - The schema containing the UN data is named GISADMIN.   I've granted my editor user SELECT, INSERT, UPDATE and DELETE on this schema.  Out of desperation I granted the same to the SDE schema. - Also the editor user has the Enterprise user type "Creator" If I'm missing something I would greatly appreciate any pointers. Thx, Ed   ... View more

On the off chance that there might be another "TestVersion" lurking somewhere unseen in my database, I tried again with a version name I sure does not exist.   Same result:   ... View more

It seems the steps that created this condition (at least in our case) were: - Drop the geometric network - Un-ArcFM-ify all classes in the feature dataset It seemed that after dropping the network all contained classes were un-ArcFM-ified, so that afterward the "Un-ArcFM" operation actually did nothing.   However, one of these steps did not perform exactly as expected.   So that while after the steps were completed it *seemed* that the ArcFM class extensions were removed, in fact they were not. Ultimately the work-around appears to be: - Re-ArcFM-ify the classes - Confirm the classes are actually ArcFM classes - Un-ArcFM-ify the classes I tried these steps in a test environment and afterward was able to add them all to an ArcGIS Pro project. (Hopefully the last post in this thread) Ed ... View more

So... I dug in closer and examined the Definition column GDB_Items table (sorry ESRI folks) for one of the problem classes.   In this case it was a CapacitorBank -- previously an ArcFM Simple Junction, but as presented in ArcCatalog now just a "Point" feature class.   What I found in the EXTCLSID tag in the Definition XML was this: <EXTCLSID>{91BC9A23-B210-4EE5-B524-93BCD640E58D}</EXTCLSID> Which, per the SE ArcFM site is an ArcFM class extension for simple junction features (below). How this remained after I had "un-ArcFM-ified" the feature class I don't know. However, I modified the Definition XML to remove the class extension (again, sorry ESRI) so it now looks like this: <EXTCLSID /> I *now* can add the feature class to an ArcGIS Pro map. Pretty sure there has to be a better way to do this. Ed   ... View more