In ArcMap, labels and tooltips include the ability to add complex expressions to dictate what value will be shown for each layer.  As these settings are set at the layer level, changes to the layer will impact these expressions.

When you add your first join to a layer, for example, things can change behind the scenes.  Understanding why this occurs can be useful, and can sometimes help fix frustrating uncommon issues.

When a layer without joins becomes a layer with joins, the fields available to that layer can no longer stay be defined simply, due to multiple tables participating in the layer. Instead, they become fully-qualified – that is, the database and schema name are prepended to each field – so that you can be sure that the field you’re looking for is coming from the right table.

If you add a join, ArcMap does you a favor and makes this change for you in the layer’s expressions for labels and tooltips so that things will work properly.

As an example, say we’re working in a database called “GIS” with a schema name of “SSP”, and we are trying to use a label text field in our fuse bank’s expression.  By default, the variable name in the expression would be called [LABELTEXT].  The fully-qualified name would be [gis.ssp.FuseBank.LABELTEXT].

With labels and tooltips, this generally means that little action is required once a join is created; however, there are occasionally issues that make this knowledge useful.  For example, we recently witnessed a situation where ArcFM™’s Feeder Manager 2 joins were not applied when opening a map document with ArcFM Viewer™.

This knowledge allowed us to provide a reasonable workaround to the issue, which was to manually use both methods.

For example, this transformer label expression only works on layers without joins:

Function FindLabel ([KVA], [PhasingCode])
  FindLabel = [KVA] & [PhasingCode]
End Function

We also know that changing it to use fully-qualified names would allow it to work on layers with joins, but it would no longer work on layers that don’t have joins:

Function FindLabel ([gis.ssp.TransformerBank.KVA], [gis.ssp.TransformerBank.PhasingCode])
  FindLabel = [gis.ssp.TransformerBank.KVA] & [gis.ssp.TransformerBank.PhasingCode]
End Function

This normally isn’t a problem since the label expressions will make this change for you once your first join is added or your last one is removed.  But in our example, the joins were simply not being loaded properly in one environment, and the label expressions weren’t being changed automatically.

We had fully-qualified names for our layer because they worked properly in ArcMap, but changing them back to support ArcFM Viewer™ would then break ArcMap. As a result, we used both!

Function FindLabel ([KVA], [PhasingCode], [gis.ssp.TransformerBank.KVA], [gis.ssp.TransformerBank.PhasingCode])
  if [KVA] <> "" or [PhasingCode] <> "" then
    FindLabel = [KVA] & [PhasingCode]
  else
    FindLabel = [gis.ssp.TransformerBank.KVA] & [gis.ssp.TransformerBank.PhasingCode]
  end if
End Function

This works well if tweaked correctly. The parameters that don’t end up being used don’t break the expression, and we can use a conditional to figure out which fields are being used. This allows us to consider both options effectively.

The fun doesn’t stop there, though, because this knowledge can also be put to use with annotations. Annotation feature classes are stored in the geodatabase, not within a layer on a map.  To manage them, you have to go into ArcCatalog, navigate to the annotation feature class, and change the expression(s) from there.

However, we have seen cases where annotation feature classes still respect joins, despite the fact that annotation classes can be used from any map independent of any single layer due to being managed at a geodatabase level.  When you add a join to a map, the annotation expression doesn’t change, and if you go to change the annotation expression, ArcCatalog isn’t aware of joins at the map-level.

But we have experienced the woes of annotation and joins firsthand, especially when upgrading an ArcFM™ implementation to Feeder Manager 2.0, which will automatically join electric layers to their respective in-memory feeder tables.

In some cases, the Feeder Manager 2.0 join could also be manually disabled when needed, and we would still want annotation to work properly in that case.  Ultimately, we want annotation to work with or without joins.

If you’re experiencing an issue where an annotation expression breaks, consider the possibility that joins may be the culprit. You can work around this by using both standard and fully-qualified field names, as shown above.

Of course, these steps help with the diagnosis and treatment of the problem, but they’re not a cure. Regardless, knowing about how joins affect expressions has saved the day numerous times now, and can alleviate issues while the problem is addressed.