Error Opening Table in Pro - "Failed to retrieve a page of rows"

BenVan_Kesteren1 · ‎10-11-2018

Hey,

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?

BenVan_Kesteren1 · ‎12-12-2018

Hey,

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.

JonathanFarmer_oldaccount · ‎12-13-2018

Thanks for letting me know Ben! Glad they were able to sort to the bottom of it. I believe the way you've described how things work in Pro is the way they designed it to work. That being said, a better error message could be helpful.

You can always ask Esri Austrailia to speak with our Support team here and log an enhancement to Pro if you like on this issue.

Jonathan

MatthewDriscoll · ‎02-02-2021

Same thing happens with SQL. We even assigned the primary key, added an objectid field, added unique numbers, and every time it gets put into a Pro Map it switches the field primary key/objectid to the first integer column it finds. I agree this should be a bug as it is still happening years later.

MichaelVolz · ‎01-02-2019

Ben:

Is this data being brought into Pro as a Query Layer?

BenVan_Kesteren1 · ‎01-06-2019

Hi Michael,

It is a view that lives within the Authority DB.

So no it is not a Query Layer as such.

JonathanFarmer_oldaccount · ‎12-11-2018

Ben,

Couple more pieces of information I remembered after posting.

I've run into this exact issue most often with these 2 problems:

The column headers have spaces, invalid characters, unsupported characters. See more below. But looking at your video, I think you are OK here.
1. FAQ: What characters should not be used in ArcGIS for field names and table names?
The field data types are not supported in ArcGIS. Since you said this was a non-spatial database table, this is also something to look at.
1. DBMS data types supported in ArcGIS—Help | ArcGIS Desktop

One thing that does stand out from that video. Do you see in ArcMap where the table is in the DBO schema? So it says "authlive.dbo.tablename". When you go to add the table in Pro, I also see the same schema. But when you actually add the table to the TOC, it comes in as "authlive."Albury/Benva".tablename".

I just tested with Pro 2.2.4 on my end and all tables in the DBO schema come in under the DBO schema just like I expect. So is this happening with all tables in the DBO schema in Pro for you? Or just this one? Might be worth taking a closer look as to why this is happening.

Jonathan

JoeFlannery · ‎09-16-2020

Jonathan:
Item #1 solved my problem. The alias name for one of my fields had commas. I removed the commas and this issue no longer persists.

Thank you!

Anonymous User · ‎08-13-2019

I am seeing this issue with Pro v 2.4 (as well as v2.3.2), when trying to open a view from an Oracle database. I cannot open the table to see the data, because it throws the exception mentioned in this thread. When I look at the table design, I am noticing that Pro is somehow assigning the 'ObjectID' data type to a field that does not contain unique values. This seems to me that Pro is interpreting this table incorrectly. I am able to open the table in ArcMap 10.6.1 without issue. There is not much that can be done on the DB side to this as this view is simply derived from a few tables that are already in production. Please keep in mind this Oracle database is the backend of our main permitting system which I have used many times for GIS automation--it's just this one particular view that I can't work with. I think it's a bug in Pro

MichaelVolz · ‎08-13-2019

Evan:

Can you provide the steps you take to add the view to Pro? I ask because I thought that you have to add a view as a Query Layer and this process asks you which field to use as the ObjectID field so you have control over the field that Pro uses for the unique id field.

Anonymous User · ‎08-13-2019

I was able to add the table successfully this way Michael, thanks. Historically I was just able to create the database connection to Oracle, find the view, add it to the map and open it in Pro. When I added it as a query layer I got the option to pick which field contains unique values, which skips Pro trying do this by itself.