Can I have multiple tables to gather event data

Hi Guys,

Wondering if I could have two tables with parent child relationship to gather event data. Does NS support such scenario while defining schema in ADF.xml.

Please advice.

Thanks,

Shamir

You can use just about any T-SQL code in the EventRule Action node to

identify and insert new events for the SSNS application, as long as it

produces the appropriate fields as defined in the associated

eventclass.

HTH...

--

Joe Webb

SQL Server MVP

http://www.sqlns.com

~~~

Get up to speed quickly with SQLNS

http://www.amazon.com/exec/obidos/tg/detail/-/0972688811

I support PASS, the Professional Association for SQL Server.

(www.sqlpass.org)

On Sun, 23 Jul 2006 03:10:01 -0700,

wrote:

>Hi Guys,

>

>Wondering if I could have two tables with parent child relationship to

>gather event data. Does NS support such scenario while defining schema

>in ADF.xml.

>

>Please advice.

>

>Thanks,

>

>Shamir|||

[again, reposting since my prior attempt didn't seem to render appropriately]

You can use just about any T-SQL code in the EventRule Action node to
identify and insert new events for the SSNS application, as long as it
produces the appropriate fields as defined in the associated
eventclass.

HTH...

--
Joe Webb
SQL Server MVP
http://www.sqlns.com

~~~
Get up to speed quickly with SQLNS
http://www.amazon.com/exec/obidos/tg/detail/-/0972688811

I support PASS, the Professional Association for SQL Server.
(www.sqlpass.org)

|||

Hi Joe,

Thanks for your reply.

Let me give you a clear picture of what I am trying to do ..

I have event data of following structure,

Table 1:

<Transactions>

<Transaction id=1>

<Transaction id=2>

<Transaction id=3>

<Transactions>

Table 2:

<TransactionDetail>

<TId></TId>

<Info></Info>

<TransactionDetail>

"TId" in table 2 references id of transaction element in table 1. Idea is to support unlimited number of rows in table2. How can i go about this.

Thanks,

Shamir

|||

Ahhh...gotcha.

A couple of options come to mind. First you can flatten out the rows into multiple events. In this scenario, you'd have one event row per transaction detail and that row would include information from table 1 and table 2. You'd want to then use the digest delivery to pull it all together into one notification. However, under certain circumstances, I could see how this may lead to an occassional mishap where a user would receive more than one notification, each being somewhat incomplete.

You could also look at submitting only the master events, table 1, and then retrieving the detail information later on in the process - in either the match rule or perhaps in a custom delivery protocol.

HTH...

Joe