Solved! Go to Solution.
You can "DROP USER SDE CASCADE" IF AND ONLY IF no other user has a table which uses
one of the SDE user's object types (e.g., no tables with an SDE.ST_GEOMETRY column).
If you drop the SDE user while some user references SDE-owned objects, it will cause the
DROP to partially fail, and set up a referential integrity issue within the database instance,
where further attempts to DROP will fail due to missing objects (and attempts to create
a new SDE login will fail due to conflicting objects,...). The only solution to this is dropping
the database instance and restoring from backup.
The safest procedure would be to drop all the users that had SDE.ST_GEOMETRY at any time,
then recreate the user(s) and restore the non-ST_GEOMETRY table(s).
- V
You can "DROP USER SDE CASCADE" IF AND ONLY IF no other user has a table which uses
one of the SDE user's object types (e.g., no tables with an SDE.ST_GEOMETRY column).
If you drop the SDE user while some user references SDE-owned objects, it will cause the
DROP to partially fail, and set up a referential integrity issue within the database instance,
where further attempts to DROP will fail due to missing objects (and attempts to create
a new SDE login will fail due to conflicting objects,...). The only solution to this is dropping
the database instance and restoring from backup.
The safest procedure would be to drop all the users that had SDE.ST_GEOMETRY at any time,
then recreate the user(s) and restore the non-ST_GEOMETRY table(s).
- V