Registered Feature Class

3974
2
01-07-2015 12:58 PM
by Anonymous User
Not applicable

All,

I am trying to better understand which DDL actions are possible to execute using a SQL Server DBA Account against feature classes registered with the geodabase in ArcGIS 10.2.  This DBA Account is not the schema owner or the assigned SDE account.  In our company, all DDL statements are supposed to be executed by the DBA group via sql scripts created specifically for deployment purposes.  We are not allowed to use ArcMap or any other ArcGIS tools.  The problem is that we have tried to execute alter statements before using TSQL instead of ArcPy/Python and we have seen weird issues with SDE not understanding the change.  Somehow the internal SDE catalog gets out of sync and it either things the field has not been modified or it thinks the feature class still exists even thought it was deleted using a 'DROP' statement.  Any ideas on how to manage changes and maintaining a geodatabase in a company with strict separation of duties policies?  Appreciate your feedback.

0 Kudos
2 Replies
RandyKreuziger
Occasional Contributor III

Sandra, did you ever hear back on your question? 

In our agency it's require that all database manipulation be done through TSQL scripts with strict separation of duties.  Because of this our enterprise geodatabases are kept on another SQL Server instance.  I've explained that industry "best practices" can't always be applied or strictly applied geodatabases.  The first, that you cannot create a SDE geodatabase from scratch using only TSQL.  The response from above was, "ESRI doesn't know what they are doing and we should find another GIS system to replace it."  Really, and I hear it at least once a month.

As the SDE administrator I do let a few users own their own SDE database on theseparate SQL Server instance I manage.  It's only for SDE/SQL databases.  Another thing that the rest of the IT Data shop doesn't understand is that ArcGIS is the "Application." The GIS analyst is not developing software, therefore they don't need the traditional separated dev, test, and production databases. Maybe the user needs to do a one time analysis and needs the power and scalability of SQL Server.  The analyst isn't necessary going to know ahead of time the schemas for the final tables let alone all the intermediate tables.  Therefore, the requirement that create all the empty table schemas in advance doesn't work.  That doesn't mean that SDE/SQL databases can't be allowed in the enterprise.

I'd also like to hear from others on this too.

NeilAyres
MVP Alum

"ESRI doesn't know what they are doing and we should find another GIS system to replace it."  Really, and I hear it at least once a month.

Really, wow.

It is very unwise to mess with the backend of a geodatabase. There is so much going on in there and its managed by sde (or whatever they call it these days).

0 Kudos