Alternatives to using SDE command line tools - Blog Discussion

[ChetDobbins]

With the release of 10.2 and plans to deprecate the ArcSDE command line tools, you may be wondering how current tasks that use these tools can be completed elsewhere. This blog provides some workflows that have alternate user interface tools in ArcCatalog/ArcMap that will make transitioning as seamless as possible.

http://blogs.esri.com/esri/supportcenter/2013/10/04/do-this-not-that-alternatives-to-using-sde-comma...

We are very interested in hearing feedback from everyone who uses the ArcSDE commands, including questions, concerns, and ideas for making this successful. You can also contact Esri Support Services for specific ArcSDE commands that do not have comparable replacements.

This document outlines the planned changes in platform and functionality in the ArcGIS 10.2 release and
includes a reference to ArcGIS 10.1 deprecation notes.
http://downloads2.esri.com/support/TechArticles/W26496_W25918_DEPRECATION_PLAN_FOR_ARCGIS_101_and_10...

[AprilWilliford]

I submitted an idea to continue support for registering Oracle Spatial layers without adding the SE_ANNO_CAD_DATA field to the underlying table. Please promote this idea if you would also like to see this option supported :

https://c.na9.visual.force.com/apex/ideaView?id=087E0000000kAgxIAE

[MelissaJarman]

Thanks April for reporting back here after your support case. The following enhancement was logged for you and we also suggested using the ArcGIS Ideas site to see how many others are interested in this functionality/behavior when registering spatial tables with the geodatabase.

ENH-000092182 - Provide an option using ArcGIS Geoprocessing Tools to exclude the SE_ANNO_CAD_DATA column when registering an Oracle SDO_Geometry spatial table directly with the geodatabase.

The ArcGIS Idea is a good idea to go along with the internal enhancement for this functionality that we logged.

Continue support for registering an Oracle Spatial layer with the geodatabase without adding the SE_ANNO_CAD_DATA field to the underlying table. - See more at: http://ideas.arcgis.com/ideaView?id=087E0000000kAgxIAE#sthash.7dEzAbsu.dpuf

[AndrewWilson99]

Melissa Jarman: Thanks for the direct URL. 

[NateArnold]

I'll add to this thread that in May of 2013, I submitted an incident which got tagged onto NIM085579, which is currently listed as Open and Assigned.  This bug was created TWO YEARS AGO and it has still not been fixed.  The analysts found that yes, a view created with CreateDatabaseView_management against a feature class using geometry storage (which is the default now) in SQL Server 2012 is indeed slower than command line spatial views against feature classes using sdebinary storage.  The analyst I was working with at the time said (c/p from an email):

     So the slower drawing time seen in the view created with SQL is expected.  Please let me know if you have any questions about this.

Please, ESRI, don't be surprised when users like Joshua Bixby‌, me, and everyone else in this thread get frustrated on the subject of spatial views, when "it's slower now by design" is the type of response we get from Tech Support.  Add to that command line tools going away, and what are we to do??? 

Please, please, please share the suggested workflow for making spatial views at 10.2+.  And don't say saving a .lyr file is part of the solution.

[JeffPace]

Agreed.  We need a "purely with SQL" workflow

[JohnBaleja]

I've been following this thread and first I want to make clear that all of the ArcSDE command line tools are available up through the ArcGIS 10.2.2 release. We have done a lot of work at 10.3 to fill gaps, but spatial views is an area where we still have work to do. I will post back to this thread as I have more information regarding our plans regarding spatial views. John

[JeffPace]

Thanks for this update.

Spatial views are a biggest use, and the biggest need.  We cant use sql straight up (we get an error about abstract data types from oracle).  So we have to create a spatial view with the commandline tools and then modify the view in sql.  That frequently includes inner and outer joins, data accessed via database links, etc.   Things that are absolutely essential to day to day function

[VinceAngelo]

Jeff, this workflow isn't anything I've ever seen to be required.  Have you configured the ST_GEOMETRY support library through hs/admin?  I've never had an ADT error with respect to CREATE VIEW.  I expect it's the database link that's the source of the errors (and they're very difficult to work with). Editing the view after registration can create column registry issues.

[DavidColey]

I totally agree with Jeff.  We have always created our spatial views in CommandLine and then modified them as necessary in SSMS since 2006, and since moving to SqlGeometry in 2010.  We have never gotten consistent results using Vinces' method becasue of the behavior diffculties with SQL Geometry Shape column. So, I would say that I don't agree with his 'rarely_used' assessment.

[VinceAngelo]

David, each storage type has a different best practice.  SDEBINARY views had to be created with 'sdetable -o create_view'.  What behavior difficulties are you seeing with SQL-Server Geometry (and with which version of SQL-Server  and ArcGIS)?