Delete Raster Dataset From Command Line

[HenWagner]

Hi,
I guess it's a simple one:
I'm trying to delete a Raster Dataset from SDE via the command line.
I've seen sderaster delete, sderaster drop and sdelayer delete- is it one of those? If so, how do I use it?

TIA
Hen.

[VinceAngelo]

None of the above.  A raster dataset is a geodatabase entity -- it must be deleted via
ArcGIS tools.  The only command-line deletion option is through Python.

- V

[HenWagner]

Well, I guess I'll have to learn it in the hard way.
I tried:

sderaster �??o delete

and this was thrown:

SE_stream_execute (-1002) No rows were deleted

so I tried:

Sderaster �??o drop

[ATTACH]7874[/ATTACH]
and it looks OK from ArcCatalog, and in the SQL the aux-blk-ras-bnd tables are gone but the business table is still there.

Can I delete it manually?

[VinceAngelo]

Unfortunately, you have corrupted your geodatabase data dictionary.  Even if you used the
safest command-line option available ('sdetable -o delete') you would still have corrupted
metadata (no binary in $SDEHOME/bin is geodatabase aware).

You may be able to use ArcCatalog to delete the remaining feature class fragments, though
you might need to recreate the raster column before a GUI delete would be fully successful
(Tech Support would be a great resource at this point).

The exact steps for SQL maintenance to clear the corruption depend on the version of ArcSDE
in use, and, if necessary, are better executed under the close supervision of Tech Support.

- V

[HenWagner]

Now I can still see the 'deleted' raster's footprint in the tables:
[SDE_table_registry]
[GDB_OBJECTCLASSES]
[SDE_layers]
Should i see it somewhere else?

The technical support advised me to leave it this way (corrupted) and avoid using the name of the deleted raster.

Thanks for the assistance.

[VinceAngelo]

It's hard to believe that Esri Tech Support would recommend that.  The fix is simple
to do, but not at all simple to explain.  Leaving your database like this will prevent
application of service packs or upgrades.  Please follow up with Esri Tech Support.

- V

[JakeSkinner]

I use to work in Tech Support and came across this issue quite a few times.  Here are queries that you can run that will remove all the entries from the SDE, GDB, and base tables.  These queries should only be run AFTER you create a database backup.  ESRI rarely recommends editing tables directly within the geodatabase, but this is the only solution that I've been able to find in these situations.  As vangelo recommended, I would follow up with Tech Support before running these queries. 

Also, the below queries are for ArcSDE 9.x for SQL Server.

use <database> 
select rastercolumn_id from sde.sde_raster_columns where table_name = '[table_name]' 

select ID from sde.gdb_objectclasses where name = '[table_name]' 

select layer_id from sde.sde_layers where table_name = '[table_name]' 


--Recall the three numbers from these queries. Then run the following queries: 


use <database> 
delete from sde.sde_table_registry where table_name = '[table_name]' 

delete from sde.sde_layers where table_name = '[table_name]' 

delete from sde.gdb_rastercatalogs where objectclassid = [number from above sde.sde_raster_columns query]

delete from sde.gdb_objectclasses where Name = '[table_name]' 

delete from sde.sde_raster_columns where table_name = '[table_name]' 

delete from sde.sde_geometry_columns where f_table_name = '[table_name]' 

DROP TABLE <owner>.<table_name> 

DROP TABLE <owner>.sde_aux_<# from above rastercolumn_id query> 

DROP TABLE <owner>.sde_bnd_<#> 

DROP TABLE <owner>.sde_blk_<#> 

DROP TABLE <owner>.sde_ras_<#> 

DROP TABLE <owner>.f[number from above sde_layers query] 

DROP TABLE <owner>.s[number from above sde_layers query]

[VinceAngelo]

I much prefer the "put stuff back the way it was, then delete it" approach to hacking the
geodatabase dictionary.  It's just one 'sderaster -o add'  to fix an inopportune '-o drop'
(and you don't even need to get the parameters correct, just to do enough that Catalog
will able to clean up the whole tree).

- V