Select to view content in your preferred language

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

192
15
Tuesday
DylanHinton
New Contributor III

 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

0 Kudos
15 Replies
MichaelVolz
Esteemed Contributor

Dylan:

How did you ensure that your field types are compatible with 3.1 and earlier versions?

0 Kudos
DylanHinton
New Contributor III

Under Projects>Map and Scene>Add Layers and Tables>"Use field types that are compatible with ArcGIS Pro 3.1..." I just keep that box checked due to some issues we were having a couple of months ago with one of our field types breaking 

0 Kudos
MichaelVolz
Esteemed Contributor

Do you think the new data types are being added with the tabular data that is being joined to your SDE data, even though you have that setting checked?

Have you verified that the data is still in Pro 3.1 compatible format where it is not using the high precision data field type or big integer field type (I would suggest seeing if you can load the table into ArcMap as a test)?

0 Kudos
DylanHinton
New Contributor III

I can bring in both the feature layer and the table and perform the join and export successfully with no issues in ArcMap. 

0 Kudos
MichaelVolz
Esteemed Contributor

So I am doing similar automated  operations using python where I am trying to revert to Pro 3.1 field types using useCompatibleFieldTypes, but this code just gets ignored.

I am wondering if you can bring the table into a file gdb in Pro 3.3.1 with the Pro 3.1 field types checked and then see if you can view that file gdb table in ArcMap after it was initially created in Pro 3.3.1.

0 Kudos
DylanHinton
New Contributor III

Hi Michael, so I tried viewing the attribute field for the feature after performing the export in Pro and saving it to a local gdb. Unfortunately, its still showing the null values for me. 

0 Kudos
Bud
by
Honored Contributor

Is your join one-to-many? If the answer is no, are you 100% sure?

I ask because one-to-many joins in ArcGIS Pro are pretty buggy. Is ArcGIS Pro the right tool for tabular/join-based geodatabase analysis?

Possibly related:

Export join to FGDB: Join table ID field is null

Join with definition query: Export has more rows than input (definition query is ignored)

0 Kudos
Bud
by
Honored Contributor

If your join is one-to-many, you could try creating a one-to-one join instead and see if you have the same issue. Pro now has the option to choose the join type: Choose if join will be one-to-first or 1:Many

You could also try removing any definition queries to see if it behaves differently.

0 Kudos
Bud
by
Honored Contributor

Does the Join Field geoprocessing tool (exports a copy FC) behave the same way as Add Join (dynamic)?

0 Kudos