Zoom-to/Pan-to/Flash Selected Feature not working in ArcGIS Pro with joined table

[KateNewell1]

I have a project with a parcel feature class joined to a standalone table. 

The join works great and I also have a definition query on the joined feature class that functions as expected.  When I select a record in the attribute table and right click the record to zoom to it (or pan or flash, etc.), the entire data set flashes or it zooms to the entire extent and shows all features selected on my screen...even though only 1 record is selected in the table.  At the bottom of the table it shows that only 1 record of the 28 is selected but I can't zoom to that feature. I also can't switch the table view to see just the selected records. This seems to be because of the join.  When I take the join off, the zoom/flash/pan-to works fine and all functionality is back.  Even when I remove the definition query (with the join remaining) I still have this problem...so it appears that the join is the issue.  Has anyone else run into this issue? I really need to be able to work with the data in a joined fashion. 

[DanPatterson_Retired]

Kory Kramer‌ something further of interest

[KoryKramer]

Looks like others have tried and can't reproduce.  I tried with some data at hand and can't reproduce (if I've understood the steps correctly).

Kate Newell‌ if you do the same steps with different data do you see the same issue? 

You said that the parcel feature class and standalone table are in the same file gdb.  Can you make a copy of the parcel features, place in the same file gdb and re-test?  Same issue?  

Have you re-calculated the spatial index on the features?

Is the map using the same coordinate system as the data?

This could be a good candidate for a tech support case, but if you zip up the gdb with just the FC and table, and include a simple txt file with steps to reproduce we'll take a look.

Cheers

[KateNewell1]

Yes it is very specific to this feature class.  I have tried a join with "Keep Common" on other datasets and it works fine in PRO.

I tried a copy of this dataset and still have the issue ONLY when I try to "Keep Common".  If I Keep All Target Features for this dataset, then it is fine. 

I have no doubt its somthing funky with my feature class, but its really weird because the exact same process with exact same feature class/table works fine in ArcMap with "Keep Common".

I have rebuilt spatial indexes and the map is using the same coordinate system as feature class. 

Its definitely specific to this feature class.  

Thanks for all the ideas and troubleshooting...gotta move forward on this project so I will just join it up to the original parcel feature class from SDE and take the performance hit or "Keep All Target Features" and query out the ones that didn't join.

[MichaelVolz]

Have you tried bringing the original data from SDE into Pro?  I ask because I have specific SDE feature classes that works in ArcMap, but I cannot bring the data into Pro.  With help from ESRI technical support using open source check geometry option as opposed to ESRI check geometry option, we determined that the data had geometry issues that need to be fixed before the data can be used in Pro (SDE does not detect topology issues).  As such, it appears that Pro has higher data quality standards than ArcMap, so just something to check.

If you have already brought this data into Pro from SDE, how bad is the performance of the data?  There are several posts asking for ESRI to fix performance issues of Pro that appear to be specific to SDE.  It seems that if you work local and with file gdbs you are good to go with Pro.

[KateNewell1]

Yes the original data from SDE works but is so painfully slow that querying the feature class or table with the join on it is almost impossible.  It takes almost a minute to open the table and trying to symbolize the data is unbearable.  I'm trying to symbolize with Graduated Symbols and get the spinny-thing for about 45 seconds before the symbology window is functional on the joined SDE layer.  That is originally why I created the copy of the SDE parcel data in a file geodatabase.  Obviously something corrupt or wrong with my copy though....but I can't get over that it works in ArcMap!

I also wanted to create a report on this information...and I see now that reports are not part of PRO yet.  So, back to ArcMap it is   I'm trying to like PRO, really I am

[MichaelVolz]

Not sure if there is an idea to get reports ported over to Pro yet.  You might want to search for that in GeoNet and if you cannot find an idea for reports ported to Pro then you can create one.  You need to get this concept on ESRI's radar as there are plenty of shortcomings in Pro already, but we the users need to let ESRI know of the urgency to gets these tools in Pro so we can migrate all of our ArcMap workflows over to Pro.

[KoryKramer]

https://community.esri.com/docs/DOC-11989-arcgis-pro-roadmap-june-2018 Reports are on the Pro roadmap and we'll see them rollout in 2.3.

[MichaelVolz]

Are you able to work with this SDE data directly in ArcMap currently or do you also export the SDE data to a file gdb there as well?  If you currently don't need to export SDE data to a file gdb in ArcMap, it seems ridiculous that what is touted as better software (Pro), forces you to copy the data to file gdb format due to performance issues.  This is an item that I would work on with technical support, as there seems to be a common thread of performance issues in Pro that really need to be reviewed and hopefully resolved whether that is a specific org system architecture fix or bug(s) fix to the software by ESRI.

[ThomasColson]

Kate Newell I have tried to repro your issue with many combinations of join types,rules, and join fields (e.g text, numeric, GUID) and definition queries, and cannot repro in 2.2. While you've figure out a workaround, I'd love to see a zip file of your data (if you can share it). I support a number of folks that spend all day doing complex joins, and am nervous that this would effect them (if it is indeed due to some quirk in the data, e.g. the behavior occurs if the number 9 appears after the number 5 in the fifth row of the joined table after 2 PM on odd days of the week). If you can't share your data, how about a blank schema?

[ThomasColson]

On that note, how is the FGDB being created? That might have some bearing...if you create it in arc versus Pro....