7

I am using a relationship class to maintain a one-to-many relationship between material sites (under Engineering's purview) and the material sites' sample status and content (under Materials' purview). I have privileged the tables such that Engineering personnel (user A) can edit the origin table and Materials personnel (user B) can edit the destination table. This works well, until user B needs to create a new record in the related table.

In order to create a new record in the related table, user B must have editing privileges to the origin table. This is the only way to access the Attributes dialog from the Editor toolbar, which appears to be the only method which programmatically ensures the GlobalID and ParentGUID fields match. Otherwise, you have to rely on the user to copy/paste.

Is there a workaround here? A way to split relationship class privileges between two different users while still maintaining referential integrity?

I use ArcGIS Desktop 10 (ArcInfo) SP3 with ArcSDE 10.

Improve this question
1
  • If this is something that you are still keen to try and get Answer-ed then you may want to edit it, perhaps to revise it with the versions you are using now, and maybe to try and make what you are asking even clearer.
    – PolyGeo ♦
    Apr 4, 2014 at 23:41

1 Answer 1

Reset to default
1

There is not any workaround as you ordered it to act like this (revoked origin table edit privileges from user B).

ESRI suggests to give privileges to both origin and destination tables/FCs of a relationship class.

Per Documentation

When privileges are granted to a feature class or table that participates in a relationship class, privileges must be granted to both the origin and destination class. If the origin and destination feature classes are within the same feature dataset, they have the same set of privileges since privileges are granted at the feature dataset level. However, when the origin or destination class are in not in the same feature dataset, you must ensure the proper privileges are granted to both the origin and destination classes. If the relationship class is either Attributed or has Many to Many cardinality, privileges are automatically propagated to the intermediate table when you assign privileges to the origin class.

So the only solution is to grant the privilege to user B

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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