SQL DATABASE
-
Hi all, Could You please let me know how to trace a Stored Procedure modifications history within a certain period of time? Including the conetnet of a Stored Procedures at a particular period of time. Many thanks for your help.
-
Hi all, Could You please let me know how to trace a Stored Procedure modifications history within a certain period of time? Including the conetnet of a Stored Procedures at a particular period of time. Many thanks for your help.
As d@nish said, you'd best keep a copy of your procedures in a safe location. The database itself doesn't version the procedures, there's no change-history by default. Try restoring a database-backup that contains the correct version of the sp's. --edit; (to prevent this)
- Script your entire database, in the version that you're releasing to the customer(s).
- Archive them somewhere safe (SourceSafe - don't forget to label it, or even burned and nicely indexed on CD)
- Include all unit-tests for your procdures!
- Consider whether the sprocs have any dependencies themselves, like functions, views or other procedures.
- A scripter[^] might come in handy.
I are Troll :suss:
modified on Thursday, August 26, 2010 6:22 PM
-
Thanks very much for your response.Its much appreciated.I didnt have TFS ,I am just running Sql 2008 and wated to know the content of a particular Stored procedure at one time back before modification. Please advice.
Have a database project in your code which will have all the scripts logically placed in separate folders. Database will not do this for you. Either usea source control software or take regular backups. Former, IMHO, is simpler and suitable for your requirement. If you don't have a DB backup, you cannot revert back unless you manually edit things.
-
As d@nish said, you'd best keep a copy of your procedures in a safe location. The database itself doesn't version the procedures, there's no change-history by default. Try restoring a database-backup that contains the correct version of the sp's. --edit; (to prevent this)
- Script your entire database, in the version that you're releasing to the customer(s).
- Archive them somewhere safe (SourceSafe - don't forget to label it, or even burned and nicely indexed on CD)
- Include all unit-tests for your procdures!
- Consider whether the sprocs have any dependencies themselves, like functions, views or other procedures.
- A scripter[^] might come in handy.
I are Troll :suss:
modified on Thursday, August 26, 2010 6:22 PM
Eddy Vluggen wrote:
The database itself doesn't version the procedures,
Another argument against using stored procedures.
-
Eddy Vluggen wrote:
The database itself doesn't version the procedures,
Another argument against using stored procedures.
-
The database does not version any objects [Tables, Views, Triggers, Functions and Stored Procedures]; so using your argument, should we avoid databases altogether?
SilimSayo wrote:
PIEBALDConsult wrote:
Another argument against using stored procedures.
The database does not version any objects [Tables, Views, Triggers, Functions and Stored Procedures]; so using your argument, should we avoid databases altogether?
It's not the non-versioning that's bad, it's sproc's. PI isn't saying that the database should do versioning, he just found an argument against sprocs. Like the argument or not, inline Sql usually gets backed up with the source. Yes, some people will prefer sprocs. I prefer whatever my client pays me to, as it's kinda easy to switch between the two. Yes, we can start a religious argument on the topic, but that shouldn't be part of the answer. How 'bout the lounge?
I are Troll :suss:
-
The database does not version any objects [Tables, Views, Triggers, Functions and Stored Procedures]; so using your argument, should we avoid databases altogether?
A database is for data; not code. Use a code base for code.
-
A database is for data; not code. Use a code base for code.