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

Layer failing to load in Field Maps app only

NicoleV

Hello all,

I have an issue with a layer failing to load in the Field Maps iOS application. The layer loads perfectly fine in the accompanying web map and also in a Web App Builder application. This is the error it is throwing:

Domain: com.esri.arcgis.runtime.error
Code: 10018
Description: Invalid cast.

I found this post but I ran a Domain Check in data reviewer and there were no attributes that did not meet domain requirements. A different issue I've seen where the layer was not loading in Field Maps (with a different error code) was where the domain field type and the field type of the attribute were not matching, but that is not my issue either.

Also, I found this documentation but this is a line layer so it is not using any marker symbology so that's not it.

I am fully at a loss so any ideas or suggestions would be much appreciated!

Find more posts tagged with

Accepted answers

NicoleV

Updating the schema worked. Since we did it this way still not exactly sure what specifically was the cause of the error was. We are just assuming it was either a different field/domain data type mismatch or the fact that the shared domain was no longer attached the the field but was still stored in the database??

All comments

Nick_Creedon

Is it a point layer? I had a similar issue when I was using custom symbology. I was creating custom symbols in ArcGIS Pro and sharing them to AGOL with no errors in maps or apps but when I launched them in field maps they wouldn't load. I figured out that the symbols were actually too large in size, and I had to remake them in AGOL and then I resolved my issue.

NicoleV

No, this is a line layer. I still re-did the symbology just in case there was something I couldn't see but am still having the issue after I re-published.

Nick_Creedon

Without seeing the layer, my other thought, did you by chance create the domain after you had all the fields filled out? This can create a weird disconnect with the data and you have to go back and re-fill out the domains for all the features.

NicoleV

There was a new field added to the layer prior to publishing. However, the domain was existing. The domain and new field have matching field types and there are no length issues. Currently the entire field has Null values.

Nick_Creedon

I have created long domains where the codes are fine, but the descriptions were too long, so it resorted to showing the domain codes instead of descriptions when editing. This behavior happened in AGOL I didn't see what it would do in field maps.

If you believe the rest of your layer is fine and it's the domain, you could try this is a long work around... You could use export domain to table tool--> create new GDB --> duplicate your layer in the new GDB-->reconfigure fields--> use Table to Domain tool and configure your field to the new domain --> symbolize--> share back out.

If the domain is not lengthy, I would just recreate it, but I know if it is long that stinks to recreate, so exporting it to a table and importing the table to domain is a lot quicker.

If I am having issues, I start with a clean slate to isolate the problem. The Domain Codes or Descriptions might be too long. You said the field types are the same. Don't add default values to editing templates.

NicoleV

The code and description of my domain are identical, because my org previously found the same issue you described above so now our practice is to forgo differing codes and descriptions. This is an enterprise database layer and the domain is used on about 30 datasets so rebuilding is not ideal.

However, I do not believe the domain is truly the issue, I was using it as an example because the previous post I referenced found that was their issue, so I was ruling it out with my data reviewer check I ran.

MitchellGrafstein

It seems the general error here is stating that there is a conflict with the type of field and/or other attributes of the field and the values within the domains.

Most likely, will have to analyze the domain itself down into the JSON.

Navigate to the item page in AGOL or Enterprise. You can click on the service URL pop-up in ArcGIS Online (or Enterprise depending which version) which should be on the bottom right. Click on the JSON link to open the JSON. You should see a section called "fields" which will have all the fields within the service and if you have a domain, the domain will be listed within the individual fields that have them. Inserted a sample below. Had to choose Markdown just to keep formatting, but not sure why in the world there is no JSON formatting.

{
    "name" : "field_name", 
    "type" : "esriFieldTypeString", 
    "alias" : "alias_name", 
    "sqlType" : "sqlTypeOther", 
    "length" : 32, 
    "nullable" : true, 
    "editable" : true, 
    "domain" : 
    {
      "type" : "codedValue", 
      "name" : "arbirary_coded_value_name_assigned_or_from_hosting_source", 
      "codedValues" : [
        {
          "name" : "No", 
          "code" : "No"
        }, 
        {
          "name" : "Yes", 
          "code" : "Yes"
        }
      ]
    }, 
    "defaultValue" : null
  }

Things to look for would be it not allowing null values and the default is null. For string types, anything that is not a string in the coded value (code) part of each object. Also, for strings, anything in the coded value (code) part of each object that has a length which is greater than the field length.

If there are no trade secrets in the JSON, you can copy the "field" list here and I can take a look (or you can PM me.)

I hope this helps.

NicoleV

No trade secrets, here is the info.

{
   "name": "MAINTAINEDBY",
   "type": "esriFieldTypeString",
   "alias": "Maintained By",
   "domain": {
    "type": "codedValue",
    "name": "Department",
    "description": "The overall dept responsible for managing the work area. Managed By.",
    "codedValues": [
     {
      "name": "Development",
      "code": "Development"
     },
     {
      "name": "Fire",
      "code": "Fire"
     },
     {
      "name": "NNRHA",
      "code": "NNRHA"
     },
     {
      "name": "Parks",
      "code": "Parks"
     },
     {
      "name": "Police",
      "code": "Police"
     },
     {
      "name": "Public Works",
      "code": "Public Works"
     },
     {
      "name": "Waterworks",
      "code": "Waterworks"
     },
     {
      "name": "Sheriff's Workforce",
      "code": "Sheriff's Workforce"
     },
     {
      "name": "General Services",
      "code": "General Services"
     },
     {
      "name": "Engineering",
      "code": "Engineering"
     }
    ],
    "mergePolicy": "esriMPTDefaultValue",
    "splitPolicy": "esriSPTDefaultValue"
   },
   "editable": true,
   "nullable": true,
   "length": 60,
   "defaultValue": null,
   "modelName": "MAINTAINEDBY"
  }

MitchellGrafstein

Just a guess...I am wondering if the code having a single quote within it might be a potential issue. While single quotes should be allowed in the JSON standard, I do not see anything else as even a potential issue.

It could possibly be an underlying database issue with how this is being stored. Not sure how annoying it is for you to test this, but you could update the domain to remove the apostrophe and see if it makes for a better day.

While not ideal for the final solution, it at least gets us to the potential root of the problem. (You can always create a new service off of the existing one and then just update that if this one is in production.)

I am about at the end of my day here, but I will check in on this again tomorrow.

NicoleV

I had that thought as well that the apostrophe could be the issue. However, I have other layers that use this same field and domain combination and they are loading just fine in the same Field Maps map. I'll have to dig deeper into my other domains but like I said I did a data reviewer Domain Check on this layer and it returned no errors so I feel like that roots out the issue being with the domains.

NicoleV

Well here's an update...

Did some more digging in my layer and found that 3 fields had a differing field type from the domain field type. I was focused on the "Maintained By" field because that was newly added so initially thought that was the problem. However, we also had a version of the layer published to our REST that did not have that new field added, so when I tested that layer in Field Maps and it was also failing to load, I knew it was not being caused by this new field.

Initially I created a copy of my layer and then removed all the domains that did not match field types, published that layer and pulled it up in field maps and it loaded!

Looking back at the field and domain combinations, I realized I had one field that was numeric and the domain was a text, whereas all the other fields were vice versa. So once I did another test with just removing that specific domain and it loaded properly in field maps I thought I had finally found the culprit. However, once we detached the domain from the field in the enterprise layer, I got a completely different error.

Domain: com.esri.arcgis.runtime.error
Code: 3079
Description: Domain exists.

According to this esri support documentation this has a few causes. However, we completely disconnected the field and the domain so not sure how the data-type mismatch is still causing this error. We did the steps in the solution and are still getting the same error.

It's definitely not ideal but at this point we believe the only path is to do some schema updating using X-Ray to ensure there are no more data-type mismatches between fields and coded domains.

NicoleV

MitchellGrafstein

Glad you were able to fix the issue. Unless you were able to dig into the database itself, it would be hard to inspect that last part. It would be nice to know exactly what the cause was, but sometimes it is just nice to have an issue resolved and know you can resolve it if it appears again. (Seems like it would be the mismatches, only based on the descriptions in the wild, but hard to tell for sure.) Appreciate the back-and-forth on this.

NicoleV

Yes very true, we are just glad to get the layer back up and running so our field staff can finally use it! Thank you for your guidance, it really helped me narrow things down!

MitchellGrafstein

Most welcome, happy to help. 🙂

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.