Latest Contributions by JoshuaBixby

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.

@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.

If money is no object, there is always Entity Extraction Software | Unstructured Data Analysis | ArcGIS LocateXT (esri.com), but I think your situation is simple enough Excel's Text to Columns should work.

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.

I am a big fan of regular expressions, which is why I am so disappointed the Python builtin re module has such weak support for Unicode categories. Fortunately, it is quite common that people will bundle regex · PyPI with their Python deployments, including Esri. Using regex instead of re allows for people to use Unicode categories to write regular expressions that are much more portable in this global world we live in: import regex def remove_alpha(value): return regex.sub("[^\p{NUMBER}\p{DASH}]", "", str(value))

I believe the OP wants to sum over all columns for each row, which is the opposite of what Summary Statistics does.

If the field does not allow NULL, then returning None would create an error since Python None gets converted to SQL NULL.

With multiple processes accessing the same file geodatabase, especially to make edits, you will run into locking issues. Might be worth reading through: FAQ: How Are the Various Lock Mechanisms Implemented in ArcGIS Enterprise and the Geodatab (esri.com)

The function hasn't been updated to understand how to interpret a database connection string. The results from CreateDatabaseConnectionString are a Python string, and Describe interprets a Python string to either be a path to a suitable item or the name of an instantiated ArcGIS Pro object, which the string from CreateDatabaseConnectionString is neither. It is similar to passing the path of a CSV file vs passing the contents of a CSV file to Describe. The function would know what to do with the former, but would give the same OSError on the latter because it doesn't understand that contents of a CSV file were just passed to it.

This can be done with a Python 6.13. Conditional expressions; Python 3.x documentation, aka ternary operator, and doesn't require a code block: !DateField![3:5] if !DateTypeField! == "D" else None

A Python if statement will be far from the slowest part of this process.

Even with ArcGIS Desktop/ArcMap, if you define a function with only a pass statement and nothing else, it will return None and then Calculate Field turns that None into a SQL NULL. Although Calculate Field does iterate over the records, your pass statement is in a function that is being called on each row and not within the loop itself. A Python function has to return something, either a value or an error. If you don't return something, then Python None is returned.

You are passing expression type, which is the fourth parameter, as the second parameter, which is field. Also, when you pass the second parameter, you don't put it in square brackets, which creates a Python list and will cause another error. Try: arcpy.management.CalculateField(out_fc, "SEGMENT", r"!STRUCTUREBEG! + ' to ' + !STRUCTUREEND!", "PYTHON3")

Providing representative code would be helpful because it is likely how you are calling the tool that is causing the issue. From Select Layer By Attribute (Data Management)—ArcGIS Pro | Documentation If the input is a feature class or dataset path, this tool will create and return a new layer with the result of the tool applied. Are you passing a feature class or dataset path to the tool or the name of a layer or view?

‎04-10-2024

Have you tried using an UpdateCursor—ArcGIS Pro | Documentation? If so, any error messages?

Online Status	Offline
Date Last Visited	yesterday

My Ideas

Latest Contributions by JoshuaBixby

Re: New Geodatabase Features Add Functionality But Complicate Compatibility and Interoperability

Re: New Geodatabase Features Add Functionality But Complicate Compatibility and Interoperability

Re: Extracting an Address from a string

New Geodatabase Features Add Functionality But Complicate Compatibility and Interoperability

Re: Remove Non-numeric Characters

Re: sum multiple fields

Re: Converting state name abbreviations to full state names using ArcGIS Field Calculator

Re: Multiprocessing with ArcGIS Pro arcpy

Re: Describe Workspace properties don't work from CreateDatabaseConnectionString()

Re: ArcGIS Pro field calculator if statements based on value of other field

Re: Most efficient way to concatenate strings in millions of records ignoring nulls and spaces

Re: ArcGIS Pro Field Calculator just converts entire column to null values

Re: Syntax for arcpy.management.CalculateField

Re: How to Stop "SelectLayerByAttribute_management" creating temporary tables, while running script in ArcPro

Re: Calculate Field won't update a date field

Re: New Geodatabase Features Add Functionality But...

New Geodatabase Features Add Functionality But Com...

Re: Remove Non-numeric Characters

Re: Multiprocessing with ArcGIS Pro arcpy

Re: Converting state name abbreviations to full st...

Esri Forestry Group (EFG)