nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Find more posts tagged with

Accepted answers

All comments

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.

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

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

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

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.

LayerInfo.Fields.png

Graphic.Attributes.png

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

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

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.