Select to view content in your preferred language

Query not returning all records

3497
12
03-08-2017 12:17 PM
TychoGranville
Frequent Contributor

I am working with ESRI tech support on this, I thought I would check with the community simultaneously. This is a known (and open) bug in desktop from 10.1 on. This just started happening to us (we first noticed it this morning), none of our data structures or procedures have changed in some time.

The FC's are in a File GeoDB. This happens on multiple machines using both 10.5 and 10.2 (we have one user with a 32 bit machine so they won't be able to upgrade for a while).

Basically, copy–paste a selected set from the table view to Excel does not select all the records.

For example:

Select more than 2048 features in FC (does not matter if it has joined or related tables or not) --> copy selected features in table view --> paste into Excel.
Result: 2048 records pasted into the spreadsheet (always returns 2048 if any number greater then that selected)

These permutations work –


Select > 2048 features in FC (does not matter if it has joined or related tables or not) --> copy selected features in table view --> sort (by any field) --> paste into Excel.
Result: all records pasted into spreadsheet

Select > 2048 features in FC (does not matter if it has joined or related tables or not) --> export from table view to DBF --> open in Excel.
Result: all records pasted into spreadsheet

Selecting and copy/pasting from a shapefile works correctly.

Not all of my staff are (necessarily) sophisticated enough to figure out/consistently use the workarounds, and we are not going back to shape files. Has anyone else experienced this, and did you have any luck fixing it?

Thanks,

Tycho

Tags (4)
0 Kudos
12 Replies
Lake_Worth_BeachAdmin
Frequent Contributor

there is a data conversion.... Table -> Excel. Give that a try.

0 Kudos
JoeBorgione
MVP Emeritus

My staff will not be able to figure out a new tool. They are used to going straight from copy selection in Arc to pasting directly into Excel.

Sorry if I sound a bit short, but it's 2017;  data and work flows are constantly in a state of flux.  I gotta go with the Tech Support response:  People need to adapt to this changing enviroment and accept the challenge of learning something new.  I know it's tough, but it is what it is.

 

Years ago (As in the ArcInfo days) I got into a rather heated discussion with the director of a department:  he posed the question "Can't you make it easier?"  My response was "Can't your people think harder?"   A few years before that while in college, hand held calculators were just hitting the scene.  A group of us approached our Calculus Professor and asked if we could use them in class.  He responded with a pearl of wisdom I chose never to forget: "Sure, you can use them.  But you still need to learn the calculus.  Don't become a slave to a machine".  I think of him eveytime I pass someone on the freeway while they are texting....

Google "Who Moved My Cheese Free PDF" .  There is a Google Docs copy of it floating around.  This should be required reading for anyone in the database, GIS, IS or related fields; especially those who fear change...

That should just about do it....
TychoGranville
Frequent Contributor

I will have to disagree with you on that one.

I view GIS as being a tool for line staff to use. The guts of how it works should be invisible to staff. I want them to be concentrating on their primary work area (planning, tax assessment, etc.) and not have to spend time trying to figure out how these tools work. The information I provide should fit easily into their workflow, not mine. I don't know how to write staff reports, I don't expect them to know how to write queries against GeoDatabase tables.

(We do have staff who do analysis against our raw data, I just don't expect people to have to do that in order to do their jobs)

0 Kudos