problem with FeatureLayer QueryAttachmentInfos with Joins

[TerryGiles]

I think a found a bug or two with QueryAttachmentInfos.  Is anyone else using this and seeing similar behavior?

I've been using the code below to get attachements, if present, for graphics returned from IdentifyResults -

                    flyr.Initialized += (s, e) =>
                    {
                        string title2 = t2;
                        Graphic feat =  f2;
                        FeatureLayer fl = s as FeatureLayer;
                        FeatureLayerInfo fli = fl.LayerInfo;

                        if (fli.ObjectIdField != null)
                        {
                            urlFeature = urlLayer + "/" + feat.Attributes[fli.ObjectIdField];
                        }
                        else
                        {
                            urlFeature = urlLayer + "/" + Guid.NewGuid().ToString();
                        }

                        _dataItems.Add(new DataItem() { Title = title2, Data = feat.Attributes, Id = urlFeature });
                        _dataLinks.Add(urlFeature, new List<DataLink>());

                        cbxIdentify.ItemsSource = _dataItems;

                        if (fli.HasAttachments)
                        {
                            fl.QueryAttachmentInfos(feat, FLayer_QryAttachmentsComplete, FLayer_QryAttachmentsFail);
                        }

                    };

It works great until I joined a table to a layer in the mxd and republished the service.  Now I get the following error on fl.QueryAttachmentInfos -

System.ArgumentOutOfRangeException was unhandled by user code
  Message=Specified argument was out of the range of valid values.
Parameter name: Invalid graphic or ObjectID
  StackTrace:
       at ESRI.ArcGIS.Client.FeatureLayer.QueryAttachmentInfos(Graphic g, Action`1 callback, Action`1 errorCallback)....


The other overload for QueryAttachmentInfos takes the feature's OID as the input instead of a graphic, but when I try using feat.Attributes[fli.ObjectIdField] it's null.  fli.ObjectIdField is coming back as the fully qualified field name but in the graphic, the attributes are not qualified.  Is this by design or another error?

Thanks,

Terry

[TerryGiles]

Here's a quick work around for anyone who needs it -it uses the 2nd overload I mention at the end of my first post and a quick LINQ query to get the features OID.  Should probably add some error handling such as ensuring fli.ObjectIdField is not null..

                        //get OID
                        Field fldID = fli.Fields.First(x => (x.Name == fli.ObjectIdField));
                        string id = fldID.Alias;
                        string oid = (string)feat.Attributes[id];

                        if (fli.HasAttachments)
                        {
                            try
                            {
                                fl.QueryAttachmentInfos(feat, FLayer_QryAttachmentsComplete, FLayer_QryAttachmentsFail);
                            }
                            catch (System.ArgumentOutOfRangeException)
                            {
                                try
                                {
                                    //issue with feature, try OID instead
                                    fl.QueryAttachmentInfos(oid, FLayer_QryAttachmentsComplete, FLayer_QryAttachmentsFail);
                                }
                                catch
                                {
                                    return;
                                }
                            }
                           
                        }

[TerryGiles]

While I found a work around, I still think this is a bug.  Any comments from ESRI on this?  Is this behavior by design or no?  I think the API should be consistent in how field names are returned to avoid such issues.  Just my 2 cents...

[JenniferNery]

I'm a little bit unclear - are you saying that after republishing the service, the layer fields do not match the graphic attributes? Kindly see attached.

[TerryGiles]

Hi Jennifer.

Yes that is correct.  If I hit the REST end point of the service it shows the fields name fully qualified.  Same if I query the layer that why the JSON results have the qualified names as shown here -


  "fields" : [
    {
      "name" : "ppqtest.DBO.irfa_qbnd2009_test.OBJECTID",
      "type" : "esriFieldTypeOID",
      "alias" : "OBJECTID"},
    {
      "name" : "ppqtest.DBO.irfa_qbnd2009_test.Quarantine",
      "type" : "esriFieldTypeInteger",
      "alias" : "Quarantine"},
    {
      "name" : "ppqtest.DBO.irfa_qbnd2009_test.Shape",
      "type" : "esriFieldTypeGeometry",
      "alias" : "Shape"},
    {
      "name" : "irfajoin.OID",
      "type" : "esriFieldTypeInteger",
      "alias" : "OID"},
    {
      "name" : "irfajoin.Field1",
      "type" : "esriFieldTypeInteger",
      "alias" : "Field1"},
    {
      "name" : "irfajoin.irfaoid",
      "type" : "esriFieldTypeInteger",
      "alias" : "irfaoid"},
    {
      "name" : "irfajoin.testfield",
      "type" : "esriFieldTypeString",
      "alias" : "testfield",
      "length" : 50}
  ],


Result from querying for an known Object ID -

  "features" : [
    {
      "attributes" : {
        "ppqtest.DBO.irfa_qbnd2009_test.OBJECTID" : 403,
        "ppqtest.DBO.irfa_qbnd2009_test.Quarantine" : null,
        "irfajoin.OID" : 0,
        "irfajoin.Field1" : 403,
        "irfajoin.irfaoid" : 403,
        "irfajoin.testfield" : "test data from joined table"
      },
      "geometry" : {
        "rings" : [  ......



However in the graphic that comes back from the identify the Keys in .Attributes are not qualified-

(dumped this out via foreach (f in g.Attributes){system.diagnostics.debug.writeline(f);}
[OBJECTID, 403]
[Quarantine, Null]
[Shape, Polygon]
[OID, 0]
[Field1, 403]
[irfaoid, 403]

It seems that when the IDictionary is getting populated the Alias is being used for the key and not the Name.

Does that make more sense?

[JenniferNery]

Looking at the JSON, fields and attributes match in name but you mentioned that Identify results contain attributes with alias instead of name.

This seems to be related thread: http://forums.arcgis.com/threads/16331-Results-from-IdentifyTask-are-not-correct-%28indexed-by-Field...

[TerryGiles]

Hi Jennifer,

Looks like the same issue as described in that post.  Do you know if there is a bug # for this so we check it's status?  I installed SP2 while working on this issue and that did not fix the issue.

Also do you think this is why I cannot pass the graphic returned from the Identify directly to QueryAttachmentInfos?

Thanks again, TG

[JenniferNery]

I'm afraid I cannot answer this question. You can post in the server forum http://forums.arcgis.com/forums/11-ArcGIS-Server-REST-API.

It seems like IdentifyTask had always been designed this way so I'm not sure if it was ever logged as bug or not. A much older post: http://forums.esri.com/Thread.asp?c=158&f=2421&t=284527.

What you had as workaround seem like the ideal solution given that the result of IdentifyTask uses Alias, you need to use the field's Alias instead.