topic Re: problem with FeatureLayer QueryAttachmentInfos with Joins in ArcGIS API for Silverlight Questions

problem with FeatureLayer QueryAttachmentInfos with Joins

TerryGiles — Thu, 19 May 2011 16:13:27 GMT

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

Re: problem with FeatureLayer QueryAttachmentInfos with Joins

TerryGiles — Sat, 11 Dec 2021 07:35:11 GMT

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;
                                }
                            }
                           
                        }

Re: problem with FeatureLayer QueryAttachmentInfos with Joins

TerryGiles — Thu, 26 May 2011 12:44:15 GMT

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...

Re: problem with FeatureLayer QueryAttachmentInfos with Joins

JenniferNery — Fri, 27 May 2011 16:49:06 GMT

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.

Re: problem with FeatureLayer QueryAttachmentInfos with Joins

TerryGiles — Fri, 27 May 2011 17:37:50 GMT

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?

Re: problem with FeatureLayer QueryAttachmentInfos with Joins

JenniferNery — Fri, 27 May 2011 21:55:13 GMT

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-Alias%29

Re: problem with FeatureLayer QueryAttachmentInfos with Joins

TerryGiles — Tue, 31 May 2011 12:44:13 GMT

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

Re: problem with FeatureLayer QueryAttachmentInfos with Joins

JenniferNery — Tue, 31 May 2011 22:43:46 GMT

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.