Get a value from a joined field

[MikeLouwrens]

Hi,

I have a tool that selects two features (different feature-classes), gets a value from a specific field in feature 1 and puts it into a specific field in feature 2. This mostly does what I want, except I would like to get the value from a field from a joined table, but the tool won't work on a joined field.

How do I get it to use a join field value? I went hunting for some code that looks at joined fields, and found something in the old forums that will give me all the field names, including the joined fields, but I can't find an option to get the value from a field. Is it possible to change this script somehow to give me the values from those fields?

Sub JoinedFields()
Dim pDoc As IMxDocument
Set pDoc = ThisDocument
Dim pFeatureLayer As IFeatureLayer
Set pFeatureLayer = pDoc.FocusMap.Layer(0)
 
Dim pFeat As IFeature
Set pFeat = pFeatureLayer.FeatureClass.GetFeature(12)
Dim pTable As ITable
Dim pDisplayTable As IDisplayTable
Set pDisplayTable = pFeatureLayer
Set pTable = pDisplayTable.DisplayTable
 
Dim pFields As IFields
Dim pField As IField
Set pFields = pTable.Fields
For i = 0 To pFields.FieldCount - 1
  Debug.Print pFields.Field(i).Name
Next
End Sub

I had thought I could do something like "Debug.Print pFields.Field(i).Value" but that's not an option.

thanks,
Mike.

[MikeLouwrens]

I have revised your code to make it more efficient. Your code is slow because it uses repeated queries inside of a loop (it also was repeatedly doing a Dim of the Row variable inside the loop as well, which is a big no no. Never do a Dim inside of a loop).

Ah OK, I didn't know that, thanks 🙂  teaching yourself VBA and ArcObjects from sample scripts doesn't always teach you things like that, so thanks.

Thanks for the revision of my code, it runs much better now (runs on 1500+ records faster than it did on 5 earlier), I really appreciate the help and suggestions! 😄 I think I understand what you've done - now to just remember for next time.

Again, much appreciated 🙂
Cheers,
Mike.

[MikeLouwrens]

I tried your code with a file geodatabase and it requried the fully qualified table name and field name, so the behavior is not limited to an SDE geodatabase. But whatever works.

maybe it's the geodatabase and not specifically SDE... odd though

Since your line features are not part of the code you have written and all your code accesses currently is the point feature class, you do not need the emedded loops to read the joined table. You also will not need embedded loops if you are going to simply construct one line from the points, since you would then just be writing to one feature and you can access all of the fields you need including the shape field of the parent table from the ICursor object derived from the IDisplayTable. However, if you are going to construct more than one line from a set of points based on some attrribute you would then need a set of embedded loops to control the creation of each line feature and the writing of the point attribute.

yes, just one line from each point - so shouldn't need the embedded loops.  I can see how that would speed it up.

Mike.

[RichardFairhurst]

I think if you give nothing as the queryfilter to ISelectionSet.Search, it will return all the records as a cursor.

Sean:

You are correct, using Nothing with as SelectionSet.Search method returns whatever records are already currently selected (and not the entire set of features).  That is how my code is set up to behave.  However, I was hoping to use the Update method to return a cursor from the FeatureClass instead of a SelectionSet Search method.  If I use a query filter of Nothing with that method, all of the features of the feature class are returned for the cursor and not just the features that were already selected in the SelectionSet.  If there were an Update method for the SelectionSet that would be ideal, but such a method is not available.

Since a SelectionSet can be purely a user selection that may not have any apparent query where clause logic beyond the list of OID values, the only way I know how to reliably translate a SelectionSet to a whereclause is to list every OID value using an IN statement.  I could build such a where clause by reading the IEnumIDs object from the SelectionSet, but that effectively causes another read of the selected features and the where clause I build might potentially exceed the allowed length of a string object if a lot of features are selected.  I was hoping there is another alternative, but if nothing else is possible, that would be my approach.  That approach should still be worth the trouble, since I expect that building a where clasue to use Update Cursors would still be much faster than using the Store method in combination with a Search Cursor.