Appends When Geometry Storage Type Differs?

[RandyKreuziger]

When I upgraded from 10.0 to 10.1 the default geometry storage changed from SDEBinary to Geometry which initially I didn't notice.  So the original feature classes all use SDEBinary and everything added since the migration is stored using the Geometry (SQL spatial).  But now my exising workflow is broken. The Append command doesn't work if the target and source featureclasses use different geometries.  Why does this fail when I can do an Append between an feature class in a FGDB and an SDE database?

Executing: Append 'Database Connections\xxxxxxxxxxxxx\GeoWeb.DBO.Road_wm' "Database Connections\vSQL3 GeoWeb.sde\GeoWeb.DBO.Road" TEST # #
Start Time: Fri Jun 20 13:41:59 2014
ERROR 000466: Database Connections\xxxxxxxxxxxx\GeoWeb.DBO.Road_wm does not match the schema of target
Database Connections\vSQL3 GeoWeb.sde\GeoWeb.DBO.Road
Failed to execute (Append).
Failed at Fri Jun 20 13:41:59 2014 (Elapsed Time: 0.00 seconds)

Env: SQL 2012 / SDE 10.1 / Desktop 10.1

[VinceAngelo]

If you look at the tables themselves, the datatype of the geometry column *is* different.
File Geodatabase only has one geometry storage type, so that's not a fair comparison.

Are you using 10.1 SP1, with the QIP?  Provided there aren't other table differences,
I'd report this as a bug (though it wouldn't hurt to check it in 10.2.2 first).

- V

[RandyKreuziger]

I'm running into the same problem when going appending from Oracle to SQL Geometry.  This is killing me!  At 10.1 a bug deleting with spatial views and the SDEBinary storage type in SQL Server was introducted.  The workaround to that bug is to convert the storage type of the base feature classes from SDEBinary to Geometry.  OK spatial view issue fixed, except that results in the discovery of another bug dealing with the APPEND.

Now that the storage type has been converted to SQL Geometry the Append no longer works when going from Oracle GDB to SQL Server GDB.  A error is reported that the Schemas differ.  I can turn off the Schema Type test which works but I shouldn't have to do that because I do want to be alerted if there are legitimate schema changes like missing fields.   When I posted back in June I only knew that the problem occurs going between SDEBinary to Geometry within SQL Server.

(With every release of the ESRI software comes news bugs. I've spent 3 weeks implementing workarounds to the scripts and workflows that were broken with the 10.1 upgrade since upgrading.  And I'm not even finished.  I wish I had stayed at 10.0 ArcSDE!  rant over)