Do you have access either to ArcGIS Server or ArcGIS Online? If your need is to hide some attributes/fields, but show geometry, it can be accomplished using web-based tools. Otherwise, as noted by others, you invite complex and unsupported database behaviors and/or Desktop customization with ArcObjects.
I wrote that you can't use ArcGIS tools to accomplish this.
If the database supports this functionality, then a forum of the database in use would be a better place to get help. You may need a great deal of geodatabase knowledge to avoid breaking ArcGIS functionality.
If it is not supported by Esri, what then would be the usual procedure(steps) to follow to get this done? I mean to forbid the access for an SQL Server 2008 R2 Database user, to an attribute field table, which could contain sensitive information?Thank you.
ArcSDE permissions aren't that granular, and database extensions that permit row/column levelsecurity are not supported by Esri (if you can make it work, congrats, but Tech Support can't helpyou if it doesn't work). You'd need to pay careful attention to the extra tables created by ArcSDEfor versioning, archiving, etc, since you couldn't use ArcGIS to grant the permissions. Addingrelationship classes, domains, etc into the equation increases the level of difficulty by an order ofmagnitude. I certainly wouldn't want to attempt this, and I've been working with ArcSDE sinceversion 1.3 and SQL-Server since 6.0.Using multiple tables and views to join them is a less fearsome approach, but it's unlikely you'llfind someone to donate days/weeks of time to give you detailed instructions on how to proceed.The best you can hope for is someone having published a paper on how they did somethingsimilar, then using that as a roadmap.- V
How do you define "code-level access"? I've never seen that term before.
What RDBMS are you using? ArcSDE doesn't have anything to do with security models -- Those are provided by the RDBMS.
I don't think that SDE permissions are that granular, perhaps you will need to split those private attributes into a separate table and use a primary/foreign key relationship. Then you can use a spatial join that combines the private attributes with the feature class and only grant access to private (internal) users. If the spatial view does not handle the one to many relationship well, you can add an extra step where you export the spatial view to a feature class and automate that process.
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.