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

[DylanHinton]

Hi Bud, so I'm joining one-to-one with no issues. My join is successful and I can see the data when I open up the input's attribute fields. Once I export the feature, however, the exported table nulls out the join table's values. Pro 3.3 allows me to export the same table join with another feature layer though. So, I'm guessing its something to do with this specific feature layer

[Bud]

Sounds similar to what I had in BUG-000146098

[DylanHinton]

Yep that sounds exactly it. For whatever reason, it just doesn't want to export the join between this one specific feature layer and the table. I may have to just put a ticket in with ESRI and go from there

[MichaelVolz]

The bug was supposedly fixed at Pro 3.0 as it was initially reported at Pro 2.9.1.

[DylanHinton]

It wasn't an in issue in 3.2.2 for me, but I updated to 3.3.1 and now its a problem. I did not change my workflow and it just doesn't like keeping exported join values for whatever reason

[Bud]

Sometimes, there are "regression bugs" in Pro. An issue was fixed in a previous version, but then the devs made a mistake and the issue re-appears in a newer version. I've seen that a handful of times.

[JeremyLyman]

I just experienced this today, except that it was exporting null records after I REMOVED the join from the features.  I started poking around in the Export Features field map and found that it was not updating the expected fields when joins were added or removed. (not sure I've found any consistent behavior) But I think if I open the edit field window and reset the field map then it uses the current fields.

[Bud]

What version of Pro? What kind of geodatabase? For example, Oracle 18c 10.7.1 enterprise geodatabase.

[JeremyLyman]

We're newly updated to 3.3.1 Pro and I was keeping it simple with a shapefile joined to .csv exporting to a local File Geodatabase.

[Paul_C_Anderson]

I was just having a similar issue today- I joined a table to a feature class and was trying to save the result as my new working layer. I kept getting null values, or "0" values in one case. Weird thing was, after goofing around with it for an hour, I was able to get it completed successfully when I created a fresh project on my local drive, copied the layer and table to the new project and  completed it all locally with no issues . 

I have had other performance issues solved by moving everything to the local machine, but this would be suboptimal long term because I work a split in-office / remote schedule and use two different machines.