SHAPE.STArea()field in SQL 2008

[JustinConklin]

I recently migrated my SDE geodatabase from SQL 2005 to SQL 2008.  The SHAPE.area and SHAPE.len fields automatically changed to SHAPE.STArea() and SHAPE.STLencth().  I believe this is because of the new geometry data types available in SQL 2008 and later.  A simple change in the field names doesn't really present a problem until I export feature classes to a file geodatabase.

When feature classes are exported the SHAPE.STArea() and Length fields are retained, and additional Shape_Area and Shape_Length fields are created.  Now there are redundant area and length fields and none can be deleted.  Also, the area fields are different by as much as several square feet in some cases. 

How can I avoid or work around these additional fields.  I replicate the entire SDE database as a file geodatabase, so one by one featureclass manipulation isn't ideal. 

Thanks,

Justin

[RichardFairhurst]

I recently migrated my SDE geodatabase from SQL 2005 to SQL 2008.  The SHAPE.area and SHAPE.len fields automatically changed to SHAPE.STArea() and SHAPE.STLencth().  I believe this is because of the new geometry data types available in SQL 2008 and later.  A simple change in the field names doesn't really present a problem until I export feature classes to a file geodatabase.

When feature classes are exported the SHAPE.STArea() and Length fields are retained, and additional Shape_Area and Shape_Length fields are created.  Now there are redundant area and length fields and none can be deleted.  Also, the area fields are different by as much as several square feet in some cases. 

How can I avoid or work around these additional fields.  I replicate the entire SDE database as a file geodatabase, so one by one featureclass manipulation isn't ideal. 

Thanks,

Justin

The Feature Class to Feature Class tool can alter the field map to exclude the SDE fields and they will regenerate with the new names in the gdb anyway.  The Make Feature Layer tool can make those fields invisible too as an input to other tools.  Not sure about the area changes, although the first place to check is for any differences in the Spatial Reference, tolerance or resolution settings.

Standard replication may not allow these options.  At 10.2 I can delete those fields from copies, but I am not using actual replication which has its own set of schema restrictions.  I've never really experimented with replication.

[RandyKreuziger]

Justin,

  Have you reported that as a bug?  I'm running ArcGIS 10.1, SP1 and just ran into this problem when doing an export.  These two extra fields that are created cause problems further down in our work flow!

Shape_STArea__

Shape_STLength__

Shape_Length

Shape_Area

[VuDang2]

This is a bug and has not been fixed as of version 10.3.1

[RandyKreuziger]

I contacted ESRI nearly 2 years ago and asked that they escalate this "known bug" but the team that reviews the escalation requests said it wasn't a very low priority.  What makes it worse for us is that we were told to move from SDE Binary to SQL Server native Geometry as a workaround to another ESRI bug that had no fix!

[RayMontgomery]

At 10.3.1, with data stored in SQL Server 2008R2, WITH data stored as Geometry type, this happens even when simply copying a FC to another FC in the same Feature Dateset.  I did use Data>Export, so maybe it has to do with the export function.

That newly-copied FC has 3 versions of these key fields: "Shape_STArea__", "Shape_STArea_1", Shape.STArea(); as well as "Shape_STLength__", "Shape_STLength_1", and the popular "Shape.STLength()". Randomly checking, it looks like the values are the same, however, unlike Justin's.

In Catalog, I was able to delete the pair ending with the double underscore, but not the others.

[BrianO_keefe]

Is there a solution to this? I'm trying to implement ArcGIS Addressing Assistant and the MXD is broken with these field names.. SHAPE.STArea() instead of SHAPE_Area

It's extremely frustrating.

[PatriciaMoehring]

Unlike everyone else, I just went in to the template and fixed the queries, etc. to read the Shape_ST layer.  However, after reading some of the solutions, I have my sde export nightly to a fgdb.  All readers actually access this db and not the main sde.  The fgdb maintains the SHAPE_Length and SHAPE_Area fields.  I didn't realize this when I was suffering through the template!

[BrianO_keefe]

I've modified the 9K layers, all of them, to adjust their Definition Queries and their Label Expressions and Label SQL Expressions... but... the Facility Sites has NO queries and the labels don't reference the SHAPE.STArea yet that field is still throwing a drawing error.

Frustrating.

[PatriciaMoehring]

Yeah, I'm trying to remember about the Facility Site -- because there are points and polygons.  I believe what I remember the most about them was FCODE field. Make sure you aren't looking at the Points!  I know that seems silly but I just remember it was difficult. 

I set up the ParcelPublicAccess for a basemap which is all pointed to the fgdb and OMG, I'm just saying!  Until I actually figured out what the hello was going on . . . let me just say, I have a whole lot less hair and quite a few bruises from head banging.  Once I figured out what layer they were referencing that I may have named differently in my SDE, then I was able to just bring my SDE feature in and work from there.

The road centerlines is what really got me!  I had to add fields to mine!

You might want to open the template that is looking at ESRI's local government fgdb.  Save the symbology as a layer file.  Then delete that layer from your map and save it.  Then try to bring in your layer from your SDE and use the saved symbology.  You may have already tried it but if you did, once you remove the layer and save the map, try deleting your default.mxd (don't forget to just rename it) then reopening the template you are working in.  If that doesn't work, let me know, I have a whole bunch of other things you can try!:)