0

I want to create one and the same stored procedure for multiple (even all) databases on my SQL Server 2008.

Can i do it at once or should I create it in asp.net project reference database separately?

please help me.....

vijay
  • 58
  • 5

2 Answers2

2

This question has been asked multiple times already on SO, but interestingly there seems to be no consensus about the best answer. So here is a summary of the main options various people have suggested (in no special order):

  1. Put it in the master database with an sp_ prefix so that SQL Server looks for it there first
  2. Put it in the model database, so it is automatically added to all new DBs
  3. Create a database only for 'global' procedures (and other objects) and call them using three-part naming
  4. As 3, but create synonyms in other databases so you don't need the three-part naming
  5. Use commercial or self-developed tools to manage deployment to multiple databases
  6. As 5, but deploy to one database, then diff the databases and apply the diff script to deploy to other databases

In my opinion, 1 is a non-starter because Microsoft explicitly says you should not create objects in the master database. 2 sounds good but in practice databases are restored or copied more often than created from scratch (YMMV), so using model is unreliable.

3 and 4 are good for tables and views, but execution context can be a problem for stored procedures and functions. But this depends on the logic in the procedures and it may be workable in your case.

But 1-4 all have the potential problem that if you only have one object, you only have one version of that object, and it's often useful to have different versions available in different DBs, for testing or just for different customers.

5 and 6 are variations on the same theme and I personally find this is the best approach because deployment is a problem you have to solve anyway, so you might as well do it and make sure that you have the knowledge, tools and processes in place to be able to deploy code cleanly and quickly to any database in a controlled, automated way.

Pondlife
  • 15,992
  • 6
  • 37
  • 51
  • We use 5, with a simple batch file to deploy an upgrade script to multiple databases (200+), its fast and easy to manage. I've yet to experience a problem with this especially since I can perform a dry run on local staging environment which mirrors all the databases. And the best part is theres no funny rules to remember when writing stored procedures. – Chris Moutray Jun 22 '12 at 16:13
0

Make a stored procedure in master database or a database which will not deleted. Pass a parameter to stored procedure which identify in which database you want to get data and do rest of work accordingly.

Asif
  • 2,657
  • 19
  • 25