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,

[RichRuh]

I don't think you're doing anything wrong.  At this point I'm just trying to narrow down what isn't working and hopefully provide you with a workaround.  

Do the other fields (GRIDNO, LocalMunicipality, SettlementArea) have mangled names when you use .GetFieldDescriptions(), or is it just DEPOTAREA?  Does DEPOTAREA come from a different source table than the other fields?

One more thing to try is to fetch the row and edit it with Editor.Modify() rather than using the Inspector.  If nothing else, that will help us determine if the Inspector class is causing the problem or if the problem is at a lower level.

If there is an easy way to package up some code and data that reproduces the problem and submit it to technical support we can do some of this experimentation on our end.  Thanks for your patience.

--Rich

[BrianBulla]

Hi Rich,

Yes, the other fields have mangled names too, but only with the join present.  

All the fields are from the same table/feature.

I will give it a go with Editor.Modify() and get back to you.

Thanks!

[BrianBulla]

Hi Rich,

I'm trying to edit using EditOperation, but having some issues getting the code to work.  Can you see where I am going wrong?  No errors, but the feature doesn't actually get edited.

                            foreach (var oid in selectedOIDs)
                            {
                                var qf = new QueryFilter() { WhereClause = "OBJECTID = " + oid };
                                var cursor = currentLayer.Search(qf);
                                var editOp = new EditOperation { Name = "Edit DEPOTAREA" };
                                

                                while (cursor.MoveNext())
                                {
                                    Row row = cursor.Current;
                                    editOp.Modify(row, "DEPOTAREA", "ORONO");
                                    featureCount++;
                                }

                                editOp.Execute();
                            }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[RichRuh]

Your code looks fine. I going to guess that editOp.Execute() returns False, and that editOp.ErrorMessage contains a string that may or may not be useful.  My guess is that the Editor is having the same problems finding the field "DEPOTAREA" as the original code.

I'm out of ideas.  Could you send this to text support with some data and a code snippet?  You can add my name so that there are no delays routing it to me. At this point I need a debugger to take a closer look.

Thanks,

--Rich

[BrianBulla]

OK.  Sounds good.  I will ZIP up a bunch of data and the source code.  How do I send it to Tech Support??  Can you give me their contact info??

I'm out of the office tomorrow, but I'll try to get it out to you on Wednesday.

Thanks,

[RichRuh]

This link should help: https://support.esri.com/en/contact-tech-support#us 

--Rich

[BrianBulla]

OK, so I'm still working on getting that support ticket, but in the meantime I did more testing today, and the problem only seems to happen when that feature class has a Join, and only on the DEPOTAREA field.  The other fields are updating fine, even when there is a join.  

There are no duplicate field names in the joined table either, so I'm not sure what the problem is.

Anyways, I hope to have that ticket issued next week once our contact with esri is back in the office.  If you can think of anything in the meantime, just let me know.

Thanks

[BrianBulla]

Hi Rich,

So it looks like that using DepotArea instead of DEPOTAREA is resolving the problem.  I'm still not 100% sure why though and was hoping you can shed some light.  Here are some details on my data:

NAME	ALIAS
LOCALMUNICIPALITY	LocalMunicipality
GRIDNO	GRIDNO
SETTLEMENTAREA	SettlementArea
DEPOTAREA	DepotArea

In ArcObjects, using the highlighted names always worked, but in ArcPro they all worked except for DEPOTAREA.  So I am using the Alias now, but in the documentation for the Inspector class it just says to use the 'Attribute Name'.  Is it really case-sensitive??

http://pro.arcgis.com/en/pro-app/sdk/api-reference/#topic9684.html

[RichRuh]

I'm asking some colleagues, but I don't have a ready explanation.  If you made any progress putting together a reproducible case for tech support, I'd love to take a closer look. 

[Anonymous User]

Brian Bulla wrote:

So I am using the Alias now, but in the documentation for the Inspector class it just says to use the 'Attribute Name'.  Is it really case-sensitive??

Hi Brian.

Yes the inspector key is case sensitive. It looks for either the field name or field alias.

Before the join, “DEPOTAREA” works because that’s the field name.

After the join, the inspector FieldName becomes “Table.FieldName” or “SAN_MANHOLE.DEPOTAREA”.

Therefore "DEPOTAREA" is no longer found in either the field name or field alias.

In the previous line, “SettlementArea” works before or after the join as that’s the field alias. "DepotArea" would also work for the same reason.

We'll get this addressed for 2.3 where they key will be case insensitive. Thanks for sending the data.

Sean