Hi,
I was hoping if someone has come across this issue before.
We have a map that contains a feature layer {point feature layer and related table (non-spatial) }
I can access the map fine but when I try to download and offline area it fails.
After that I thought, is something wrong in layer1 (related table). So I exported the feature layer as FGDB and reuploaded it to AGOL and created a TEST Map. Now this worked perfectly fine when I tried to download the offline area.
I compared the schema of the original feature layer and the TEST feature layer. I found some of the names had been truncated to 31 characters. Could this be the problem?
Original
TEST
The next obvious step was to try and break the TEST layer. So created a new field with name of more than 31 characters. Then I tried downloading an offline area, the result was a fail with the same error.
Removed the troublesome field and I am able to download offline areas on my phone/iPAD.
Has anyone else experienced this?
If the length of the fieldnames is the issue -should this be logged as a bug?
Also can I change field names on the feature layer(AGOL)? I am sure the answer is no but I wouldn't mind being proven wrong.
Any help is appreciated.
Thanks,
Sahil
**EDIT**
A few other tests have confirmed this. It is the field length that causes the issue.
There is no limit (max 31 characters) in AGOL when you create a new field but when you try and download an offline area/replica then possibly that limit kicks in and the process fails.
Solved! Go to Solution.
Mobile geodatabases have a limit of 31 characters. ArcGIS Field Maps leverage similar in a SQLite database. Can't find a specific limit documented anywhere on this.
It may not be an issue (the truncating) generally, but could be manifesting for you if the two truncated field names have the same value e.g. longname1 and longname2 become 'longname' and conflict.
You should avoid having field names this long, as some databases don't support it (e.g. ArcGIS Enterprise limitations are well documented in Survey123). It can be fine as you found out in ArcGIS Online. In ArcGIS Pro, you can add fields up to 64, but sometimes it limits it to 30 as well:
I would recommend going even further, and trying to keep your field names to 10 characters or less. This accommodates shapefiles. Even though they're a dated format, at some chance you may need to give to another user. So just avoid all future conflicts and keep your field names short, field aliases longer.
So from here, you can lodge a support ticket with Esri. They can address it in the documentation or otherwise identify it as a bug. From my perspective, you've already found out what the issue is, and can just bypass it and a bunch of other issues down the track by naming your fields shorter.
Mobile geodatabases have a limit of 31 characters. ArcGIS Field Maps leverage similar in a SQLite database. Can't find a specific limit documented anywhere on this.
It may not be an issue (the truncating) generally, but could be manifesting for you if the two truncated field names have the same value e.g. longname1 and longname2 become 'longname' and conflict.
You should avoid having field names this long, as some databases don't support it (e.g. ArcGIS Enterprise limitations are well documented in Survey123). It can be fine as you found out in ArcGIS Online. In ArcGIS Pro, you can add fields up to 64, but sometimes it limits it to 30 as well:
I would recommend going even further, and trying to keep your field names to 10 characters or less. This accommodates shapefiles. Even though they're a dated format, at some chance you may need to give to another user. So just avoid all future conflicts and keep your field names short, field aliases longer.
So from here, you can lodge a support ticket with Esri. They can address it in the documentation or otherwise identify it as a bug. From my perspective, you've already found out what the issue is, and can just bypass it and a bunch of other issues down the track by naming your fields shorter.
Agreed.
I just thought it was unexpected behaviour that ArcGIS Online allowed you to do this.
We have bypassed the issue by reducing length of the field names.
Just thought, I'd leave this here just in case anyone else finds this useful.
Ill also add here that this problem will occur when your hosted feature service schema contains attribute field names that are reserved Sqlite words. For example, a hosted feature service can have a field named "group". If you try and download this feature service in an offline area you will get the above error as "group" is a reserved sqlite word. See https://sqlite.org/lang_keywords.html for all words that you should never use in AGOL as field names.
Just Everyday! Offline FMA is so badly engineered that Esri shouldn't even call it "offline". More like Fail all the time
I found a big bug recently that was making offline maps fail to download and even failing to package in the Field Maps Designer. DO NOT USE VECTOR SYMBOLOGY !!!
Once I used Basic Symbols it worked again ! until something else crashed it after data update...
Did you find the download issue any fix. If you did find it can you please share it.
Yeah now on the new version of Field Maps Designer, they FINALLY show what the problem is. Most of my problems were related to indexes, long field names, and related tables.
You have to keep your map at the barebones for it to work offline without any issues because of the huge limitations of them using sqlite dbs to store mobile data.
I am having the same issue. The Map is failing to create an offline area under managed areas. I am not getting any messages telling me what is causing the issues. I am using Field Maps Designer, all my tables and field names are ok. The symbology is the only issue. When I am publishing form Pro I am checking the option to use symbol types compatible with all clients. Esri needs to do a better job letting you know what layers symbology with prevent a map from going offline.
I agree. I am experiencing this issue as well. All layers are editable, there are no related tables, and we are on the latest Field maps for Android. It appears as if the slew of "Deprecated" base maps available to choose from could be part of the issue. Even though we are using a supported basemap, it is still failing.