IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New I generally do it the other way.
I keep the source to generate the stored procedures, tables, views, functions, etc... in the version control system. The scripts are much cleaner and easier to control than the auto-generated variety. Too many SQL Server DBA's tend to use the Server itself as the code repository (a bad idea from a maintenance perspective).

Just one note if you are going to generate the scripts => remember to drop the objects in the reverse order that you created them - otherwise you run into object dependency problems (e.g. can't delete a table that is currently acting as a FK). I've noticed in the past that the auto-generated scripts from SQLServer did not always maintain the correct order of drop and create - meaning you had a fairly arduous task trying to get things manually in the right order. Perhaps they've fixed that on the later versions (it's been awhile since I've used the feature).


New No experience with this problem in MS-SQL, but
can't you "drop cascade" to take care of any dependancies?

Never mind. Oracle great, SQL/Server sucks.
You need to exec sp_depends and drop the results of that. Of course, for each of those, you would need to do the same thing.

Recursion at it finest.
     MS SQL Server - Generate Scripts programmatically? - (kmself) - (4)
         Define not run - (broomberg)
         I generally do it the other way. - (ChrisR) - (1)
             No experience with this problem in MS-SQL, but - (broomberg)
         An error list might be helpful. - (mmoffitt)

Hey, they have color-coded detours here.
119 ms