Skip to main content
All,

 

 

I just flpped open the back-end of SDE 10.1 through SQL server and to my surprise the geometry of the SDE feature classes was being read as if it were native SQL spatial data...

 

 

Is this a supported feature?

 

 

Thanks!

 

 

-m
ArcSDE has used the native ST_GEOMETRY as the default storage form ArcGIS 10.0 - So if you know where to look you can read it directly. It's just like a regular SQL-server spatial tabel.

 

 

Be aware!!! If you use ArcGIS' versioning you need to use the versioned view (from version 10.1 it's <tablename>_vw i think)

 

 

/Tim
Thanks, Tim!

 

 

This is intriguing, but due to the large amount of extra tables ArcSDE writes to my SQL database, and the versioning issue you mentioned, I'm still hesitant to point anyone to this database and call it our SQL spatial production environment!

 

 

-m
Just to confirm - If you are using version 10 and above of ArcGIS/ArcSDE with SQL Server, then the default geometry storage type is GEOMETRY, which is the SQL Server native storage format. Hence you can view/query the geometry within SQL Server. The default is not ST_GEOMETRY as this is an OGC format specification, though I believe it is similar and some OGC functions may be implemented by SQL Server. 

 

 

The warning about versioning is true. If you are using versioned data, then you need to take extra care. At 10.1 and above multi-versioned views are created automatically when you version a feature class, but prior to that you need to create them manually. You can then use the multi-versioned view to view/query and optionally edit the data outside ArcGIS. See the following and related articles for more info: 

 

 

http://resources.arcgis.com/en/help/main/10.1/index.html#//006z0000000q000000

 

 

The extra tables SDE creates are it's metadata that are used by the ArcGIS applications and it's "Geodatabase" implementation. These are used primarily to implement advanced geodatabase functionality like versioning, relationships, feature datasets, geometric networks, topology etc. If you are purely querying stand-alone feature classes from SQL, then you don't need to worry about the SDE metadata. 

 

 

 


Reply