I've become a believer in never have developers write SPs by hand (in an editor). Instead, we write programs (in the language of the app) that construct the SPs (as strings) and cause them to be created. This lets you have SPs that trivially do things like changing the datatypes of parameters or local variables to match the defn of the database. (For example, if a column goes from varchar(20) to varchar(25) and the SP variable to manipulate it doesn't change, data could get corrupted.)
It also makes it easier to do things that are appropriate in a "code for sale" environment -- the code that writes the SP can consult application settings to write an SP that works for the current set of application settings, rather than having to figure out how the SP can get the setting and change its behavior "on the fly" each time it runs. Any time the schema changes, or an application settings changes, or you install a new version (etc), you just run your "create stored procs" method and everything is fine. At 09:15 PM 9/21/2005, Ben Kloosterman wrote (in part) >In environments where the SQL is managed by the developers they >are a hindrance to the operators who have to add the scrips to >production each time they change. > >Regards, > > Ben J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
