Creating an Instance and Making It Run
| To create an instance, you write an Instance Configuration File (ICF) and compile it with the SQL-NS compiler. An ICF is an XML document that describes the instance and the applications in it. The ICF contains a reference to the ADF for each application. After you've written your ICF, there are usually five steps to getting the instance running:
Step 1 creates the instance and application database objects and populates them with the required data. It also installs the required metadata about the instance in the SQL-NS system tables. Step 2 installs the Registry keys, the Windows service that hosts the SQL-NS engine, and the performance counters. A separate Windows service is installed for each SQL-NS instance. This allows different instances to be managed and configured independently. Step 3 gives the SQL-NS engine permission to log in to the database and perform the data operations required to run the instance. The instance and application database objects are created by an administrator (the user who invokes the SQL-NS compiler in step 1) and, by default, only that user will have access to them. Because it's recommended that the SQL-NS engine run as some low-privileged (nonadministrator account), you have to manually grant it login and database access. In some cases, the components in the SQL-NS engine also need to read from and write to files in the filesystem. Again, because the engine will be running as a low-privileged account, you'll need to explicitly grant it access to the necessary files and directories. Step 4 is required because when an instance is first created, all applications and components within it are configured as disabled. SQL-NS configures things this way for security reasons. Because you have to explicitly enable the things you want to run, the chances of you accidentally running something that poses a security risk are reduced. Step 5 puts the instance in motion. If the SQL-NS engine is hosted in a Windows service (as it usually is), you can start the service from the command line (using the net start command), from Management Studio, from the SQL Server Configuration Manager, or from the Services applet in Administrative Tools. If you have the SQL-NS engine hosted in another application (as described in Chapter 17, "Hosting the SQL-NS Execution Engine") you'll start the engine via whatever controls the hosting application offers. For the purpose of illustration in this chapter, I've provided a simple ICF that defines a skeleton instance with two applications in it. This ICF and the associated ADFs contain the minimum amount of code required to create a multiapplication instance that actually compiles and runs. A real instance with useful applications will likely have more code than you'll see here, but to highlight the basic instance concepts, the simple files referenced in this chapter will be sufficient. In the following sections, we'll work through the steps to get the instance running and examine the various parts of the instance in detail. Note To work through the steps in this chapter, you need to set up your development environment as described in Chapter 2, "Getting Set Up." If you have not already done so, perform the steps in that chapter before proceeding. The source code for this chapter is located in the Samples\MinimalMultiApplication directory under the source code base directory. Tools for Working with SQL-NS InstancesSQL-NS ships with two sets of tools for working with instances:
The two sets of tools offer equivalent functionality. The command-line tools are easier to automate through scripts, but the graphical tools are more user friendly at first. In Chapter 3, "The Simplest Notification Application: Stock Quotes," you used the graphical tools to create and run the StockBroker instance, but I didn't explain the tools in much detail. In this chapter, we'll take a more detailed look at what the tools do. I'll explain how to perform the various steps outlined in the previous section using both the command-line and the graphical tools. Caution As you read through this chapter, you should read the instructions for both toolsets in each section so that you become familiar with all the tools available to you. However, you should only execute the instructions for one of the two toolsets when you perform the various SQL-NS operations on your system. Because the two sets of tools do essentially the same things, if you complete the instructions for both, you'll be carrying out the underlying SQL-NS operations twice. In many cases, this will lead to errors or unexpected behavior. After you become familiar with SQL-NS concepts, I think you'll find the command-line tools most convenient to use. After this chapter, all the instructions for working with the examples will refer only to the command-line tools (though we'll still use Management Studio to examine and edit ICFs, ADFs, and T-SQL scripts). However, based on what you learn in this chapter, you should be able to perform the equivalent steps using the graphical tools if you prefer. The following subsections highlight the key points about each set of tools. The instructions in the remainder of this chapter provide more details on how they're used to carry out various operations. Note The functionality of the SQL-NS tools is also exposed programmatically through the Notification Services Management Objects (NMO) API. Using this API, you can write code to invoke the same operations that the tools usually perform. The NMO API is covered in Chapter 16, "Using Notification Services Management Objects." SQL-NS Command-Line ToolsThe SQL-NS command-line tools are invoked through an executable called nscontrol.exe. This executable is installed in the SQL-NS binaries directory. If you installed SQL Server 2005 in the C:\Program Files\Microsoft SQL Server directory, the SQL-NS binaries, including nscontrol.exe, will be in C:\Program Files\Microsoft SQL Server\90\NotificationServices\9.0.242\bin. To work with nscontrol.exe, it's convenient to have the SQL-NS binaries directory in your path. I recommend that you open a Notification Services command prompt when you want to work with SQL-NS command-line toolsyou can access the Notification Services Command Prompt shortcut via the Start menu, All Programs, Microsoft SQL Server 2005, Configuration Tools, Notification Services Command Prompt. This shortcut opens up a command prompt window with the path already configured to include the SQL-NS binaries directory. The instructions for using the command-line tools in this chapter assume you're invoking the tools from a Notification Services Command Prompt. The command-line arguments passed to nscontrol.exe determine what operations it performs. Usually, the first argument is a command name: for example, the command name, create, is given to instruct nscontrol.exe to create a new SQL-NS instance by compiling an ICF. Each command requires a specific set of parameters, which are passed as additional arguments to nscontrol.exe. In later sections, when nscontrol.exe is used to carry out various SQL-NS operations, the different command names and expected arguments are explained. SQL-NS Graphical Tools in Management StudioThe SQL-NS tools built in to Management Studio are all invoked from the Object Explorer. When you connect Management Studio's Object Explorer to a Standard or Enterprise Edition SQL Server, you'll see a folder labeled Notification Services in the object tree for that server. The items in this folder represent the various SQL-NS instances that have databases on the SQL Server. If there are no SQL-NS instances on the SQL Server, the Notification Services folder is empty. All the SQL-NS commands are available from context menus that appear when you right-click the Notification Services folder or its contents. When you right-click the folder itself, you get a context menu containing commands that apply to the server as a whole. When you right-click a particular instance in the Notification Services folder, the context menu contains commands that apply to that individual instance. Many of the commands launched from the context menu bring up dialog boxes that ask for additional information. As you work through the steps in this chapter, you'll become familiar with each of these commands and their associated dialog boxes. Compiling the ICFListing 4.1 shows the complete ICF for this chapter. Glance at it to get a feel for what it contains, but don't be concerned if you don't understand every line of it right now. First, we'll focus on compiling and registering the instance so that we can examine the databases and Registry keys that get created. Doing this illustrates many of the important instance concepts you should understand before we delve into the code. I will explain the code in the ICF line-by-line in the section "The Instance Configuration File in Detail" (p. 103). Listing 4.1. The Instance Configuration File
Compiling the ICF with the Command-Line ToolsTo compile the ICF with the SQL-NS command-line tools, you use the nscontrol create command. This command takes the name of the ICF as a parameter. It reads the XML in the ICF and the referenced ADFs and uses it to create the instance and application database objects. I've provided a batch file that invokes nscontrol create with the ICF shown in Listing 4.1. The batch file is useful because the actual call to nscontrol create is fairly long. Retyping it each time we needed to run it would not only be tiresome, it would also be error prone. Tip It's good practice to use batch files to invoke nscontrol commands. Many commands take several parameters, and using a batch file means that you don't have to remember all these parameters every time. Take a look at the call to nscontrol create in this batch file to examine how it works. Open the create.cmd file, located in the Samples\MinimalMultiApplication\Scripts subdirectory off your source code base directory, in a text editor. You'll see some lines at the top that have to do with setting environment variables and getting the username and password required for SQL Server Authentication: You can ignore these for now. But, below that, the actual call to nscontrol create appears as follows:
The -in argument specifies the name of the ICF to compile. In this case, it's InstanceConfiguration.xml located in the base directory of the instance (the name of which is obtained from the %INSTANCE_BASE_DIRECTORY_PATH% environment variable, established in one of the other scripts used to set up the development environment). Next, the value of the environment variable, %SQL_USER_INFO%, is given. The value of this environment variable is set by one of the setup scripts invoked earlier in create.cmd. If you're using SQL Server Authentication, this environment variable is set to a string that supplies values for the -sqlusername and -sqlpassword arguments to nscontrol create. These arguments tell nscontrol create what username and password to use when connecting to the SQL Server; the values supplied are the username and password of the development account you set up in Chapter 2. If you're using SQL Server Authentication, the expanded value of %SQL_USER_INFO% might look like -sqlusername "SQL-NS_Dev" -sqlpassword "devPassword" If you're set up to use Windows Authentication, %SQL_USER_INFO% is set to an empty string. This results in the -sqlusername and -sqlpassword arguments being omitted, which causes nscontrol create to use Windows Authentication. The remaining arguments passed to nscontrol create specify values for parameters used in the ICF. For example, the argument _SqlServer_=%SQL_SERVER% instructs the compiler to replace every occurrence of the string %_SqlServer_% in the ICF with the value of the %SQL_SERVER% environment variable. The last two arguments in the nscontrol create command line specify values for parameters _NSServer_ and _InstanceBaseDirectoryPath_. When we go through the code line-by-line in the section "The Instance Configuration File in Detail" (p. 103), you'll see where these parameters are used. Parameters are just a convenient text substitution mechanism that makes it easy to apply certain values consistently throughout your ICF and ADF code. The number and names of parameters used in the ICF are not mandated by SQL-NS. You may use parameters as much or as little as you prefer, and you may give your parameters any names you choose. I always surround the words in my parameter names with underscores, but that's just a convention that makes it easy to distinguish parameters from other tokens in the file. For more information on parameters, see the "Parameters" section (p. 104). Tip At the minimum, it's good practice to use parameters for server names in the ICF that may change. This makes it easy to relocate your instance to a different server without having to modify your ICF code directly. Also, whenever you need to include sensitive information in the ICF, such as usernames and passwords, it's usually best to use parameters. (Usernames and passwords are sometimes needed for event providers and delivery protocols, as described in Chapter 8, "Event Providers," and Chapter 10, "Delivery Protocols.") By using parameters, you can avoid storing these sensitive strings in the file, where they may be visible to unauthorized users. In the example we just examined, all the parameter values came from environment variables. You can also specify parameter values that are literal constantsfor example, _SqlServer_=DBServer01. However, using environment variables is usually more convenient. The development environment was set up in Chapter 2 so that all the environment variable values are set in one batch file and then used in all the other batch files that invoke nscontrol commands. With this setup, if you need to change a value, you just need to make the change in one place. Now that we've looked at the nscontrol create command, let's run it and see what it does:
The script should generate output similar to that shown in Figure 4.2, indicating that SQL-NS is validating the instance definition and creating the database objects for the instance and the two applications within it. Figure 4.2. Running nscontrol create on the command line. Compiling the ICF with the Management Studio ToolsTo compile the ICF with the graphical SQL-NS tools in Management Studio, you use the New Notification Services Instance command. This command is launched from the context menu opened by right-clicking the Notification Services folder in the Object Explorer tree. When you invoke this command, Management Studio opens the New Notification Services Instance dialog box, in which you select the ICF to compile. After you select an ICF, Management Studio populates the parameters grid in the New Notification Services Instance dialog box with the list of parameters used in the file. The values in the grid are initialized with any defaults you may have supplied in the ICF (as described later in the "Parameters" section, p. 104). If you want to change any of the parameter values, you can do so by editing the values shown in the grid. The New Notification Services Instance dialog box also has a check box control by which you can choose whether to enable the instance after it has been created (enabling of instances is covered in more detail in the "Enabling the Instance" section, p. 95, later in this chapter). Follow these instructions to compile this chapter's sample instance with the Management Studio tools:
Figure 4.3 shows what your Management Studio window should look like after the New Notification Services Instance progress dialog box completes. Notice the new item in the Notification Services folder in the Object Explorer. Figure 4.3. Creating a new SQL-NS instance using the Management Studio tools. Examining the DatabaseAfter successfully compiling the instance with either nscontrol create or the New Notification Services Instance command in Management Studio, you can examine the database objects created by the SQL-NS compiler:
In the "Instance Database Objects" section (p. 98), we'll explore a few of the instance objects in the database in more detail, but for now, you should spend some time just looking at some of them. Focus on the objects qualified with the NSInstance schema name (the schema name specified in the <Database> element in the ICF). Ignore the application database objects (those qualified with the schema names Application1 and Application2) for now. We'll examine application database objects in detail in Chapter 5, "Designing and Prototyping an Application.") In addition to creating the instance and application database objects, the SQL-NS compiler also installs metadata about the instance in SQL-NS system tables. In the "Instance Metadata" section (p. 100) later in this chapter, we take a closer look at the information in these tables. Registering the InstanceCompiling the ICF resulted in SQL-NS creating the instance and application database objects in the MinimalMultiApplication database. Now we need to register the instance to install the required Registry keys, the Windows service that will host the SQL-NS engine, and the performance counters that are used to monitor the activities of the instance. Registering the Instance with the Command-Line ToolsTo register the instance with the SQL-NS command-line tools, we use the nscontrol register command. As we did with the nscontrol create command in the previous section, we'll use a batch file to wrap the nscontrol register command and its arguments. Let's examine this file to understand the nscontrol register command syntax. Open the register.cmd file, located in the Samples\MinimalMultiApplication\Scripts subdirectory off your source code base directory, in a text editor. Like create.cmd, which we looked at in the previous section, register.cmd begins with some environment variable settings that will be required later. Looking further down in the file, you'll see that the call to nscontrol register is as follows:
The -n argument specifies the name of the instance to register. This is obtained from an environment variable, which, as before, is established in one of the earlier setup scripts that register.cmd invokes. The -s argument specifies the name of the SQL Server on which the instance and application databases are located, again obtained from an environment variable. Note that the value passed for this argument should be the same as specified in the <SqlServerSystem> element of the ICF. When we look at the ICF in detail, you'll see that it is the same because the <SqlServerSystem> element's value was obtained from the _SqlServer_ parameter, for which we used the same %SQL_SERVER% environment variable as a value. The -service argument instructs SQL-NS to install the SQL-NS Windows service to host the SQL-NS engine. This argument exists because there are some cases where you will want to register the instance but not install the service: for example, if you have a dedicated web server to host your subscription management interface or if you are hosting the SQL-NS engine in your own application process, as described in Chapter 17. The -serviceusername and -servicepassword arguments specify the name and password of the Windows account under which the service should run. In Chapter 2 we created an account for the service and stored the username in an environment variable. We use that environment variable to obtain the username here and pass it to the -serviceusername argument. The code at the beginning of the register.cmd file prompts for the password for this account and stores it in the %NS_SERVICE_PASSWORD% environment variable. This variable is then used to supply a value for the -servicepassword argument. After it has been used in the call to nscontrol register, the %NS_SERVICE_PASSWORD% environment variable is cleared out (for obvious security reasons). When you're done examining the contents of the register.cmd file, use the following instructions to run it and register the instance with the nscontrol register command:
Figure 4.4 shows nscontrol register invoked on the command line. The command prints out status messages indicating that the Registry entries, Windows service, and performance counters are installed successfully. Figure 4.4. Running nscontrol register on the command line. Registering the Instance with the Management Studio ToolsTo register the instance with the graphical SQL-NS tools in Management Studio, you use the Register Instance command. This command is launched from the context menu that appears when you right-click a particular instance item in the Notification Services folder in the Object Explorer tree. (Note that this is different from the New Notification Services Instance command, which is always launched from the context menu on the Notification Services folder itself.) When you invoke the Register Instance command, Management Studio opens the Register Instance dialog box, in which you can choose to install the SQL-NS Windows service and supply the required credentials. It's important to note that even if you're connected to a remote SQL server in the Object Explorer, the Register Instance command always creates the instance registration (including the Registry keys, the Windows service, and the performance counters) on the local computer on which you're running Management Studio. To register an instance on another computer, you have to physically run Management Studio or nscontrol register on that computer. Follow these instructions to register this chapter's sample instance with the Management Studio tools:
Figure 4.5 shows a Management Studio window immediately after the Register Instance command has completed. The progress dialog box indicates that the Registry entries, Windows service, and performance counters are installed successfully. Figure 4.5. Registering a SQL-NS instance using the Management Studio tools. Granting PermissionsWhen you registered the instance using the steps in the previous section, you configured the service to run under a specific Windows account. If you're using SQL Server Authentication, you also configured the service to connect to the database with a SQL username and password. You now have to configure database permissions so that the Windows service can access the instance's database at runtime. You also need to assign the appropriate filesystem permissions to the service's Windows account so that components such as the file delivery protocol can read and write the necessary files. This section explains how to correctly configure both database and filesystem permissions for a SQL-NS instance. Granting Database PermissionsWhen you completed the instructions in Chapter 2, you created a SQL Server login for the SQL-NS Windows service (see the "Setting Up SQL Permissions and Accounts" section, p. 32). If you're using Windows Authentication, the login you created was for the service's Windows user account. If you're using SQL Server Authentication, you created a SQL Server login with a password. You now need to set up the service's login as a user in the instance's database. This will allow the service to use the database when it establishes a connection to the SQL Server. You also need to add the service user to specific SQL-NS database roles. SQL-NS defines a set of database roles corresponding to the various operations that can be done with the instance and application database objects. For example, there is a role for event submission and another role for subscription management. The permissions on the objects in the database are set so that only users in the appropriate roles can access them. The complete set of SQL-NS database roles is documented in the SQL-NS Books Online. However, in this case, you just need to place the service user in the NSRunService role, which allows it to perform the operations required of the SQL-NS engine components. Note This might seem like a lot of work to get a simple instance running, but it's necessary to keep your system secure. Of course, it would be much easier if you just let your service run under an Administrator account and granted full permission to your databases. But then you run the risk that someone tampering with the service would have unrestricted access to your data. Instead, it's wise to always grant only the minimum set of permissions needed. This takes more time and involves more steps, but it's worth the trouble. All the samples that accompany this book come with a T-SQL script called SQLPermissions.sql. This script executes the commands needed to set up the required database permissions. For the sample we're working with in this chapter, you'll find SQLPermissions.sql in the C:\SQL-NS\Samples\MinimalMultiApplication directory. Note SQLPermissions.sql is one of the files that was generated from a template when you ran the setup script described in the "Customizing the Source Files for Your Environment" section (p. 39) in Chapter 2. The contents of the script will be different, depending on whether you set up your system to use Windows Authentication or SQL Server Authentication. Open the file C:\SQL-NS\Samples\MinimalMultiApplication\SQLPermissions.sql in Management Studio to examine its contents. The first line in the file changes context to the MinimalMultiApplication database: USE MinimalMultiApplication Next, the script invokes the CREATE USER command to create a user in this database for the service login. On my system, I'm using Windows Authentication and my service runs under the PATHERNET\SQL-NS_Service domain account, so the line reads: CREATE USER [PATHERNET\SQL-NS_Service] On your system, this line should specify the name of your service Windows account if you're using Windows Authentication, or the name of your SQL test account if you're using SQL Server Authentication. Finally, the script adds the service user to the NSRunService database role. On my system, this line reads EXEC sp_addrolemember 'NSRunService', 'PATHERNET\SQL-NS_Service' Again, the username may be different on your system. Run the SQLPermissions.sql script to set up the database permissions on your system. You can run it directly in a Management Studio query window or you can use the batch file, grant_permissions.cmd, in the sample's scripts directory (C:\SQL-NS\Samples\MinimalMultiApplication\Scripts) to run it from the command line. The grant_permissions.cmd batch file invokes the sqlcmd command-line utility to run the same SQLPermissions.sql script. Granting Filesystem PermissionsIn this chapter's sample (and the one in the previous chapters), the SQL-NS engine is configured to use the file delivery protocol to write notifications to a file. The Windows account of the SQL-NS service hosting the engine therefore needs write permissions to the notifications file. When you create a SQL-NS instance, you must determine the filesystem permissions needed by the SQL-NS engine, based on the engine components that your instance and its applications will use. In the samples we've looked at so far, the file delivery protocol is the only component that needs access to the filesystem, so we need to grant the service user write access to the notifications file. If we were using other SQL-NS components, such as the FileSystemWatcher event provider (covered in Chapter 8), we'd have to grant other permissions as well. You can grant filesystem permissions using Windows Explorer: right-click the relevant file or directory, choose Properties from the context menu, and go to the Security tab in the properties dialog box. From there you can assign the appropriate permissions to the service account. You can also assign permissions from the command line, using the cacls utility. The setup scripts that were run when you completed the instructions in the "Customizing the Source Files for Your Environment" section (p. 39) in Chapter 2 already invoked cacls to assign the appropriate filesystem permissions for all the book's samples to the service account you specified. If you want to see how this was done, open the setup.cmd batch file in this chapter's scripts directory and look at the calls to cacls near the end. Enabling the InstanceAs mentioned earlier in this chapter, when you first create an instance, all components within it are configured as disabled. This is to prevent any components from running without your explicit consent. SQL-NS allows you to enable (or disable) each running part of the instance separately. You can enable applications individually and even choose to enable individual components within each application (for example, a specific event provider or distributor). Enabling the Instance with the Command-Line ToolsTo enable components of the instance from the command line, use the nscontrol enable command. As you might expect, the nscontrol disable command is used to disable components. In the Samples\MinimalMultiApplication\Scripts directory, you'll find a script called enable.cmd that invokes to nscontrol enable. Take a look at the nscontrol enable syntax by opening this file in a text editor. In enable.cmd, the call to nscontrol enable appears as follows: nscontrol enable -n %INSTANCE_NAME% %SQL_USER_INFO% For simplicity, this command just enables the whole instance. The -n argument provides the instance name. If we wanted to enable only certain parts of the instance, we'd have to specify additional arguments to nscontrol enable to identify the components the command should affect. These arguments are explained in the "Enabling and Disabling Components" section (p. 492) in Chapter 14. Again, the %SQL_USER_INFO% environment variable is used. As in previous commands, if you're using SQL Server Authentication, it supplies values for the -sqlusername and -sqlpassword arguments; otherwise, it evaluates to an empty string. Run the enable.cmd script:
When it completes, the enable command prints out the status of the various components in the instance. At this point, all should say either Enabled or Enable Pending. Those that say Enable Pending will become enabled when the SQL-NS engine starts. Enabling the Instance with the Management Studio ToolsWhen you first create an instance in Management Studio, you have the option of enabling it at the same time. To do this, you check the Enable Instance After It Is Created box, below the parameters grid in the New Notification Services Instance dialog box. You were instructed to do this in step 6 of the instructions in the "Compiling the ICF with the Management Studio Tools" section (p. 87), earlier in this chapter. If you did not do this, or if you disable the instance at some later time and want to reenable it, you can use the facilities described in this section. Note Though you can choose to enable an instance when you create it in Management Studio, there is no equivalent option in the command-line nscontrol create command. To enable a whole instance from Management Studio, launch the Enable Instance command from the context menu on the instance item in the Notification Services folder. When you invoke this command, you'll be prompted for confirmation. If you answer Yes in the confirmation dialog box, the command will proceed and no other visual feedback will be given. Unfortunately, there is no immediate visual indication in the Object Explorer as to whether a particular instance is enabled. To check the enabled status of an instance and its components, you have to open the properties dialog box for the instance from its context menu (right-click the instance in the Object Explorer and choose Properties). The properties dialog box has several pages; you can select a page to view from the list in the left pane of the dialog box. The Applications page shows you the status of the various applications in the instance and their components. You can change the status of individual components via the Enabled check box on each line in the components grid. The Subscribers page in the properties dialog box lets you view and change the enabled status for subscriber management. To enable the instance we created in this chapter, use the following instructions. These steps will enable the whole instance. There's no harm in enabling an instance that's already enabled, so feel free to perform these steps, even if you enabled the instance at the time you created it.
Starting the InstanceNow that we've created the instance, registered it, granted database permissions, and enabled the required components, we are ready to start the instance. This amounts to starting the Windows service that was installed for the instance when we registered it. The Windows service for a given instance is always named NS$<InstanceName> where <InstanceName> is the name of the instance. Because in this chapter, our instance is called MinimalMultiApplication, the service is called NS$MinimalMultiApplication. To start the instance's service, you can use any of the standard mechanisms for managing Windows services. These include the net start command and the Services applet in Administrative Tools. For example, to start the service from the command line using net start, issue the following command: net start NS$MinimalMultiApplication You should see messages indicating that the service is starting and finally one that says it started successfully. Tip If your service did not start successfully, look in the Application Event Log for error messages. (Open Administrative Tools from your Start menu and choose Event Viewer; open the Application log and look for messages that have NotificationServices listed as the source.) In general, the Application Event Log is the first place you should look if you have problems with your SQL-NS applications. SQL Server 2005's toolset introduces two new ways you can start and stop instances: using Management Studio and using the SQL Server Configuration Manager. From Management Studio, right-click an instance in the Object Explorer and select Start from the context menu. This has the advantage of starting the instance's service on all computers on which it is deployed (in the case of a multimachine deployment, as described in the "Deployment of SQL-NS Instances on Multiple Servers" section, p. 102, later in this chapter). The SQL Server Configuration Manager (launched from the Start menu, All Programs, Microsoft SQL Server 2005, Configuration Tools, SQL Server Configuration Manager) provides a central interface for managing all the services associated with SQL Server 2005 (including SQL-NS instance services). In SQL Server Configuration Manager, you can select the instance service from the list and use either the buttons in the toolbar or the context menus to start and stop it. Choose one of the methods described in this section and start the service for this chapter's instance on your system. Whichever method you used, if your service started successfully, you now have a running instance. In its current form, it's not very exciting because there are no events or subscriptions and, therefore, no notifications. We'll get to adding those things in Chapter 5. For now, you've learned the basic steps to get the instance running. If this seemed like a lot of work for no results, be assured that you're over the hardest part. You've built the basic framework in which any application can be implemented. From now on, all the code you'll see in the next few chapters adds functionality that you can observe and test. Whenever you build SQL-NS instances and applications going forward, you'll need to use the same patterns and techniques you learned in this chapter. However, you'll probably automate most of the steps and they'll go by much faster. |
/www.w3.org/2001/XMLSchema-instance xmlns="http://www.microsoft.com 
EAN: 2147483647
Pages: 166