See Datasets and Relationships without granting permissions?

[JerryGarcia]

Using SQL Server, I set-up a user and connected via ArcSDE.  The user can see all datasets and relationship classes, but no data.  I have not granted any permissions yet. 

Given I have not granted any permissions to database objects yet, why can the user see the datasets and relationships? 

Did I set something up wrong with the user? 

I do not want the user to see anything until I grant read access.

Any help would be very much appreciated!

[VinceAngelo]

Feature Datasets and Relationships are not RDBMS objects which can have access
defined (just rows in SDE-owned tables).  The actual tables ("feature classes") can
have GRANTs applied, so the contents of the meta-objects can be restricted to
specific users (if you look inside a FDS as an unprivileged user, it will be empty).

- V

[JerryGarcia]

Feature Datasets and Relationships are not RDBMS objects which can have access
defined (just rows in SDE-owned tables).  The actual tables ("feature classes") can
have GRANTs applied, so the contents of the meta-objects can be restricted to
specific users (if you look inside a FDS as an unprivileged user, it will be empty).

- V

Is there a way to hide feature datasets and relationships from users when they connect to the ArcSDE database?  This is a security issue whereby users should not know these feature datasets exist unless they have access to the feature dataset's objects.  There names give away too much information.  Thanks.

[VinceAngelo]

I don't think so. This has been discussed extensively in the past (search forums.esri.com).
It comes down to a design constraint -- If Desktop had to check for the existance of every
table referenced by any FDS before the initial "open" returned data, some sites would be
taking 30+ minute coffee breaks upon initial connect.

Your only options are to either forgo FDS membership (i.e., you're using it as a container,
not to edit related tables with shared topology) or to be less explicit in your FDS naming
scheme.

- V

[JerryGarcia]

I don't think so. This has been discussed extensively in the past (search forums.esri.com).
It comes down to a design constraint -- If Desktop had to check for the existance of every
table referenced by any FDS before the initial "open" returned data, some sites would be
taking 30+ minute coffee breaks upon initial connect.

Your only options are to either forgo FDS membership (i.e., you're using it as a container,
not to edit related tables with shared topology) or to be less explicit in your FDS naming
scheme.

- V

Thanks for your comments.  We could do away with FDS, but relationships would be hard.  Even if we rename the relationship classes to something non-descriptive, the error message when a user clicks on the relationship displays the name of the feature class which the user does not have access to.  We do not want folks to see this.  As a work-around, we could drop all GDB relationship classes, and have an ArcMap tool which builds these on-the-fly as ArcMap document relationships for the feature classes in the document?  Not optimal, but may work?

[VinceAngelo]

I'd suggest you file a bug on the information bleed for the relationship class.
A more generic message would be more appropriate.

- V