Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

Notification Services for the DBA

Last updated Mar 28, 2003.

In most applications, users connect to the database using a client program or through various layers. Once they connect they get instant (or near-instant) feedback from the database that shows the results of their queries on a computer monitor. When we begin new development efforts, that's usually the type of system we're thinking about.

But in some cases the user just needs an answer from the database, and they don't necessarily even need to enter any data to get it. For instance, managers might want to know when a run finishes on a line, or clients might want to know about a stock ticker change. In both of these situations the user could log onto a system periodically, but it makes more sense for the data to be delivered to them when its status changes. It also makes more sense for the user not to have to use a computer at all, but have the data sent directly from the database to their cell phone, PDA or over an E-Mail.

SQL Server Notification Services can do just that. It's a set of programs that tracks changes in a database field, a file system, or even other events that developers write that can send out immediate and delayed notifications using several built-in protocols or you can extend the system by writing your own. You can use Notification Services to extend the capabilities of SQL Server to provide remote users with data from your databases either on a scheduled or rule-based basis, using a program. Once you define the parameters for the notifications, other programmers can write code to simply request the notification.

The main advantage to using Notification Services is that the data is pushed out automatically based on an event—stock notifications, project changes, travel schedules, inventory levels, etc. Another great use for this service is on a data-collection system. Systems (assembly lines, medical devices, etc.) can ship their data to a database, and Notification Services can then route that data to remote devices. The Microsoft Messenger service uses a similar concept to send traffic and stock alerts.

Notification Services is available natively in SQL Server 2005, and as download for SQL Server 2000. To run Notification Services in Windows 2000, you need to download the source from Microsoft, as it doesn’t come in the standard install media. Once you’ve done that, you follow a standard Next, Next, Finish install, with the exception of choosing an instance of the database server to use (usually the default instance) and destination directories.

One of the most difficult things to understand about Notification Services is all the terminology changes. Microsoft describes Notification Services using some fairly generic words that you've probably seen in another context. Here's a basic chart that will help you out with some of the terms, and then I'll explain how they all fit together in the context of a Notification Services application.




A group of settings that defines the rules, Events, Subscribers, Distributors and Generators that run as an interface to a client program that receive data from the server.

Application Database

The database that contains the metadata used to track all the parts of a single Notification Services application. This is paired with the XML configuration file to get data to users.


Hardware or software (such as cell phones or email) that can accept data from Notification Services.


The part of Notification Services that formats and sends the data.


A change in data that you care about. From the examples above, a stock price change or a project change would be an event.


The part of Notification Services that matches changes in data (events) to those who should learn about the changes (subscribers).


A group of settings that controls a service program that runs in the background of the server, it also defines all of the Notification Services Applications that are allowed to run under the context of that service.


The final message that goes to the user (subscriber).


The user (which could be another computer software system) that gets the data (notifications).

You’ll find even more terms as you dig a little deeper, but these cover the basics. With those terms defined, let's take a look at the high-level process flow within the system:

  1. Notification Services stores subscriber and subscription data in a SQL Server database.
  2. Notification Services collects event data (using event providers) and stores the event data in the application’s database.
  3. The generator matches subscriptions and events and then generates notifications on a user-defined interval.
  4. The distributor delivers the data to subscribers. You can use XSLT to format the data for the subscribers.

That's the overview of how the process works once you set the system up. To create a Notification Services application, you can use a set of XML files (SQL Server 2000 and 2005), or a programming model called Notification Services Management Objects (SQL Server 2005 only). Using NMO is the simplest way to create the Instances and Applications, but if you use the XML files you can make the applications more portable. The two XML files you need to create are called the Instance Configuration File (ICF) and the Application Definition File (ADF).

Whichever route you choose, creating and enabling the Instance and Application will create a Windows Services (the Instance name prefaced with NS$) and a database that holds the meta-data and event information. In SQL Server 2005 you can manage and monitor the system using the SQL Server Management Studio, and in SQL Server 2000 you can use the NSCONTROL.EXE program.

Before you create your files or the NMO programs, there's a process you can follow to create your applications.

  1. Design your application. You have to know what users want and where the data is stored. This is a typical part of any project; it’s the specification of the goals and the business rules. This step is all paper and meetings, but from here on you’ll be using a programming environment to do the job. .NET is the environment of choice.
  2. Create the ICF and ADF files, specifying the required elements for the Instance and its Applications.
  3. Add one or more Event Classes to the files or NMO program. Event classes define the data that you’ll monitor for changes.
  4. Add an event-driven or scheduled Subscription Classes to the files or NMO program. This part ties the Event Class to the Subscription, and sets the trigger that will cause the event to fire. The events can fire instantly (event-driven) or at specified times (scheduled).
  5. Add the Notification Information Classes and Formatter processes to the files or NMO program. In this step, you set up the formatting and outputs for the Events.
  6. Add one or more Event Providers to the files or NMO program. A provider tracks changes to a filesystem, table or other function.
  7. Add the delivery protocols. Standard choices here are SMS (Short Message Service) and SMTP (Simple Mail Transport Protocol), or file. This gets your message to the intended user or program.

In my next tutorial on Notification Services I'll break down the parts of the ICF and ADF, and explain a bit more about the NMO programming objects.

Informit Articles and Sample Chapters

The first book I got on Notification Services was Microsoft SQL Server 2000 Notification Services by By Shyam Pather. You can read a free excerpt from it and learn about a simple application here.

Online Resources

The definitive resource for Notification Services is here. You can find out everything you need to know, and also get the download for free for SQL Server 2000.