-1

I am attempting to collapse three separate (non-spatial) tables with related records into one. I have used the Make Query Table tool to do this (I think) by joining them based on a shared field, however I am now having trouble writing the runtime table view output as a stored table in the GDB. I've tried multiple options- Table to Table, Table Select, Copy Rows- all of which seem to have trouble. I'm not receiving any errors, just a hanging process each time. ArcCatalog will show a processing window which seems to run indefinitely. I've tried running the process overnight (18 hrs) with the same result. I've also tried using a query statement within the Query Table tool to use a limited number of records to try and identify if it is the amount of data; with the same result.

I'm not sure what visual information will assist so I haven't uploaded anything, but please let me know what information would be useful in the resolution of this issue.

  1. I'm not entirely sure what types of GDB there are but at a guess I would say a File Geodatabase
  2. Table 1 contains 147184 rows; Table 2 contains 3308 rows; Table 3 contains 3416 rows
  3. Row count of the output would be that of table 1 as the largest table
  4. Tables are not currently joined or indexed
  5. The output required is a File GeoDataBase table which will be stored in the file path specified after the process has ended rather than just in runtime memory.

closed as unclear what you're asking by PolyGeo Apr 30 at 21:59

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Please edit the question to contain more information: What type of geodatabase? How many rows in each of the tables? The Cartesian product of the join (row count). The join columns and the indexes in place. What you mean by "to memory" when your target is a table. – Vince Feb 3 '16 at 1:45
  • 1. I'm not entirely sure what types of GDB there are but at a guess I would say a File GeoDataBase? 2. Table 1 contains 147184 rows; Table 2 contains 3308 rows; Table 3 contains 3416 rows 3. Row count of the output would be that of table 1 as the largest table 4. Tables are not currently joined or indexed 5. The output required is a File GeoDataBase table which will be stored in the file path specified after the process has ended rather than just in runtime memory. Hope that makes some sense! – RobinHorner Feb 3 '16 at 1:51
  • 1
    Please always edit the question in response to requests for clarification. Please take the Tour to better understand how things work here at GIS SE. Failure to create indexes is an almost unpardonable sin when doing database joins, made all the more heinous by not even having a database. Please remove the words "to memory" from the title because it has nothing to do with a file-based output table. – Vince Feb 3 '16 at 2:24
  • 2
    "Memory" is absolutely the wrong term. "Memory" does not persist. "Memory" is the least memorable part of a computer. If you want a computer to remember something it must be written to disk. Memory is only the weigh-station on the way to disk, where individual rows are assembled before they are saved. You want to write a query to disk. – Vince Feb 3 '16 at 3:50
  • 1
    It will be extremely difficult to write an understandable answer to this question without a great deal of basic database theory. A query is a set of rules for matching rows. By failing to build indexes, each of your supplemental tables must be read in their entirety, for each input row, just to make sure nothing is missing. Reading a 3k row table 150k times is a huge waste of computing resources (and it's being done twice). You must build indexes on the join columns if you want the query to finish before the new year arrives. – Vince Feb 3 '16 at 3:58
1

Problem resolved by using alternate method arisen from insightful discussion with Vince in comments section of question.

Rather than using Make Query Table tool, which was struggling with the large amount of data that it needed to process, I used two separate Join tools- joining Table 1 to Table 2 and the output of this to Table 3- and then processed the result of this using the Table to Table tool.

Not the answer you're looking for? Browse other questions tagged or ask your own question.