New Geodatabase Features Add Functionality But Complicate Compatibility and Interoperability

296
6
2 weeks ago
Labels (1)
JoshuaBixby
MVP Esteemed Contributor

I posted the following in Pro 3.3 beta forums, but I wanted to post on Esri Community in case someone or some organization has found an elegant solution to managing compatibility and interoperability between products and versions as Esri adds more functionality to geodatabase objects.

When Esri simplified the Geodatabase schema back at ArcGIS 10.0, it allowed for the addition of new functionality to geodatabase objects without having to update the Geodatabase schema itself. In and of itself, I think it was a really wise move that made the Geodatabase schema much more robust to survive the test of time; however, it hasn't been without its issue.

As Esri has added new features to geodatabase objects, e.g., attribute rules in ArcGIS Pro 2.1 and new data types in ArcGIS Pro 3.2, it is great that feature classes, tables, etc... that don't rely on that new functionality can continue to work in older Esri software; BUT, Esri hasn't really provided many tools for helping organizations and users manage compatibility and interoperability across software and versions.

I know in a perfect world no one would be using ArcGIS Desktop/ArcMap any longer, and every ArcGIS Pro user would already be using 3.2 (soon 3.3), but the reality for large organizations is that transitions to new software and versions takes time, as in years sometimes.

I recently spent some time in the bowels of the Geodatabase schema and the schemas of its objects, and I realized there is a RequiredGeodatabaseClientVersion XML element for feature classes and tables. Not only is the element specific, it appears to be extremely accurate, which is great. However, outside of querying GDB system tables, how are organizations and users supposed to be able to access that information to easily and accurately determine whether a given geodatabase object is compatible with the software they are using or plan on using?

If I am missing the obvious, mea culpa, just point me to the documentation for the tools I can use because I haven't had any luck.

6 Replies
RyanUthoff
Occasional Contributor III

This is a great point, and quite frankly, something that has frustrated me as I've found out these compatibility requirements the hard way. For example, high precision date fields are only compatible with 3.2/11.2. I didn't realize that until it was too late.

I think having a feature compatibility matrix would be VERY helpful. Something that is very easy to look at and quick to reference. Because right now, I have to dig through and research the release notes for each version to determine compatibility requirements which even then, isn't 100% clear.

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

@RyanUthoff, if you use GDAL at all, you might be interested in reading my answer to qgis - How to tell file geodatabase' version using open source tools? - GIS SE where I give ogrinfo code for querying the RequiredGeodatabaseClientVersion for objects in a geodatabase.

 

0 Kudos
Bud
by
Notable Contributor
0 Kudos
George_Thompson
Esri Frequent Contributor

Not sure this meets all the needs but a start...... https://enterprise.arcgis.com/en/server/latest/manage-data/windows/client-geodatabase-compatibility....

--- George T.
0 Kudos
JoshuaBixby
MVP Esteemed Contributor

It is a quote in that linked page that gets to the heart of the issue:

Older ArcGIS clients can open, query, edit, and save data in newer release geodatabases, but they cannot open datasets that participate in newer functionality. You will encounter the following error messages when you try to access a newer type of dataset from an older ArcGIS client:

The version of the Geodatabase client is incompatible with the dataset and cannot open it.

Failed to add data, unsupported data type.

First, that is not the error message one receives when accessing tables or feature classes with new functionality in file geodatabases.  The actual error message is more verbose and yet less helpful in understanding what is actually happening.

That quotes leads back to my question/issue, what tools are readily avaialble for an organization to determine compatibility beforehand?  Simply having users try and get an error message isn't a very enterprise-y way of going about it, not to mention the time it wastes.

Bud
by
Notable Contributor

Possibly relevant:

What's new in ArcGIS Pro 3.3 - Enterprise geodatabases and databases

If your enterprise geodatabase contains branch versioned data, it is strongly recommended that you upgrade the geodatabase at ArcGIS Pro 3.3. See How Upgrade Geodatabase works for more information.

0 Kudos