I have searched high and low and for some reason this functionality does not seem to exist? I have a SQL Server database with many tables I have created myself (in SQL) and made the mistake of enabling a geodatabase on that database. Now I have all these extra tables and stored procedures on a database I don't want. Restoring from a backup, rolling back, etc, are not options. I need something that will delete all tables, views, stored procedures, everything, that is created when a geodatabase is installed on a SQL database. Is this possible?
Why not just do it through sql server manager?
Is there a list of everything created? Otherwise I'm going through all tables, views, programmability, checking everything one at a time to see if it's part of the geodatabase or not. This was added to a database with a lot of tables and views already.
Probably in TransAct SQL. I don't know off hand.
Easiest way is through SQL Server Management console. Right click on the database you want to delete, select DELETE. Follow through the command prompts (Yes, I'm really really sure I want to delete the database.) and you are set.
You're misunderstanding, the problem is I have a SQL database that is full of tables and views (user created) and then it was geodatabase enabled. So I have a lot of objects in my database that I need to keep and use and a bunch of stuff that was added from the geodatabase that needs to be deleted. I definitely do not want to delete the database.
Ah - my bad. You may still be better off porting the tables and views that you want to save to a new database. My suggestion would be to use a data compare utility like RedGate's SQL Compare. Compare your target database with an empty geodatabase and copy the tables that don't match (after you have removed the new sde tables you added) to your new database. SQL Compare writes out a script that you could modify to point at your new database. Hope that helps.
Hi Dustin,
There is no tool to do this, I would not recommend removing the geodatabase objects (repository tables, stored procedures, triggers, etc...) from the database, especially if SDE or another user in the geodatabase owns any objects. If this occurred it could corrupt the database as a whole.
I think the easiest and safest way it the process that Alex P. referenced:
"You may still be better off porting the tables and views that you want to save to a new database."
Hope this helps...
-George