When publishing a feature layer from Pro 3.2 to Enterprise 11.1 there are some new geodatabase features that are not supported in Enterprise. I got these errors when publishing from a variety of local data sources (including a GeoPackage, Esri FGDB, and I think even a shapefile).
I get this for both analyze and publish:
This error description strikes me as odd. Shouldn't it be a maximum version, not a minimum?
Help link goes here: https://pro.arcgis.com/en/pro-app/3.2/help/sharing/analyzer-error-messages/00396-the-dataset-version...
Solved! Go to Solution.
Pro started offering 64-bit OBJECTIDs, but those are incompatible with older versions of Enterprise (11.1, in this case). Look here to see what your OBJECTID type is:
To fix it, you create a new feature class using the old one as a template, but specifying 32-bit OBJECTIDs. Then, you append the features to it. This KB article describes how. In brief, use the “Create Feature Class” GP tool to create a new feature class. The template dataset imports the fields, but you still have to tell it the geometry type and coordinate system. I think you can set whatever coordinate system you ultimately want, but I just kept the same as the input.
Once you have that, use the append tool to add the features and attributes. The append documentation says it will reproject the data for you if they’re in different coordinate systems, but I didn’t try that.
Note: Read ahead about the date fields in the next section before running the append. Just like the OBJECTID field can be incompatible with ArcGIS Enterprise, so can certain field types (my issue was with “Date Only” fields. There are two way to resolve this:
This help document mentions that new date field types are incompatible with older versions of Enterprise.
Note: That help page also mentions using a field type compatibility option in the settings. I tried this and it had no effect.
See above for how I fixed this while importing it from another format. I ran Create Feature Class to create a template, changed the field types, and then ran an append. That was probably easier than what is discussed below.
To solve this:
Note: I was able to do this because the Date Only field type maps to a date field. A value like 11/25/2024 maps to 11/25/2024 00:00:00 seamlessly in a Python expression in the field calculator. It might then be mangled by Pro’s or Portal’s display into your local timezone, which is part of why people hate regular date fields. Anyhow, this solution works for Date Only fields. The other incompatible fields types (big integer, time only, timestamp offset) might require a different fix.
Pro started offering 64-bit OBJECTIDs, but those are incompatible with older versions of Enterprise (11.1, in this case). Look here to see what your OBJECTID type is:
To fix it, you create a new feature class using the old one as a template, but specifying 32-bit OBJECTIDs. Then, you append the features to it. This KB article describes how. In brief, use the “Create Feature Class” GP tool to create a new feature class. The template dataset imports the fields, but you still have to tell it the geometry type and coordinate system. I think you can set whatever coordinate system you ultimately want, but I just kept the same as the input.
Once you have that, use the append tool to add the features and attributes. The append documentation says it will reproject the data for you if they’re in different coordinate systems, but I didn’t try that.
Note: Read ahead about the date fields in the next section before running the append. Just like the OBJECTID field can be incompatible with ArcGIS Enterprise, so can certain field types (my issue was with “Date Only” fields. There are two way to resolve this:
This help document mentions that new date field types are incompatible with older versions of Enterprise.
Note: That help page also mentions using a field type compatibility option in the settings. I tried this and it had no effect.
See above for how I fixed this while importing it from another format. I ran Create Feature Class to create a template, changed the field types, and then ran an append. That was probably easier than what is discussed below.
To solve this:
Note: I was able to do this because the Date Only field type maps to a date field. A value like 11/25/2024 maps to 11/25/2024 00:00:00 seamlessly in a Python expression in the field calculator. It might then be mangled by Pro’s or Portal’s display into your local timezone, which is part of why people hate regular date fields. Anyhow, this solution works for Date Only fields. The other incompatible fields types (big integer, time only, timestamp offset) might require a different fix.