Since TBL2SDE no longer exists (we're running a 64-bit server and ArcGIS 10 doesn't include that executable on a 64-bit installation) I've been using the Table to Table script in ArcToolbox to copy some Info and DBF tables to SqlServer. This has been working fine but I ran into a problem today where it simply does not allow me to copy any tables.

When I run the command, it returns:

ERROR 999999: Error executing function.
Item with the same path name already exists.
DBMS table not found [Microsoft SQL Server Native Client 10.0: Invalid object name 'gismo.RFCGIS.aocondo'.] [gismo.RFCGIS.aocondo][STATE_ID = 19653]
DBMS table not found [Microsoft SQL Server Native Client 10.0: Invalid object name 'gismo.RFCGIS.aocondo'.] [gismo.RFCGIS.aocondo][STATE_ID = 19653]
Failed to execute (TableToTable).

I use sdetable -o delete to remove the tables and that, too, has been working fine, so I don't think there's a problem with SDE. I've also checked to see if there are any remnants of the table names in sde_table_registry, sde_layers, sde_column_registry, and even gdb_items (though the tables should not have been registered with the GDB). I also checked against various owners (dbo, rfcgis, and sde) to see if it was a problem with the file existing but owned by a different user and that's not it either. Oh, and it does work when copying from DBF to DBF, so it's not contention on the source file. I've run out of ideas and hope someone can suggest another direction to take with this.

  • what OS are you running? – Mapperz Feb 22 '11 at 2:02
  • @Mapperz Windows Server 2003. – Michael Todd Feb 22 '11 at 4:52
  • Can you make a copy of a table that's already in arcsde? – Kirk Kuykendall Feb 22 '11 at 17:02
  • @Kirk Yes, and I can even copy the tables I want to different names; the tool only complains when I use the original names of the files (i.e. aoextract to aoextractTEMP works, but not aoextract to aoextract). – Michael Todd Feb 22 '11 at 17:39

Several of the ArcSDE administration commands are built with ArcInfo Workstation technology. Since ArcInfo Workstation is not supported on HP Itanium, Linux, and Windows 64-bit operating systems (OS), certain administration commands are not available for ArcSDE 64-bit. These commands include the following:

cov2sde sde2cov sde2shp sde2tbl shp2sde tbl2sde shpinfo

The tasks these commands perform can be accomplished through ArcGIS Desktop. Alternatively, if you must use these commands (for example, in scripts), you can install ArcSDE 32-bit on a client machine that is using a supported 32-bit OS and utilize these commands from the client machine.

| improve this answer | |
  • Oh, I know about the workaround. I'm more curious as to why I can't get a table to table copy done. It's annoying but par for the course that "old" tools don't work, I just want the current tools to do their job without breaking. – Michael Todd Feb 22 '11 at 4:53

I ran into the same issue in version 10.2.0 with Oracle 11g as the back end. The data had been copied/upgraded from a 9.3.1 db and I was getting errors running any scripted process which attempted to overwrite the existing feature class despite having the overwriteOutput flag set to True. I tried deleting the table from the ArcCatalog console and it appeared to have been deleted -- couldn't see it in ArcCatalog or find the table in the DBMS but still got the "already exists" message. I found one row in GDB_ITEMS that referenced the table and deleted it with SQL -- no ill effects and can now add the new version.

| improve this answer | |

There turned out to be some remnants in gdb_items after all (I didn't perform the SQL query correctly the first time I tried this which is how I missed it).

Although the tables did not exist in any other place (either physically in the database or in the table or column registry), for whatever reason they were not removed from sde.gdb_items when I ran sdetable -o delete. I deleted the rows that contained the table name in the Name column in gdb_items and the script worked perfectly thereafter.

| improve this answer | |
  • Micahel, I am running into the same thing and have found the residual table records in my sde.gdb_items table. I hesitate to rip those records out using SQL because the threat of corrupting something. Are you sure it is safe? Is there a more orthodox approach to clear these out? sde_Table -o delete did not find it or any "metadata" to delete. Thanks. – Jim Landwehr Jan 31 '14 at 20:40
  • Bit late to respond but I missed this when you posted. Yes, I think it's safe AS LONG AS YOU'RE CAREFUL. It worked for me and it worked for @user172974. Just make sure that you're deleting the right row and only the right row. – Michael Todd Apr 16 '14 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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