Error 00396 - The dataset version is later than is supported by your server. Minimum version: xy.X

davedoesgis

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-is-later-than-is-supported-by-your-server-minimum-version-value-.htm

 

 

 

davedoesgis

Solution Part 1 – OBJECTIDs

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:

1. Do the append with the “Input fields must match target fields” option and then fix the date-only fields later (see next section).
2. After you run Create Feature Class, change the field types from “Date Only” to date. Then, run append with “Use the field map to reconcile field differences”. I didn’t fiddle with the field map at all and everything imported fine. This is much easier.

 

Solution Part 2 – Date Fields

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:

• Create a copy of the feature class.
• Create a new date field corresponding to each “Date Only” field (I just named them with a “2” after them.
• Drag them into the field order just below the original field. Save the edits.
• Use the field calculator to copy the values in from the original field.
• Delete the “Date Only” fields. You may want to rename the fields you created.
• I’ve found that field order changes are only saved for a layer in a Pro map, but not preserved with the feature class or when publishing to Portal/AGOL. For that reason, I did a Data>Export of the map layer to a new layer.
• You should now be able to publish.

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.