I have been able to add a table using sql server in ArcMap Desktop for some time, I am now trying to read the table within an ArcGIS Pro v2.2.3 Map, but I keep getting the error Failed to retrieve a page of rows and I am unsure why this is happening. The layer adds to the map fine (seems to display all 20,000+ polygons), its just when I try to view the Attribute Table that this error appears.
Note it is able to load the column headers in the background, so I am assuming it is a data issue.
The table I am trying to add is a view from a Civica Authority DB (MSSQL 2014 12.0.5207.0), so its not spatially enabled at all.
Has anyone been able to overcome this issue before? Or even know a way for me to troubleshoot the cause?
Solved! Go to Solution.
So today I have spoken with ESRI Australia Support team, and they have gotten to the bottom of the issue.
I had not noticed that my View U_PROPERTIES_ASSESSMENTS did not have a unique field being used for its primary key. There were several rows that were duplicated, once these rows were filtered out of the view, it works fine in both ArcMap and ArcPro.
So what appears to be the difference between ArcMap and Pro is that if this view is added to Desktop, this software finds the first instance of each unique primary key, and keeps this row, after this it ignores any duplicate primary, and the user is none-the-wiser about the duplicated being ignored.
But what is happening with ArcPro is that pro will draw all the shapes on the map, all 20,000+, but it refuses to load the table due to a column being used as a primary key which contains duplicate values. This is not handled very well in comparison to ArcMap so I think it should be marked as a bug in this instance.
That being said, I also think ArcMap are not being warned that the view being used does not contain the full list of features.
The bottoms line (TLDR), I needed to make my primary key column unique for ArcPro to accept my data.
Cheers for all your comments.
I get the same issue, though loading a table from Oracle.
I see data when the table opens.
The table display window crashes if I scroll a few pages or try to sort.
ArcPro 2.2.4 and Oracle 220.127.116.11
ArcGIS Pro will throw this error if there are records in the table that have invalid geometry or are invalid in some other way. If this always happens at the same spot, it may be worth checking to see if this is the case in your situation.
You can't run a Check Geometry on an Enterprise geodatabase but you can with a File geodatabase. It may be worth exporting this feature class out to a FGDB and running Check Geometry on it just to make sure. I don't know that this is the issue but it is where I would focus.
Is there a chance that the export process to a file gdb will fix this error?
So if no errors are detected in the file gdb, then the feature class could be imported back into SDE from the file gdb (Not overwriting current feature class until problem is fouind) and it would then work as expected.
Yes, that is possible as well. Enterprise geodatabases automatically check the validity of each geometry when uploaded but they don't actively search out and fix invalid geometry once the data is loaded in.
The part of your post that sticks out to me is "The table I am trying to add is a view from a Civica Authority DB...". What is the actual DBMS you are using here? What version? Also, what version of Pro?
We have had some bugs in Pro in the past with this same error but they are usually pretty specific to a certain workflow or setup.
I just tested with that exact setup and don't see the issue. I tested both with a non-spatial table and a feature class, both with over 20,000 records each.
I'm still wondering if this may have something to do with how Pro is reading the owner of the table as I mentioned in my second post yesterday. Can you actually create a new connection to this database in the Catalog pane (right click Databases > New Database Connection) and see if the same behavior occurs? What user are you using to connect to the database? You might try a different user as well.