Apparently, the 1369 error can have a lot of causes and potential solutions.
Some other reported solutions are here: https://community.esri.com/thread/137218?q=Publishing
I recently encountered this error when trying to publish the
OutageDetails mxd from the Esri Water Solutions for the Isolation Trace (comes
from WaterWebIsolationA4W.zip) This is an mxd that is referencing an empty schema.
I was however able to publish the mxd up to AGOL. I tried to publish this in a variety of ways, from ArcMap
10.2.2, 10.4, from my desktop, directly from the Portal server, etc… all with no luck.
Esri provided the following explanation and solution:
“The problem is the layer ‘Outage Area’ uses the 'length' field as the display field. You wouldn’t be able to publish the map in 10.4. To get around the problem you could change the display field to something else in the mxd.
In AGOL the publishing implementation is a bit different.”
The Display Expression Field is found in your mxd’s Layer Properties
on the Display Tab. If I looked in there, this was originally set to: SHAPE_Length.
For this mxd, I set the Display Field to OutageType and was then able to publish the mxd successfully to our 10.4
Portal. I am guessing that this was a bug introduced in 10.4 otherwise the Esri Water Solutions folks would have
caught it under Portal 10.3.1?
When I first searched the Server log files, I came across some error messages that were very familiar looking:
"Failed to create the service.: ERROR: code:500, Failed to create the service 'Hosted/OutageDetails.FeatureServer'.
The submitted field 'st_length(shape)' does not exist in the table”
It’s that last line that caught my attention because I had seen it before when trying to publish zipped file geodatabases with certain polygons. Some polygons would fail to publish to Portal while others would publish fine.
All would publish to AGOL.
I had put in a ticket with Esri and level 1 support found a workaround, export the polygon to a
shapefile and then import it back into the Feature Class. It's a usable work around but didn’t define
the underlying problem.
When I look at the problematic polygons, I see the same issue, Default Display field is set to SHAPE_LEN. When we do the export/import, a new field is created in the schema: SHAPE_Leng which then had the display field set to it. SHAPE_Length was still there but was no longer the default display field. This explains why the export/import works.
As a note to others, changing the display field only works for a layer in an mxd. You then publish the mxd to Portal.
In order to make the change permanent in the Feature Class (in a file.gdb or an egdb) you probably have to modify your schema so that the field used for the default display field is not the 'length' field.
The following information lists out how the default display field is chosen (at least from one source, I think back about 9.3) & was taken from:
The default display field is chosen according to the following priorities:
- First field of type Text whose name contains the word "name" (case-insensitive)
- First field of type Text
- First field of an integer type (Long or Short, presumably)
- First field of any type
I don't think there is any way to specify the primary display field without using a layer or layer file, other than using the above logic to name/order your fields accordingly.
If you have a polygon with only a default polygon schema (OBJECTID, SHAPE, SHAPE.AREA, SHAPE.LEN) then the default display field is going to be set to SHAPE.LEN and this won't publish to Portal 10.4.
I have fixed this in our problematic polygons by creating a next text field: XXX.NAME
This way the default display field sees this as the first text field with the word “name”
I then set a default value to the text field, probably not necessary for this fix but useful in our maps..
I have verified this fix works to publish these problematic polygons to Portal 10.4