QueryTask.ExecuteRelationshipQueryAsync - editing the related records

BrooksShannon

I have a (hopefully) easy question about feature relationships, and editing records that participate in a relationship with a feature class.

I notice that the QueryTask exposes an ExecuteRelationshipQueryAsync method. This apparently lets you access records related to a given feature (or set of features).  I'm thinking of using this to access records that exist in a simple 1:M relationship: one point feature related to 0 or more records in a Table (not a feature class, specifically).

It seems that the QueryTask.ExecuteRelationshipQueryAsync() method would be the ticket to accessing the related records.  That would get me half-way to where I need to be. What I'd really like to do is make edits to those related records - the full suite of CRUD operations. 

I don't need to use the FeatureDataForm / Grid / etc to pull this off, necessarily - it's quite likely that I'll roll my own custom UI to do this.  That would give me the ability to do some legwork under the hood to commit the edits, if I had to.  Since the result of the ExecuteRelationshipQueryAsync operation, at the end of the day, is a RelationshipResult instance, I can get at the related records (as Graphics), and could easily make changes to their attributes.

It's the next step that I can't quite figure out.  Once I've made my changes, I have to be able to save my edits. In addition, I'll have to be able to add and remove related records.  To do that, I suppose that I'll need a feature layer; one that represents the table containing my related records.  I can put that together, of course, without much trouble.

The question then, is this: will my edits be committed if I, say, change the attributes of a Graphic in the RelationshipResult.RelatedRecordsGroup and then call SaveEdits() on the feature layer that represents the related table?  Or do I need to do something like inspect the Graphics in the RelationshipResult.RelatedRecordsGroup, and then go retrieve them again from my feature layer, and modify those instances' attributes, in order for SaveEdits() to work?

Perhaps what I'm trying to accomplish isn't possible.  If that's the case, I have some alternate workarounds that I can explore.  It would be cool, though, if I could use the existing API to accomplish this task.

Thanks!
Brooks

Jitendrudulacaraju

Can you share a sample code on this?

Casey,

That does sound like an effective approach.  As long as the user has a way of providing the data required to create a new record, you'd be set.

My app displays the related records in a DataGrid, and if users want to create new related records, they simply click an "Add" button.  Then, the fun starts:

1)  I create a new Graphic instance.
2)  I manually set one of its attribute values, the foreign key, to the primary key of the record it's related to. (This is how you wire up the relationship back to the record that exists on the "left hand side" of your 1:M relationship.)
3)  I add the graphic instance to my "related records" FeatureLayer. Voila!  You can start adding and modifying the graphic's attributes just like preexisting records.

As the user supplies attribute values for the new record, just make sure the attribute names match those in the database itself.  Say your FeatureLayer has an attribute called "NAME".  Your new graphic instance won't have a "NAME" attribute yet, but you can add one, and when you save your FeatureLayer's edits, that new value will flow back to the database.  However, if you tried to add an attribute called something else, like "SNAZZY_NEW_ATTRIBUTE" to your new graphic instance - an attribute that doesn't exist in your database - you'll run into problems.  When you save the FeatureLayer's edits, the call will bomb, since there isn't a "SNAZZY_NEW_ATTRIBUTE" field in your database.

I hope this helps!

Have a good one,
Brooks