Branch Versioning and Attributed Relationship Classes

275
4
Jump to solution
10-27-2021 11:27 AM
TimothyMorales
New Contributor II

I recently took an ESRI class on Branch Versioning that was focused on the process of preparing data for Branch Versioning. I am now configuring my test data and of course I hit a snag that was not covered in the ESRI class, attributed relationship classes. Do attributed relationship classes need to to be configured for Branch Versioning with editor tracking enabled?

0 Kudos
2 Solutions

Accepted Solutions
AnnieJames21
New Contributor

The following would be the best practice for registering many:many relationship classes:

1) Add GlobalIDs  to all participating data in no particular order, but likely: Origin Feature Class, Destination Feature Class, Attributed Table. 

2) Add Editor Tracking to all participating data in no particular order, but likely: Origin Feature Class, Destination Feature Class, Attributed Table.

In 2.9, you can use the Manage page from the r-click context menu in the Catalog pane to complete steps 1 and 2 in a single operation on the selected item.

3) Register the Origin Feature Class as Versioned (this will register the Attributed Table as versioned as well)

4) Register the Destination Feature Class as Versioned.

Again in 2.9, you can use the Manage page from the r-click context menu in the Catalog pane to complete steps 3 and 4 in a single operation on the selected item.

Let us know how it goes.

Annie

View solution in original post

0 Kudos
MelissaJarman
Esri Contributor

Timothy - 

Are you saying that you published the origin and destination table, but did not include the attributed relationship class in the map service and this caused problems when editing the service?

I did find this documented in the help, but I am not sure if there are analyzer warnings/errors for this type of situation.

Prepare data to publish a feature service

  • Feature services allow queries on related data, but only if the relationship is defined through a geodatabase relationship class. If a published map document has a layer and table related through a geodatabase relationship class, the feature service allows queries on the layer to return objects from the related table. To support queries that return related objects, you must include the table and layer involved in the relationship class in the published map document. If either the origin or destination layer or table is not included in the map document, the feature service ignores the relationship.
    Note:

    For attributed relationship classes, include the relationship class table in the map document.

View solution in original post

0 Kudos
4 Replies
AnnieJames21
New Contributor

The following would be the best practice for registering many:many relationship classes:

1) Add GlobalIDs  to all participating data in no particular order, but likely: Origin Feature Class, Destination Feature Class, Attributed Table. 

2) Add Editor Tracking to all participating data in no particular order, but likely: Origin Feature Class, Destination Feature Class, Attributed Table.

In 2.9, you can use the Manage page from the r-click context menu in the Catalog pane to complete steps 1 and 2 in a single operation on the selected item.

3) Register the Origin Feature Class as Versioned (this will register the Attributed Table as versioned as well)

4) Register the Destination Feature Class as Versioned.

Again in 2.9, you can use the Manage page from the r-click context menu in the Catalog pane to complete steps 3 and 4 in a single operation on the selected item.

Let us know how it goes.

Annie

View solution in original post

0 Kudos
TimothyMorales
New Contributor II

Well I finally have my test data set up to use branch versioning. I completed the steps you recommended with the attributed relationship classes only to find out the process initially didn't change the fact that the relationships still did not work.

The other key item to getting attributed relationship classes working in branch versioning is to make sure those relationship class tables are in the published feature layer that you intend to create named versions from. I could not find this information in any of the ESRI documentation that I read nor was the topic addressed during an all day training I received from ESRI on Branch Versioning.

Capture.PNG

0 Kudos
MelissaJarman
Esri Contributor

Timothy - 

Are you saying that you published the origin and destination table, but did not include the attributed relationship class in the map service and this caused problems when editing the service?

I did find this documented in the help, but I am not sure if there are analyzer warnings/errors for this type of situation.

Prepare data to publish a feature service

  • Feature services allow queries on related data, but only if the relationship is defined through a geodatabase relationship class. If a published map document has a layer and table related through a geodatabase relationship class, the feature service allows queries on the layer to return objects from the related table. To support queries that return related objects, you must include the table and layer involved in the relationship class in the published map document. If either the origin or destination layer or table is not included in the map document, the feature service ignores the relationship.
    Note:

    For attributed relationship classes, include the relationship class table in the map document.

View solution in original post

0 Kudos
TimothyMorales
New Contributor II

Mrs Jarman / Melissa -

My initial attempt at creating branch versioned data did not have any failures when editing feature geometry or rows from standalone tables rows that utilized relationship class tables. The biggest issue I had was not finding out that relationships utilizing attributed relationship classes required that those tables also be published with the origin and foreign tables/feature classes. I will admit that I am a skimmer when it comes to reading lengthy technical documents and I would have saved some time if I had read thru the documentation thoroughly. However I strongly feel that this case should be included in the current training because of how common the use of attributed relationship classes are present in many GIS spatial data environments/systems. Also it would be helpful to add a warning during publishing that points out relationship class tables may be missing (unless I missed those warnings because of skimming) . I do have my test data up and running and it is working fine. 

Thank you for responding,

Skimmer