You can add new params to procs in sql server without breaking existing code as long as you give the new params default values.
-----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Frans Bouma Sent: Wednesday, September 21, 2005 11:29 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Business logic > In environments with lots of applications accessing the > same database they also add more value. (Though this can > backfire in case of testing changes to stored procs ) This is IMHO not true. The simple reason for this is that once you have a proc which is used by multiple apps, you can't change it if it needs a new parameter/different type/updated resultset, because it will break a lot of apps, and perhaps these aren't written in-house. So what do you do? You add a new one. After a couple of years, how do you think your db will look like? > In Environments with good DBA's responsible for > managing the stored procs they are easier to maintain. The procs maybe, but that's just half of the story. How about the code calling the procs? Ever written an n-tier application with procs? So when a proc had to change, you not only had to change the proc but also the calling code? The proc is then managed by the DBA, but the calling code isn't. What if the DBA is not available that day? Or has other ideas about the interface / signature of the proc? Not fun. It will slow down development for no real reason. > 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. True. FB =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
