SQLNS v2.0 can probably handle what you're describing, but I don't
think it's going necessarily be a trivial development process. You'll
need to create custom event providers & custom delivery channels.
Do you have the option of upgrading to SQL Server 2005? If so, check
out Query Notifications as a possible solution. I think it's probably
a better technological fit for what you're trying to accomplish.
If you're constrained to SQL Server 2000 and want to pursue the SQLNS
route, keep posting questions/comment/etc.
SQL Server MVP
Get up to speed quickly with SQLNS
I support PASS, the Professional Association for SQL Server.
On Fri, 6 Oct 2006 12:15:02 -0700, MobileMan
<[email protected]> wrote:
>Thanks Joe ... this is pretty close to what we're looking for - great
>Let me ask you if there's a way to take SQL Server 2000 and have it send out
>"notifications" to an application that we would create that simply listens
>for these (or "events" in the sense of the word like .NET programatic events
>used to indicate something has happened, such as a user clicked a button, a
>Form changed size, or a communications channel was closed, as quick
>Instead of each table firing a trgger which adds a row into a "notification
>table" for each added/modified/deleted row (as described in the article), and
>then our program "polling" the notification table to determine what happened
>... what we're attempting to do is create an application that is smart enough
>to tell us a row of data changed, instead of the application having to poll
>the DB. For performance reasons we're hoping to find a way to stay informed
>of database changes, but without polling. These notifications could be in
>the form of e-mails, which was mentioned in the SQL 2005 documentation I
>read, but we'd prefer for the notfication to be in the form of an actual
>"event" to keep performance at the highest level possible.
>Perhaps we'd have to create an application that resides of the SQL 2000 box,
>that would listen for these notidications or events, then our "listening
>applicaiton" could fire real .NET events from the SQL 2000 box to our other
>application which is interested in these changes of data????
>Forgive my silly ideas - we're just trying to determine how best to
>I would love to hear your thoughts about what I've written here. Again,
>thanks for you help with this Joe,
>Markus Anderson (a.k.a the Moble Man)