Follow up to Null versus Not Null in Pro

JoeBorgione

Last week I ran into some confusion when trying to use a FieldName is not null expression.  See https://community.esri.com/thread/211900-arcgis-pro-select-by-attribute-is-not-null .

There were a number of records that had the string '<Null>' entered as the value which threw me off my game considerably.  I talked to the data owner and he jumped on the problem immediately making the proper corrections.

Today I looked at the data again: it's a feature layer that is published from an enterprise geodatabase feature class to our local portal: the data owner made the edits to the e-gdb feature class.  Now when I look at the data via the Select by Attribute tool in Pro, I still see <Null> listed as a value. The expression:

Reach ID  is Equal to <Null> fails  as it should

while Reach ID Is Null works, as it should

and Reach ID Is Not Null works as it should 

However I still see an issue with the way Pro displays string field values with out quotes: the list displays <Null> as a valid value.  After last week's foray, I still would consider this a six character string. ( <,N,u,l,l,>), but it isn't.

KKramer-esristaff‌

Chad_Kopplin‌

Dan_Patterson‌

DanPatterson_Retired

I can only speak for languages that implement the concept of 'null'-ness or 'none'-ness

It is either null, or it isn't  (ie python is one)

Casting it to a string so it shows '<null>'  is just pure evil, confuses people with <null>

I hate any concept of null/none that is not an obvious expression of an impossible value, whether it be text, float or integer.  This distinguishes real valid values from a total lack of an observation.

It makes people complacent.  We will blunder on regardless of how long we have been programming.  -999 was good enough at one time.

 'nuff said