ArcSDE Databases Have Extent Randomly Change

[EthanHunt1]

Hello,

I've been having a problem with the extents of feature classes in our SDE here at work.  Our database is divided into feature datasets that have various feature classes in them.  The problem is as follows:  The feature classes are all in GCS NAD 27.  Sometimes, when editing data (digitizing features and filling in the fields), at some point, the extent of the feature class will change.  The data source is still set correctly, and while the top and right extent are still correct, the bottom and left extent get changed to -400.00 dd.  It's always the bottom and left extent that get changed as well.

I can't think of anything in particular that I'm doing to cause this.  There are a couple of us editing the SDE at the same time, but we are always working in different feature classes. 

It's possible to fix the extent by resetting the data source from a feature class that still has the correct extent, but I'd like to know why this is happening so that we can fix it permanently.

Thanks,

Ethan

[RandyKreuziger]

This issue is killing us when the data is being edited and snapping is on even though the user is zoomed way in!  Our users are asking if they can move their data editing from SQL Server to a File Geodatabase but that may be the only option since ESRI tech support couldn't help us with the randomly changing feature extents.

[BarbaraS]

We still have this issue, and reading this thread, it seems like we imported the error from copying data from old sde's. We never had an issue before, until we created a new sde on a new server in 2018. Features are shown in the default coordinate system of the database (ED50), but as soon as we use a projected coordinate system, some features (not all) disappear! The remaining features have in common, that they stem from the same project, so they most likely were added to the sde at the same time.

See screenshots of what is happening here:

Feature extent:

After using a projected coordinate system in the data frame:

We only manage to fix this error by taking a backup of the feature class, rebuilding the spatial index, removing the faulty features and copying them to the database again.

I think we have the same workflow as @Steve Salas, since we usually work in a projected coordinate system and then load the data into our sde, which has a geographic coordinate system. Something gets messed up here in this process... Just today we had the case of a user loosing features in a map with projected coordinate system, she then copied the missing features in but that caused ALL other features to go corrupt and disappear!

Is there any way to restrict the feature extent of our feature datasets or feature classes? Also, what would be the ideal workflow for our data? Creating features in a projected coordinate system in a gdb and then adding the data to the sde? What is the safest and best way to do it (since there are so many and we use all of them actually: tool Append, copy paste in an edit session and Load from the right click menu on the sde)?