This documentation is archived and is not being maintained.

Defining Event Chronicle Tables

Event chronicles are supplemental event tables in your application database. If you want to use event chronicles to store event data, you must define chronicle tables when you define event classes.

When you define an event class, you can define one or more chronicle tables by using Transact-SQL. The CREATE TABLE statement must include the table name, field names, and field data types. The statement can also include arguments for constraints and any other optional CREATE TABLE parameters. You can also include a CREATE INDEX statement to create an index on your event chronicle table. For more information, see CREATE TABLE (Transact-SQL).

You can create the chronicle table in any schema of any database that is accessible by the application. Specifically, the generator, which fires event chronicle rules and subscription rules, must be able to write data to and read data from the event chronicle table.

Notification Services does not automatically drop event chronicle tables when you update the application. Statements to create a chronicle table fail if a table with the same name exists. Use the INFORMATION_SCHEMA.TABLES view to check if the table exists, and then either skip creating the table or drop and re-create the table.

The following example shows how to delete an existing table with the name dbo.StockEventChron and then create a chronicle for the StockEvents event class that has two columns, StockSymbol and StockHighPrice, with StockSymbol as the primary key:

    WHERE TABLE_NAME = 'StockEventsChron'
        AND TABLE_SCHEMA = 'dbo')
    DROP TABLE dbo.StockEventsChron;
    CREATE TABLE dbo.StockEventsChron
    StockSymbol char(10),
    StockHighPrice decimal(18,5)
    PRIMARY KEY (StockSymbol)

If you are defining an application in an XML file, you must replace reserved XML characters, such as '>', with their entity references. For more information, see XML Reserved Characters.

To define an event chronicle table