Using TableDefinition and FindField

[BrianBulla]

Hi,

I'm using the following code to determine if a field exists in the current layer:

var currentLayer = map.FindLayers(layer.Name).FirstOrDefault() as BasicFeatureLayer;
                        
//Does current layer have FACILITYID field??
Boolean facID_field = false;

TableDefinition tableDef = currentLayer.GetTable().GetDefinition();
if (tableDef.FindField("FACILITYID") >= 0)
      facID_field = true;‍‍‍‍‍‍‍‍

When I do not have a Join setup on the layer everything is fine, but with a Join I will get an "InvalidOperationException" error on the TableDefinition line of code:

An exception of type 'System.InvalidOperationException' occurred in ArcGIS.Core.dll but was not handled in user code

Additional information: The dataset 'SAN_Manhole_MH_dbf' does not have a valid definition.

In this case, the layername is 'SAN_Manhole' and the joined table is 'MH_dbf'.

Is there another way I should be looking for fields in a layer??  Or is there just an issue with Joined layers going on in the background.

Thanks,

[BrianBulla1]

Hi Sean Jones,

So how is it possible to do what I want to do using the Fieldname (NOT the alias).  To me it makes more sense to use the fieldname, since the user cannot change it in their aprx file like they can with the alias.

I have been doing some experimenting and I am able to give any number of fields the same alias name in ArcPro.  The strange this is, that when I run the code the proper field always gets updated, even though there are many fields with the same name.  Can you explain how that is working??

[Anonymous User]

Hi Brian

So how is it possible to do what I want to do using the Fieldname (NOT the alias).

To use the field name you would have to know if the layer is joined (.GetTable().IsJoinedTable()) then use the fully qualified field name (Inspector["Table.FieldName"]) if it is. In the future we may add a shortname property to the inspector to make it easier or better yet have the inspector deal with either a short or full string. There's always the chance of having the same field name in both tables though.

I have been doing some experimenting and I am able to give any number of fields the same alias name in ArcPro

I couldn't reproduce this. I tried setting the alias of ANCILLARYROLE to GRIDNO and it tried to update that field with H27, which it couldn't do. The inspector looks at the layer field names and aliases, not the data source so be careful where the alias is set.

[CharlesMacleod]

The issue may also be that you are not using a non-recycling cursor. To test, access a non-recycling cursor off the feature class, not the layer.

[BrianBulla]

Hi Charles Macleod‌ and Rich Ruh‌,

I was able to get the EditOperation code to work by changing a bit of the code.  As Charles mentioned, using the non-recycling cursor allows me to edit the field, but again only when there is NO join.  As soon as I add the join I cannot edit the field because of the 'mangled' field name.

So it seems like regardless of using EditOperation or Inspector Classes, there needs to be some way to access the field when there is a join.  In ArcObjects I never had this problem, but if there is a better solution to what I am trying to do just let me know.  In the meantime I am working on packaging up some data and will hopefully get a ticket submitted later today.

Thanks!

[JohnJones]

Brian, note that in ArcObjects only the base table is editable, not joined layers (represented as RelQueryTables), so the table that you are referencing isn't the joined table.  However in Pro the inspector object has been loaded with the layer's values (not going directly to the geodatabase base table) so all fields are there and hence they are fully qualified.  As a convinience (and consistent with the ArcMap attributes window's behavior) the Inspector will allow you to modify the fields in the left hand table through the joined view (like ArcMap the joined fields are read only through this view).  To get behavior more similar to ArcObjects you would need to load the inspector with a Core.Data Table or FeatureClass rather than the higher level joined Layer.   At that point you should see non-qualified field names for that table and no joined fields from other tables.  

Thanks

[ÉricGosselin]

Rich Ruh‌Charles Macleod‌ 

Hi, I'm Eric G from Esri Canada Tech Support, I have create a support case and escalated to Esri Inc.

The case number is 02217135.

I have a reproducable code that I can share with you. I will send you the info using Outlook