Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

As an example, let’s assume that AdventureWorks2008 was implementing a rule that said that orders
couldn’t be entered if they were more than seven days old. Knowing this rule, we could add our own
custom message that tells the user about issues with their order date:
sp_addmessage
@msgnum = 60000,
@severity = 10,
@msgtext = ‘%s is not a valid Order date.
Order date must be within 7 days of current date.’;
Execute the sproc and it confirms the addition of the new message: Command(s) completed
successfully.
No matter what database you’re working with when you run sp_addmessage, the actual message is
added to the master database and can be viewed at any time by looking at the sys.messages system
view. The significance of this is that, if you migrate your database to a new server, the messages will
need to be added again to that new server (the old ones will still be in the master database of the old
server). As such, I strongly recommend keeping all your custom messages stored in a script somewhere
so they can easily be added into a new system.
Removing an Existing Custom Message
To get rid of the custom message use:
sp_dropmessage
What a Sproc Offer s
Now that we’ve spent some time looking at how to build a sproc, we probably ought to ask the question
as to why to use them. Some of the reasons are pretty basic; others may not come to mind right away if
you’re new to the RDBMS world. The primary benefits of sprocs include:
❑ Making processes that require procedural action callable
❑ Security
❑ Performance
Creating Callable Processes
Chapter 12: Stored Procedures
As I’ve already indicated, a sproc is something of a script that is stored in the database. The nice thing is
that, because it is a database object, we can call to it — you don’t have to manually load it from a file
before executing it.
395