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...

[DavidColey]

Hi Vince-

We are at the latest 10.2.2 patch release, with SQL Server 2008.  To be honest, I don't really know other than we always had difficulties registering our spatial views if we created them in the RDBMS first, as the operation would throw an error, either in command line or in the GUI. 

I suspected that the system tables weren't handling the Shape column and so we always relied on create_view (hence my disagreement with 'rarely used').  I understand that each storage type has a best practice, but haven't read any documentation stating that when using SQL Geometry views should be constructed via the RDBMS.  We'll be performing some more testing and I'll get back to this thread asap.

[VinceAngelo]

Are  you using 2008R2?  2008 was flighty, at best, and I don't think it's supported with ArcGIS 10.2.  I do recommend reviewing procedures, and moving to a more current RDBMS.

[DavidColey]

Vince -

Yes thanks rest assured we review proceedures with each release.  Yes, we are at 2008R2 and want to move to 2012 but are trepidicious about geometry performance.  My post SQL Server 2012 and 2008: Geometry Performance | GeoNet asks whether anyone has experienced increased or decreased geometry performance at 2012 but it has recieved no replies since June of this year.  As an SDE admin, I dislike using spatial views but must for certain datasets.  Performance is always an issue, and they are clunky to serve. 

[DavidColey]

Hi Vince et al:

I am pleased to report that at SQL Server 2012 we have experienced no issues with spatial view creation and management via SSMS.  In this instance, we re-created a standard parcel left outer join with property records. 

Draw performance between 2012 and 2008r2 is about the same.  We were hoping for greater performance, but at least we did not experience a degradation. 

No issues with the SQL Geometry's Shape column.  No issues serving the views or consuming in a Mobile application (read-only) as we include the GlobalIDs from the left hand side.

[JeffPace]

Great to hear david.

Looks like spatial views are working for us (with joins) in Oracle as well. 

[DavidColey]

Good to hear as well, Jeff.  Also typo on the GlobalIDs inclusion for Mobile, I meant GlobalIDs from the right-hand participating in a 1:M relate.  For 1:1 I don't think it matters.  It would be interesting to determine best-practice for an N:M - i.e. which globals to include?

[JeffPace]

We use oracle 11gr2 (11.2.0.3) .  ST_GEOMETRY type, correctly configured.  Abstract data type error everytime at version 10.

I just tested this since we took the database to 10.2.2  and it seems to work. 

In response to "Editing the view after registration can create column registry issues."  This is something SDE NEEDS to handle. 

[VinceAngelo]

How could ArcGIS know that schema changes have occurred without notification?  Doing a complete inventory on all tables to see if changes have been made before each query is made would cripple performance, even in a small database.  The only way the SDE.* tables can know that changes have occurred is to tell them (SE_table_describe the table as the owner).  The performance benefits of registration are significant, but they are based on a contract that extra-geodatabase changes are limited, or require notification.

[JeffPace]

If i change the schema i am happy to be able to tell SDE the an update needs to occur.  I am not saying SDE needs to do it automatically, I am saying there needs to be a workflow.  Basically throw the "schema out of date" error, drag layer into arcmap as data owner to update schema, etc.. Is what we do now.

It would be nice to be able to run a "update schema to registry" tool or a validate all schemas type tool.

[VinceAngelo]

I agree that those tools would be nice, but fear for the privileges that would be necessary to run them -- both the scanner and updater user would need SELECT ANY TABLE access, and the updater would need to be run as SDE or a DBA with UPDATE ANY TABLE.