|
|
You're in the
sql server notification services
group:Source for Event Data
sql server notification services:
large proprietary database that contains the event data for our proposed SQL NS application. If possible I would like to not duplicate this data in the SQL Server table for the NS application. Does the event data have to be in the SQL Server tables or can it be accessible via any ODBC data source?
Hi,
AFAIK, event data has to reside in the same SQL Server table. The current version doesn't support to get event data from ODBC resources. But the application architecture can support it. You have to duplicate the event data in the SQL Server table. Regards, R.Balaji [quoted text, click to view] "RDV" wrote:
> Does the event data have to reside in a SQL Server table? We have a > large proprietary database that contains the event data for our > proposed SQL NS application. If possible I would like to not duplicate > this data in the SQL Server table for the NS application. > Does the event data have to be in the SQL Server tables or can it be > accessible via any ODBC data source? >
With NS2.0, the event & chron rules must use the notification function
provided by the NS framework. This changes in 2005 where we will be able to define the matches using standard T-SQL statements. If you'd rather not "duplication the data", then you can consider creating a custom delivery protocol that accepts a minimal amount of event data, goes out to your propriety data for the rest of the event information, and then sends the notification. However, if you're primary concern is database growth, the vaccuumer can help with this. HTH... Joe Webb SQL Server MVP ~~~ Get up to speed quickly with SQLNS http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 [quoted text, click to view] Balaji Ramachandran wrote:
> Hi, > AFAIK, event data has to reside in the same SQL Server table. > The current version doesn't support to get event data from ODBC resources. > But the application architecture can support it. > > You have to duplicate the event data in the SQL Server table. > > Regards, > R.Balaji > > > "RDV" wrote: > > >>Does the event data have to reside in a SQL Server table? We have a >>large proprietary database that contains the event data for our >>proposed SQL NS application. If possible I would like to not duplicate >>this data in the SQL Server table for the NS application. >>Does the event data have to be in the SQL Server tables or can it be >>accessible via any ODBC data source? >>
Hello all,
Actually, neither answer given so far is correct :-). To answer the original question, your event data can reside anywhere that can be accessed from a SQL statement on the server hosting your NS applications. So, it can be in another database on the same server, or on a linked server that you refer to using a four-part name. If your application is event-triggered, then you may need to submit some "pseudo-events" that just serve as a kick to the NS application to perform matching. These pseudo-events can simply be IDs that refer to rows in an existing table elsewhere. Your match rule can have any of the following forms: --Local data SELECT NotificationClassNameNotify(...) FROM EventClassName e, Subscriptions s WHERE ... --Data in another database SELECT NotificationClassNameNotify(...) FROM mydatabase.dbo.RealEvents events, EventClassName e, Subscriptions s WHERE events.Id = e.Id AND ... --Data on another server SELECT NotificationClassNameNotify(...) FROM myserver.mydatabase.dbo.RealEvents events, EventClassName e, Subscriptions s WHERE events.Id = e.Id AND ... If you have a copy of my book (http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/) you can see an example of this. My MusicStore application simply uses SongIds to refer to Song data in another database. Hope this helps. -shyam -- Learn more about SQL-NS: http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/ --------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. --------------------------------------------- [quoted text, click to view] "Joe Webb" <joew@webbtechsolutions.com> wrote in message news:#nxDIQTOFHA.3704@TK2MSFTNGP12.phx.gbl... > With NS2.0, the event & chron rules must use the notification function > provided by the NS framework. This changes in 2005 where we will be able > to define the matches using standard T-SQL statements. > > If you'd rather not "duplication the data", then you can consider > creating a custom delivery protocol that accepts a minimal amount of > event data, goes out to your propriety data for the rest of the event > information, and then sends the notification. > > However, if you're primary concern is database growth, the vaccuumer can > help with this. > > HTH... > Joe Webb > SQL Server MVP > > ~~~ > Get up to speed quickly with SQLNS > http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 > > > > Balaji Ramachandran wrote: > > Hi, > > AFAIK, event data has to reside in the same SQL Server table. > > The current version doesn't support to get event data from ODBC resources. > > But the application architecture can support it. > > > > You have to duplicate the event data in the SQL Server table. > > > > Regards, > > R.Balaji > > > > > > "RDV" wrote: > > > > > >>Does the event data have to reside in a SQL Server table? We have a > >>large proprietary database that contains the event data for our > >>proposed SQL NS application. If possible I would like to not duplicate > >>this data in the SQL Server table for the NS application. > >>Does the event data have to be in the SQL Server tables or can it be > >>accessible via any ODBC data source? > >> > >>
Ahh....THANKS Shyam! That's terrific to know! :)
(I'm embarrassed to say I missed that in your book.) HTH... Joe Webb SQL Server MVP ~~~ Get up to speed quickly with SQLNS http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 [quoted text, click to view] Shyam Pather [MSFT] wrote:
> Hello all, > Actually, neither answer given so far is correct :-). > > To answer the original question, your event data can reside anywhere that > can be accessed from a SQL statement on the server hosting your NS > applications. So, it can be in another database on the same server, or on a > linked server that you refer to using a four-part name. > > If your application is event-triggered, then you may need to submit some > "pseudo-events" that just serve as a kick to the NS application to perform > matching. These pseudo-events can simply be IDs that refer to rows in an > existing table elsewhere. > > Your match rule can have any of the following forms: > > --Local data > SELECT NotificationClassNameNotify(...) > FROM EventClassName e, Subscriptions s > WHERE ... > > --Data in another database > SELECT NotificationClassNameNotify(...) > FROM mydatabase.dbo.RealEvents events, EventClassName e, Subscriptions s > WHERE events.Id = e.Id AND ... > > --Data on another server > SELECT NotificationClassNameNotify(...) > FROM myserver.mydatabase.dbo.RealEvents events, EventClassName e, > Subscriptions s > WHERE events.Id = e.Id AND ... > > If you have a copy of my book > (http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/) you can see an > example of this. My MusicStore application simply uses SongIds to refer to > Song data in another database. > > Hope this helps. > -shyam > >
Great! Thanks for the great responses. Shyam, I have you book ... it
is a great resource for getting started in SQL-NS.
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |