"Project On the fly" editing with SDE in ArcMap 10

[LucasCulbertson]

Before everyone scolds me, I know it is frowned upon to edit data outside of its native projection.  However, I'm noticing some serious issues in how Arcmap 10 handles this operation when working with an SDE-versioned geodatabase.  My data is in WGS84, but I do some of my edits in state plane for calculating distances.  I try to stop my editing session and switch my data frame back to WGS84 before I do any geometry edits, but it doesn't always happen.  I can move one single node and my maximum extents will change from decimal degrees (i.e., 180, 90) to feet (i.e., 696000, 700000).  I've even recognized the screw up before I save my edits, but to no avail, my layer extent is trashed.  This obviously poses a problem and multiple "inconsistent extent" messages pop up when trying to load the data into the map.  With this being said, I have two main concerns:

1) Why does it appear that 10 has such difficulty editing data outside of its native projection
2) Why does the extent change across the board rather than just my version.  Extent is not a schema change, so I don't understand why this was set up in this manner.

Thanks for any input!

[JustinJohnson2]

I have had this problem a number of times in ArcGIS 10.  I know it wasn't an issue in 9.x

It seems to happen when I edit point data stored in a versioned SDE Feature Class in the NAD 83 coordinate system inside a map document that uses a UTM coordinate system.  I have been doing this for years, but since we migrated to ArcGIS 10, the GIS users in my group occasionally encounter a problem when an existing point is moved using the Edit Tool. 

When we move a point, it will disappear when the map redraws.  If someone saves the dataset without immediately undoing that move, the extent of that dataset becomes corrupted.  The moved point(s) appear to be stored in UTM values inside the NAD 83 decimal degree dataset, so there will be a latitude value of something like 4500000 and a display scale for the entire layer of some outrageous value like 1:2,740,267,736 

When we bring that dataset into a new map, we get the error: "Warning, inconsistent extent!"

Deleting the misplaced points doesn't fix the corrupted extent.  The only workaround we have found so far is to select all of the points that are in their proper location, export them to a new SDE Feature Class, then delete the old feature class.  This results in a lot of lost work and time.  This was never an issue prior to version 10.  We haven't changed our workflow in any other way.  It seems to happen now on a biweekly basis.

[VinceAngelo]

This seems to be a rather significant bug.  Please contact Tech Support so that it can
be fixed as soon as possible.

A version is only a name for a state in the state tree.  There is no envelope property
on states, but there is on layers, and ArcGIS updates the layer envelope after each
edit session.  Even if you delete the offending shape, the delete operation does not
shrink the layer envelope (to do so is not nearly as simple as expanding it).  You can
however reset the layer envelope with:

sdelayer -o alter -l table,geomcol -E -180,-90,180,90 -s server -i port -u owner -p pass

- V

[Marketa_Pancova]

Has this problem ever been logged as a bug? Have you got any further information?

[SeanGrant]

Sounds like you are running into this bug NIM063577: http://resources.arcgis.com/content/nimbus-bug?bugID=TklNMDYzNTc3

-Sean

[MarkSmith1]

I just want to jump in here - we've encountered this bug 4 times now in a 4 week span. This is EXTREMEMLY frustrating as it corrupts the featureclass and we've been forced to delete it and recreate it (along with any relationship classes associated with it, which in some cases are numerous).
The problem occurs when we're editing data in SDE (SQL Server 2008, ArcGIS Server 10) that is in a Geographic Coordinate System NAD83 CSRS. The data frame is often in a local UTM zone with the same datum. Operation that cause this error include: Append, copy and pasting features, and digitizing new features.

ESRI - please step up with a patch for this.

Vince - thanks for posting the sdelayer alter fix. there was still a corrupt feature in the featureclass (no geometry) but at least we were able to edit the FC and delete the offending feature. Has this been logged as a bug?

Sean - The bug you've posted doesn't really describe what is happening to us.

Mark

[VinceAngelo]

I submit bugs on reproducble things that I encounter, but I can't submit if I
can't give a detailed breakdown of how to reproduce the issue.

- V

[MarkSmith1]

Thanks for the reply Vince. So as far as you know this hasn't been logged as a bug?

Lucus - did you call Tech Support about this issue? If not then I will.

Thanks

[VinceAngelo]

I have more access to the defect tracking system than non-employees, but not as
much as the support analysts.

I realize it's a pain to put together a bug report, but *everyone* who's experiencing
a particular "feature" really ought to file bug reports. 

There are several benefits to this:
1) Sometimes they look like the same behavior, but aren't; you don't want the other
fix to not fix your problem,
2) Even if it is the same problem, it's easier to fix something if you have more than one
real-world case with which to test,
3) In the realm of limited budgets, the squeaky mouse gets the cheese; hotfixes are
generated based on a triage of impact -- less severe problems are more likely to be
rated critical if more sites are associated with the NIMBUS record.

- V