View by status   

Allow privledges to be set for feature classes within a feature dataset

  • 2200

  • In a multi-user SDE environment, some feature classes need to participate within a topology. However, we need the ability to deny edit privledges to selected feature classes within a feature dataset. An example:

    • Tax district boundaries are maintained by the Assessor's office.
    • Election precinct boundaries are maintained by the Elections office.
    • Both tax districts and precincts share topological relationships.
    • Elections staff don't want Assessor's staff fiddling with their boundaries accidentally.
    • Assessor's staff don't want Elections staff fiddling with parcels accidentally.
    Currently, the only option in SDE is to grant users from both offices full edit permissions to the entire feature dataset.
    We need the option to disallow edit privledges to individual feature classes within a feature dataset.
    Tags :
    Posted by   markuson  to Local GovernmentGeodatabase Mar 31, 2010

Share this idea Report Abuse

Comments (12)

Please log in to post a comment.

Jan 26, 2012
We have the same problem. We need to grant differnet permission within a feature dataset. This would be a great help to us.

Great idea!

Dec 27, 2010
I agree.  We have FeatureClass level data that participate in a geometric network therefore are all part of a single Feature Dataset.  Different groups are considered data owners for different FeatureClasses and we would like to be able to control editing privs as appropriate.  The goal is to prevent inadvertent editing of data they aren't responsible for without implementing workflows that need to be managed and maintained.

Has anyone confirmed that command line sdelayer -o grant permissions on a FeatureClass circumvent the Dataset level permission management as suggested below by JSkinn3?  Seems like if that works, why can't those permissions be granted via ArcCatalog? 

Aug 11, 2010
Agree.  Working for the military a few years back, we asked for this.  Our pitfall was data organization by data content (SDSFIE).  This breaks the potential (and likely) of shared topology requirements when there are two separate owners of data.  Let alone that being in the same dataset then dictates the same precision.

Overall, this would be a nice advancement.

May 3, 2010
We have over 600 layers used for reference of some kind. So we use datasets for organization like alot of users do.  I think there should be two different types of datasets, one would just be to organize data for easy browsing.  The second would be the traditional dataset as is, that is required for advanced geodatabase features like topology and geometric networks.

Apr 25, 2010

Yes , this will be very helpful

Apr 20, 2010
Agree completely.  Our GIS is setup so that all our County Departments manage their own data in our SDE database which is managed by myself (GIS Admin).  I have to adjust our feature datasets to allow for proper permissions among departments instead of structuring to fit with topologies and geometric networks.

Apr 16, 2010
As a workaround, you can use the 'sdelayer -o grant' command to accomplish this.  Ex:

GIS.Vector.Topology (feature dataset)
     -GIS.Vector.Boundaries (feature class)
     -GIS.Vector.Tax_Districts (feature class)

If I want to grant another user, ie 'Raster', to be able to just view & edit the 'Boundaries' feature class the command would be:

C:\> sdelayer -o grant -l boundaries,shape -U raster -A SELECT,INSERT,UPDATE,DELETE -i 5151 -D GIS -u vector -p vector

The Raster user will not be able to view or edit the 'Tax_Districts' feature class.

Apr 1, 2010
I agree with permissions at the feature class level, regardless of participation in a dataset or not.

As a workaround for now, couldn't you set up department specific GDBs and replicate pertinant info between departments. Then the editing would be constrained to that specific department. You could try user or role based access constraints within your DBMS but I'm not sure how SDE will like that.

Apr 1, 2010

I have run into similar problems inside one of our datasets. I would love to be able to add that extra layer of protection to feature classes. I have "fixed" more than once, an edit session gone wrong.

Apr 1, 2010
 yes, This is a good idea. My workaround is that I push a copy of the needed feature class out to another department after topology is run, creating redundant data. 

If they do this ArcCatalog would need a better way to 'track' privileges. 

Apr 1, 2010

Absolutely! We run into this in my office all the time in our case it has to do with Easements and Zoning boundaries.



Terms and Conditions   |    Feedback   |   FAQs
Previous MonthNext Month