Debugging and the Development Process

As described in Chapter 5, "Designing and Prototyping an Application," when building a new SQL-NS application, you should construct the prototype ADF one piece at a time (see the "Building the ADF Incrementally" section, p. 127). In the typical development process, you will add the schemas for the events, subscriptions, and notifications first, and then add the logic that connects them. The logic in the ADF is specified in rules of three types:

• Event chronicle rules that maintain the state information stored in event chronicle tables

• Event-triggered match rules that produce notifications for event-triggered subscriptions

• Scheduled match rules that produce notifications for scheduled subscriptions

Note

As you may recall from Chapter 6, "Completing the Application Prototype: Scheduled Subscriptions and Application State," you can declare subscription chronicles in the ADF, but there is no dedicated ADF element for declaring subscription chronicle rules. Generally, subscription chronicles are updated as part of the match rule logic.

All three types of rules are SQL statements that may contain errors (syntactical or semantic) when you first write them. This chapter is about finding and fixing those errors.

Syntax Errors in Rules

Syntax errors are usually easy to deal with. In most cases, if a rule definition contains a syntax error, you receive an error message when you compile the application. Compile-time error messages are printed to the console by nscontrol create. If you're using Management Studio to compile your application, the error messages are displayed in the progress dialog box of the New Notification Services Instance command. These compile-time error messages usually provide specific information that enables you to spot your mistakes quickly. After you identify the errors, you can fix them and then recompile.

In the few cases where syntax errors are not caught at compile time (this can sometimes happen if your rule logic constructs dynamic SQL code), you will get a syntax error message at the time the rule runs. In SQL-NS, runtime error messages appear as entries in the Application event log, which you can access by opening the Event Viewer from Administrative Tools. All event log entries generated by SQL-NS specify NotificationServices as the event source, and those relating to the execution of rules have event IDs in the 40004999 range.

Note

For more information on using the Application event log to view SQL-NS error messages, see the "Using the Application Event Log" section (p. 484) in Chapter 14, "Administering a SQL-NS Instance."

If your rules generate runtime error messages, you will have to fix them in the ADF and then update the instance to recompile the application. After the update completes, you can test your application again to verify that the runtime problems have been fixed. When you do this, it's important to look at the Application event log and make sure that no new error messages appear.

Semantic Errors in Rules

Semantic errors in rules are usually more difficult to track down than syntax errors. When you have a semantic error, the rule syntax may be correct (so you might not see an error from the compiler or the engine), but the rule does not do what you expect it to. Semantic errors usually manifest themselves as too few or too many notifications being generated. Based on the notification data generated when testing the application against sample events and subscriptions, you might deduce that a semantic error exists. Finding and fixing the semantic error can sometimes be a challenge.

When tracking down a semantic error, it usually helps to run the application's rules manually, outside the SQL-NS engine. Doing this allows you to look at the exact inputs and outputs, and examine what the rules are really doing. Running rules manually also allows you to examine the intermediate state of the application between rule invocations.

Because the rules are just SQL statements, you might be tempted to cut and paste them from the ADF into a Management Studio query window to run them manually. If you try this, you'll find that the rule statements won't run because they rely on views of the event and subscription data that don't exist (or aren't populated with the correct data) until the SQL-NS engine sets them up at runtime. Even if the views did exist, any rule that inserts into a notifications view will not work if invoked directly, because the triggers on the notifications views rely on internal state set up by the generator before they are normally invoked.

To get around these problems, SQL-NS provides a set of stored procedures that you can use to debug your rule logic. These stored procedures mimic the runtime environment set up by the SQL-NS engine and allow you to invoke the rules manually. This chapter shows you how to use these stored procedures effectively to debug your applications. Being comfortable with these debugging stored procedures will reduce the time and effort required to get the initial prototype of your application running correctly.