4

I have a SDE geodatabase in MS SQL Server, where geometries are stored in MS SQL's native geometry types, rather than the ArcSDE Binary.

It seems like it would be relatively easy to create new features in C#, without the use of ArcObjects. I could use one of my favorite Micro-ORMS (Dapper or PetaPoco) in conjunction with the Microsoft.SqlServer.Types namespace and load features directly into the database without ArcObjects.

I am a novice ArcSDE user, but am quite aware of the rat's nest of stored procedures and other db logic that comes along with ArcSDE, so I am sure its not as easy as I am thinking. I am sure I am not the first person who ever thought about this - so the lack of success stories in this area discourage me a bit.

Has anyone ever done this? Are than any compelling reasons why I shouldn't do this?

Improve this question
3

I have done this with my Locations project; where I am building point data; then using C# and normal MSSQL T-SQL StoredProcs to insert the data into a SQL table using Microsoft Geometries. This is actually a very nice and smooth process; and the lack of ESRI overhead in the process makes it easy to optimize processes directly.

No real reasons for you not to do it; as long as the database is properly registered with ArcSDE tables and you have defined to use your feature classes as either the Geography or Geometry type versus SDEBinary you will do fine.

Improve this answer
  • 1
    +1 Any thoughts on how to do this with Oracle? – Kirk Kuykendall Nov 3 '12 at 3:06
  • 1
    Yes, there is much the same way you can do with MSSQL; in the past I used Autodesk to get my spatial data into Oracle but there is a wide variety of info available from Oracle for spatial. All you need to do is some back research on the SQL. Some quick Google-Fu brings up a bevy of info using Oracle Spatial SQL as your search terms. – D.E.Wright Nov 3 '12 at 17:04
2

As D.E. Wright says, no reason not too. A few years ago I did something similar. We had data in a non-spatial SQL Server (2008?) database that needed to be brought into SDE (SQL Server 2008) as polylines.

I created a SQL Server geometry type featureclass and from a C# standalone application, would call a series of stored procedures within SDE that would pull the data from the non-spatial database every 15 minutes and push updates to the featureclass in SDE. Worked like a charm and was super fast.

Another advantage to this is that you are essentially bypassing the SDE stack, allowing you to do near-realtime updates. Once that data is pushed to the featureclass, a refresh of any open applications and the user sees that new data you just pushed.

I wrote an introductory-level article on this topic for ArcUser earlier this year.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.