1

Here is the very simple code I'm running:

arcpy.management.MakeTableView(roads_source, roads_view)
arcpy.management.CopyRows(roads_view, roads_table) # This creates the table
  • roads_source is an attribute table for a feature class with 60,000+ rows stored in an SDE. This is stored on an Oracle server.
  • roads_table is (supposed to be) a simple GDB table stored locally.

When I create the Table View, all rows appear successfully. When I copy that Table View to the new table, only a random number somewhere just over 3,000 copy over. Sometimes less.

I have also tried using CopyFeatures to copy the whole feature class into my GDB and then making a table from it and Append to a blank table I manually created, but neither worked. I was able to get between 6-7,000 rows when using the former method, weirdly.

Using Copy(roads_source, roads_table) returns

ERROR 000260: Underlying DBMS error[ORA-21500: internal error code, arguments: [%s], [%s], [%s], [%s], [%s], [%s], [%s], [%s]].

When I try and copy the rows directly from the source table, skipping the Table View, I get

error 000210: Cannot create output roads_table.

I have no active selections or definition queries. I have no idea what to do, or why it's not working.

Importantly: this issue only occurs in ArcGIS Pro 3.0.1. I have tested it in ArcMap 10.8.1 using the exact same methods, and CopyRows successfully retrieves all rows on first attempt (as it should).

4
  • That is weird. If you're copying the whole table perhaps arcpy.management.Copy(roads_source,roads_table) might work better. Is there a reason you're creating a table view? as written the view seems a little pointless. Commented Feb 16, 2023 at 0:23
  • @Michael Stimson I also tried that, and just tried again, and it gives ERROR 000260: Underlying DBMS error[ORA-21500: internal error code, arguments: [%s], [%s], [%s], [%s], [%s], [%s], [%s], [%s]]. I agree that the table view is unnecessary and was planning to skip it, i'm actually rewriting a model builder into a script and wanted to make sure it was all working before cleaning up, then I noticed this happening.
    – panta_ray
    Commented Feb 16, 2023 at 0:58
  • 3
    See this support.esri.com/en/technical-article/000009667 for an explaination of the Oracle error and some possible workarounds Commented Feb 16, 2023 at 1:22
  • @MarkBryant I did come across that but I don't think that's the reason for my actual issue i.e. not being able to copy all of the rows out. That error is being thrown only under specific circumstances e.g. using Copy. I have added some details to my question, notably that this only happens in ArcGIS Pro, ArcMap is fine.
    – panta_ray
    Commented Mar 23, 2023 at 5:52

1 Answer 1

1

I have contacted Esri Support and they believe it is because the version of Oracle required for ArcGIS 3.0 is Oracle 12c R1 (64 bit) 12.1.0.2, as stated here. The version my department uses is below that, but is supported by ArcMap 10.8.1 and ArcGIS Pro versions prior to 2.7, as stated here. This is why it worked correctly in ArcMap, presumably.

Additionally the SDE version is, to quote the support technician, "very old" at 10.1.

So it appears this is a case of outdated and unsupported technology showing its cracks. I have no control over any of these aspects so cannot update to confirm, but there is a major overhaul coming in a couple months, so I will assume it will work correctly then. There is not really any other explanation, a very strange quirk indeed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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