ArcGIS Pro 3.3.1- Exporting Join Creates NULL values in New Feature's Table

[DylanHinton]

 I updated my ArcGIS Pro from 3.2.2 to 3.3.1 last week and its impacted my weekly workflow a little bit. Once a week, I will perform a join between a feature layer (which is connected to an sde database) and an already exported/static table, and then export the resulting joined layer as a new feature in Pro and publish it online. Now, I can perform the join successfully between my feature layer and table with all the attribute fields showing their values. Unfortunately, the values in the join table become null once they are exported as the new joined feature. I was wondering if anyone has run into this issue?

To trouble shoot this issue, I have tried to index the fields, as well as, ensured that my project is using field types that are compatible with 3.1 and earlier versions. If I export both my feature layer and table separately and then try to join and export them it preserves the joined attributes in the export. It just seems to take a long time to perform the export. 

I can also perform the join in ArcMap and bring the exported feature into Pro and go from there, but I wanted to see if this has happened to anyone using 3.3.1. My workflow has not changed between 3.2.2 and 3.3.1 but the null values from the export are new. 

Thanks for your time

[LoriEmersonKDOT]

I, too, am getting all NULLs in my exported feature class when I export from a feature class that had been joined in Pro 3.3.  However, the problem only occurs when I remove all joins prior to exporting. 

I wonder if it's because the Search By Attributes that I used would no longer be true after I removed the join even though the records are still highlighted.  This would be a bug.

[jeadly]

I've been having success exporting joined or previously joined features by adding this step to my workflow to make sure the exported fields are what is currently in the table.

[LoriEmersonKDOT]

Thanks, jeadly,

Resetting the field maps worked for me prior to exporting a previously joined table with some records selected.  This workflow is different; is this an expected new workflow or a workaround?

I'm unable to mark your reply as a solution.

[jeadly]

It's just a workaround I noticed resulted in positive results.  Seems like there is a bug in the export form automatically reassessing the fields after joining/removing.  So sometimes the field names either do or don't have the "table.name" format (which isn't how they are named any more) resulting in nulls when the data is copied and those field names aren't found.

[LoriEmersonKDOT]

Thanks for finding the workaround!

[tuilbox]

Thanks jeadly! I won't admit how many times I've had failed attempts - but this workaround worked around for me!

[LoriEmersonKDOT]

I discovered that the bug only occurs after I perform a "Select By Attributes" on the joined tables.  If I select by clicking on a table row or selecting on the map and then exporting (after the join is removed), then the attributes in the exported table are filled with values as expected.  It's the "Select By Attributes" that uses the table.name which then doesn't reset when the join is removed.

[SepheFox_EWEB]

I am having the same issue in 3.3.5. Join a feature class to a table by global ID (one to one join--pole to joint use attachment). Examine table with joined features to verify that joined fields have appropriate attributes. Select all table rows where the feature (pole) Object ID is not null. Export selected table rows to a new table using Export Table gp tool. Now the exported table shows all of the feature Object IDs as null.

Absolutely maddening. I've tried a fresh gdb, and I've tried resetting the field map. I guess the next step is a fresh project.

[SepheFox_EWEB]

A brand new project made no difference. I also tried using Merge instead of Export Table to emulate the intersect/clip workaround someone else was using with features. Nope, still get empty Object IDs for the joined features. Ya know, I've been using Pro for a few years now--still waiting for the part where it's better than ArcMap. I think the only advantage I've noticed is it's easier to work with services.

[SepheFox_EWEB]

And now when I return to my original project the joined feature Object ID seems to be intact in the export, so I think this is actually some kind of display issue.