Enterprise GDB features repeat symbology

[JoeBorgione]

Some time back I created a project where I assigned a specific Unique Values symbology scheme to a feature class in our enterprise gdb (aka SDE).  Now when ever I add that feature class to a new project, I get that symbology.  It seems to be a property at the EGDB level as a coworker confirmed when he adds the feature class he gets the same symbology.

What causes this and how do I suppress it?

Edited moments later:  I added the same feature class to a new project and changed the Unique Values symbology.  But when I now create a new project, that new symbology does not show up, the other one does...

(My apologies if this is a repeat post: I thought I asked about this already but could not find any mention.)

[JoeBorgione]

I'll forward this thread to the tech support analyst working on my case.

[JoeBorgione]

@KeithOlson  @DavidPike  @Asrujit_SenGupta 

I've been working with ESRI Tech support on this and at the moment, have a work around:

If you recalculate the spatial index of the feature class, the symbology behaves itself.  I have no idea why but I just tried it on a test feature class, and then on my production feature class.  I'm not a fan of work arounds.

However, from an email conversation with the support analyst, I was offered this pearl of wisdom:

...It seems like we are running into some strange buggy behavior here...

All I can think of is:

[KeithOlson]

Joe, thanks for the advice. Our DBA recalculated the spatial index on one of our culprit feature classes as a test and it seems to have worked. Adding that fc to a map uses the normal (ugly pastel) default symbology again. We have several other fc's with this issue, so she will have to tackle each one, but it looks like this is the solution for now. Hopefully esri will have a permanent fix before the issue rears it's head again.  Thanks much!

[JoeBorgione]

@KeithOlson   Other options:

..such as renaming the feature class, removing a coded value domain, disabling attribute rules, or recalculating spatial index. After performing each change and undoing said change, the issue would not persist. 

The spatial index option seems to me as the least invasive.  Unfortunately I don't see a way automate calculating the spatial index.  There are tools (and subsequently a pythonic automation approach) for Adding indexes and Removing them, but not (re)calculating them... 

In my case we use attribute rules, and there is a python approach to Disabling them as wells (re) Enabling them that I may look into.

[KeithOlson]

Definitely good to have options. We will experiment with those and see which ones are quickest / take the least amount of valuable DBA effort.

[JoeBorgione]

@KeithOlson et al-

I just got off the phone with ESRI Tech support.  This problem is fixed at version 2.8 and above.  I'm seeing the problem at 2.7.4 but apparently it started at 2.7 and I just never noticed it.

There is a definite ying and yang tp updates.  As a python user I have been hesitant to upgrade to 2.8 as I've heard of python environment bug.  Apparently that problem exists at 2.8.1 and above; development is aware of it and it is supposed to be fixed at 2.9.  Ironically, if all goes well I'll be retired by the time 2.9 is released.  I'm not sure if I'll upgrade to 2.8.x; there are a number of work arounds for the python bug...