Re-writing all those existing Stored Procs sounds like it would be a very time-consuming process. If you would be doing it only to reduce the number of Procs, I'd say why bother? Or does it really become problematic to remember which Procs need updating when a field gets added? Even so, I'm with Kevin on this, the idea of automating the process somehow.
~~Bonnie
>What is project K2?
>
>The problem is that we are oftentimes adding field to the database, and instead of having to update every SPROC I would only like to update certain SPROCs.
>
>When I create something start to finish, I usually use the approach you mention and I try to keep things as lean as possible so I don't have this same problem. The problem is that I am maintaining a huge POS (not point of sale) system that was built by people who had no business building it.
>
>>Hey, Mike,
>>
>>What I've done, and what I believe others have done frome time to time, is generate their stored procs.
>>
>>So if you have many stored procs that follow the same pattern...
>>
>>GetAllCostCenters
>>GetCostCenterByPK
>>GetCostCenterBy
>>GetActiveCostCenters
>>
>>GetAllCustomers
>>GetCutomersByPK
>>GetCutomersBy
>>GetActiveCustomers
>>
>>etc., etc.
>>
>>You can generate them from either a script, or even from a .NET app.
>>
>>As far as having fewer stored procs with many parms....you know what...I really thing it's the old "six, and one half dozen the other"
>>
>>My two cents...
