nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Pro corrupts my python label expressions when using a table join.

Matt-Goodman

I'm using python label expressions to label address points. They concatenate various address element fields using python's .join() function.

If I apply an attribute join to my address point feature class (in an enterprise geodatabase) my python label expressions are altered by the program and they no longer work.

Here is the python label expression before applying the join (works great like this):

' '.join(str(i) for i in ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF]) if i)

Here is the same expression after applying the join, Pro has altered it (the syntax is bad / does not work):

' sde.SL.address.'.josde.SL.address.IN(str(i) sde.SL.address.for i sde.SL.address.IN ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF]) sde.SL.address.if i)

In the above, you can see that it mishandled the original python expression. It did not handle the opening parenthesis correctly and it upper-cased all instances of python 'in' to (SQL?) 'IN', even in the word 'joIN'. Also, I don't know why the letters 'jo' were appended to 'sde', which is the database instance.

Finally, here is the same python expression after I have removed the table join and the program has tried (unsuccessfully) to revert it back to its original syntax:

' '.joIN(str(i) for i IN ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF]) if i)

Notice the two instances of capitalized 'IN'. Python doesn't like these.

I'm thinking this should be logged as a bug that needs to get fixed?

Vind meer berichten getagd met

Geodatabase

Desktop

Accepted answers

Matt-Goodman

I reported this to Esri and they were able to reproduce the issue and logged it as a bug: BUG-000151759

All comments

Matt-Goodman

Also, pop-ups get ruined after using a join on a feature class. When you create the join, ArcPro automatically appends the full SQL database object name (to avoid field name ambiguity), but after removing the join, the pop-up expressions do not remove the preceding database/object path part of the name.

It's a disaster. If you want to apply a join to a featureclass that you use labeling/pop-up expressions on, you're better off just adding a duplicate instance of that feature class to temporarily use for your join operation/work so you don't screw up the layer you depend on.

It can suck an hour to go through and re-fix a single featureclass' complex label expressions and pop-up expressions.

AngelBarnett

I'm still having this issue in 3.2.1

Matt-Goodman

I reported this to Esri and they were able to reproduce the issue and logged it as a bug: BUG-000151759

rzufelt

I have noticed that if I put the join on before the label expression, it works as expected.

Matt-Goodman

FYI: I tested this using data from a file geodatabase and some of the behavior was similar, but overall it worked slightly better. The software did corrupt the Python syntax while the join was on, but after the join was removed, it was correctly reverted back to a working expression. The program did not uppercase the word 'in', and it did successfully revert the expression back to valid Python syntax after the join was removed, but while the join was on, the syntax was bad.

Label expression before the join (labels work as expected):

' '.join(str(i) for i in ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF], [LST_PREDIR], [LST_NAME], [LST_POSTYP], [LST_POSDIR]) if i)

Label expression during the join (labels do not work, bad Python syntax):

' adp.'.joadp.in(str(i) adp.for i adp.in ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF], [LST_PREDIR], [LST_NAME], [LST_POSTYP], [LST_POSDIR]) adp.if i)

Label expression after the join (labels work again, as expected):

' '.join(str(i) for i in ([ANUMBERPRE], [ANUMBER], [ANUMBERSUF], [LST_PREDIR], [LST_NAME], [LST_POSTYP], [LST_POSDIR]) if i)

Matt-Goodman

Thanks for testing this in 2.9.3!
FYI: I forgot to mention I'm using 3.0.0.

rzufelt

I tested in 2.9.3 and can confirm that it is messing things up, though slightly different than yours.

I don't get any captialization of the "in(s)", and when I remove the join, nothing changes. It keeps the mucked up code.

Original code (works):

' '.join(str(i) for i in ([DirectPrefix],[StreetName],[DirectSuffix]) if i)

After add join (broken):

' PublicWorksApps.DBO.teststreets.'.joPublicWorksApps.DBO.teststreets.in(str(i) PublicWorksApps.DBO.teststreets.for i PublicWorksApps.DBO.teststreets.in ([DirectPrefix],[StreetName],[DirectSuffix]) PublicWorksApps.DBO.teststreets.if i)

After remove join (still broken):

' PublicWorksApps.DBO.teststreets.'.joPublicWorksApps.DBO.teststreets.in(str(i) PublicWorksApps.DBO.teststreets.for i PublicWorksApps.DBO.teststreets.in ([DirectPrefix],[StreetName],[DirectSuffix]) PublicWorksApps.DBO.teststreets.if i)

Matt-Goodman

Has anyone else experienced this issue?

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.