Thanks for jumping in the thread, Vince...
"There have been bugs in the past..." - how far in the past? We're at 10.1 on both the desktop and ArcSDE and that was my first thought (adding projected data to the GCS SDE feature class), but I haven't been able to reproduce it... I've asked the GIS editors to explain their workflow but unless you see them do it, most are hard pressed to recall what they did (typically they are natural resource specialists, etc. and GIS is not a primary function of their jobs).
Also, do you know if ArcCatalog 10.3 will support updating the envelope in T_n_DIRTYAREAS? I've had to fix this with SDELAYER a few times and I understand 10.3 will not include SDE command line tools.
I don't know how far into the past. It may have been a "feature" fixed in a late 10.0 SP,
but due to release overlap, may have been present at 10.1 (Final). I can't imagine
it wasn't fixed by 10.1 SP1 (and there's been several years to get SP1 applied).
Reproducing this kind of compound error bug is usually very difficult, but if you do find
a use case, please let Tech Support know.
Without 'sdelayer -o alter' at 10.3, the fallback would be SQL, though there might be
a tool which is less risky.
We started seeing problems with strange extents only after upgrading to ArcSDE 10.1 SP1. I did the upgrade at the same time SQL Server was upgraded from 2008 to 2012 but it's probably the SDE upgrade that did it. I've encountered more serious bugs in ArcSDE 10.1 then previous versions.
We are still seeing this problem at 10.2.2. Don't know why the feature extent changes to absolutely unreal values when the editors never zoom out beyond Washington state. Performance when digitizing with snapping on goes from very slow to unusable! In the past recalculating the feature extent, then recalculating the spatial indexes fixed the problem but not this time.
We have several feature classes in a single feature database with topology set. I'm opening a ticket with ESRI but if anyone knows of a solution for this or even ideas I'd love to hear them.
Has anyone come up with a solution to this? I´m having the same problem but so far with only one featureclass (sdelayer) in one of our datasets and we are using arcgis 10.3.
I have to recalculate the extent every few weeks, but then again it´s the featureclass we edit the most. But I would like a more permanent fix than to recalculate it everytime it gets messed up, because it can go a long time before I notice it has inconsistent extent. Tried exporting it to a shape to see if there´s something wrong with the layer but the shapes extent was fine. In my case only "max Y" remains the same.
In the printscreen the above values are after it gets all messed up and after recalculation it gets the right values (shown below). I tried searching for the problem, but the only thing I found was Error: Warning, inconsistent extent! and other unanswered topics. But that doesn´t help me at all. And I don´t think the problem is the coordinate system we are using or that it´s defined wrong since I created it from scratch like most of our other featureclasses that do work.
I still have not found a consistent way to reproduce the problem, but in our case it usually looks like UTM values for our area instead of the decimal degrees that we have as the defined coordinate system - perhaps some problem with users editing the GCS data when their data frame is in UTM.
I'm considering rebuilding the data with a new spatial spatial domain/resolution/tolerance instead of the default values but not sure when I could do that as these are heavily edited feature classes.
For now I have a ArcPy script that runs nightly to loop through all data owner accounts and describe the feature classes. If the extents are outside of a certain geographic area, I put that feature class in a list that I email to myself and the other SDE Administrator for correction when we arrive in the morning.