|
|
You're in the
sql server notification services
group:Receiving notifications from SQL Server 2000 that data changed?
sql server notification services:
added, deleted, or modified in another application? I'm a competent C# developer, but a "babe in the woods" when it comes to SQL Server. I have been reading about the Notification "engine" in SQL Server 2005 and am looking for something similar for a SQL Server 2000 setup. We have an application that uses SQL Server 2000 for data storage. When a new record is created or deleted, or an existing record modified we want to somehow "notify" another application of this fact. In a perfect world we would sent an "event" from SQL Server 2000 to the 2005 server, or even better to another application that is listening for events from the 2000 server. If our "listening application" can receive the event then we can handle things from there. Any suggestions or thoughts are greatly appreciated. Thanks for your advice. --
Something like this, perhaps?
http://www.c-sharpcorner.com/UploadFile/mosessaur/sqlcachedependency01292006135138PM/sqlcachedependency.aspx?ArticleID=3caa7d32-dce0-44dc-8769-77f8448e76bc -- 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 Wed, 27 Sep 2006 15:19:01 -0700, MobileMan [quoted text, click to view] <MobileMan@discussions.microsoft.com> wrote:
>What is the best way to be notified, from SQL Server 2000, that a row was >added, deleted, or modified in another application? > >I'm a competent C# developer, but a "babe in the woods" when it comes to SQL >Server. I have been reading about the Notification "engine" in SQL Server >2005 and am looking for something similar for a SQL Server 2000 setup. > >We have an application that uses SQL Server 2000 for data storage. When a >new record is created or deleted, or an existing record modified we want to >somehow "notify" another application of this fact. > >In a perfect world we would sent an "event" from SQL Server 2000 to the 2005 >server, or even better to another application that is listening for events >from the 2000 server. If our "listening application" can receive the event >then we can handle things from there. >
Thanks Joe ... this is pretty close to what we're looking for - great
article. 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 examples)??? 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 accomplish this. 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) -- Stay Mobile [quoted text, click to view] "Joe Webb" wrote:
> Something like this, perhaps? > > http://www.c-sharpcorner.com/UploadFile/mosessaur/sqlcachedependency01292006135138PM/sqlcachedependency.aspx?ArticleID=3caa7d32-dce0-44dc-8769-77f8448e76bc > > > -- > 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 Wed, 27 Sep 2006 15:19:01 -0700, MobileMan > <MobileMan@discussions.microsoft.com> wrote: > > >What is the best way to be notified, from SQL Server 2000, that a row was > >added, deleted, or modified in another application? > > > >I'm a competent C# developer, but a "babe in the woods" when it comes to SQL > >Server. I have been reading about the Notification "engine" in SQL Server > >2005 and am looking for something similar for a SQL Server 2000 setup. > > > >We have an application that uses SQL Server 2000 for data storage. When a > >new record is created or deleted, or an existing record modified we want to > >somehow "notify" another application of this fact. > > > >In a perfect world we would sent an "event" from SQL Server 2000 to the 2005 > >server, or even better to another application that is listening for events > >from the 2000 server. If our "listening application" can receive the event > >then we can handle things from there. > > > >Any suggestions or thoughts are greatly appreciated. Thanks for your advice.
BTW .... Just purchased your book from Amazon.
-- Stay Mobile [quoted text, click to view] "Joe Webb" wrote:
> Something like this, perhaps? > > http://www.c-sharpcorner.com/UploadFile/mosessaur/sqlcachedependency01292006135138PM/sqlcachedependency.aspx?ArticleID=3caa7d32-dce0-44dc-8769-77f8448e76bc > > > -- > 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 Wed, 27 Sep 2006 15:19:01 -0700, MobileMan > <MobileMan@discussions.microsoft.com> wrote: > > >What is the best way to be notified, from SQL Server 2000, that a row was > >added, deleted, or modified in another application? > > > >I'm a competent C# developer, but a "babe in the woods" when it comes to SQL > >Server. I have been reading about the Notification "engine" in SQL Server > >2005 and am looking for something similar for a SQL Server 2000 setup. > > > >We have an application that uses SQL Server 2000 for data storage. When a > >new record is created or deleted, or an existing record modified we want to > >somehow "notify" another application of this fact. > > > >In a perfect world we would sent an "event" from SQL Server 2000 to the 2005 > >server, or even better to another application that is listening for events > >from the 2000 server. If our "listening application" can receive the event > >then we can handle things from there. > > > >Any suggestions or thoughts are greatly appreciated. Thanks for your advice.
Hey THANKS! Hope you find it worth your while. I'd love to hear your
feedback, either here or on Amazon's reviewers section. Thanks again! Joe -- 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 Fri, 6 Oct 2006 12:25:01 -0700, MobileMan [quoted text, click to view] <MobileMan@discussions.microsoft.com> wrote:
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. http://msdn2.microsoft.com/en-us/library/t9x04ed2.aspx If you're constrained to SQL Server 2000 and want to pursue the SQLNS route, keep posting questions/comment/etc. HTH... Joe -- 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 Fri, 6 Oct 2006 12:15:02 -0700, MobileMan [quoted text, click to view] <MobileMan@discussions.microsoft.com> wrote:
>Thanks Joe ... this is pretty close to what we're looking for - great >article. > >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 >examples)??? > >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 >accomplish this. > >I would love to hear your thoughts about what I've written here. Again, >thanks for you help with this Joe, >
Yes, I agree. The development effort will probably be moderate to heavy.
What this is really all about is we have a desktop client that needs "live data" sent to it. Allow me to explain ... We are building an inventory system and the requirements call for the Management software to monitor inventory as it's being moved, consumed, and replentished. The user will pick a specific section of a warehouse and be able to watch "the numbers" change and people on the warehouse floor move inventory around. Because of this "live" data requirement we are trying to find the best way for the data to notify the client that it has changed. Of course, the other approach that we are trying to avoid is having the client application continuously poll the database to see if anything has changed? Possible on a small system, but on a large system this becomes very problematic from a performance perspective. So, this leaves us with the data being smart enough to inform us that it changed. I was reading a book on SQL 05 and found the info on NS .... this is perfect in theory ... and now because of you book (thank you very much by the way) we see this is possible on SQL 2000 too. We will have to develop a custom event and channel, though, because techniques like e-mail or SMS are simply too slow (not to mention all the unneccessary processing overhead that would be required just to update a GUI that a number changed). Frankly, what we're hoping for is something similar to .NET Remoting ... the data changed on the SQL box and we send out an event to the application. The application is listening for that event, and updates the appropriate item in our GUI upon receipt. A simple concept, but, as they say, "the devil is in the details" I know this will make for an interesting implementation. Just cracked the cover on your book - we're hoping everything we need to build this out will be discussed and exampled in your book. Are there any other sources that you would recommend for this information, or does your book cover it? Thanks Joe - we appreicate it your advice and help on this. -- Stay Mobile [quoted text, click to view] "Joe Webb" wrote:
> 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. > > http://msdn2.microsoft.com/en-us/library/t9x04ed2.aspx > > If you're constrained to SQL Server 2000 and want to pursue the SQLNS > route, keep posting questions/comment/etc. > > HTH... > > Joe > > > -- > 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 Fri, 6 Oct 2006 12:15:02 -0700, MobileMan > <MobileMan@discussions.microsoft.com> wrote: > > >Thanks Joe ... this is pretty close to what we're looking for - great > >article. > > > >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 > >examples)??? > > > >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 > >accomplish this. > > > >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)
I hope you find the book useful! It was designed to take someone with
general awareness of SQLNS to competence in a very short amount of time. I've had good feedback from it and plan to update it to v2005; although all of the concepts in the book already apply to 2005, the book doesn't depict the new things like Management Studio integration, etc. When writing it, I was contractually constrained to 160 pages. I ended up writing nearly 250 pages. After negotiations with the editor, the book ended up at 172 pages and the balance of the material ended up as bonus material in PDF format. Make sure you visit Rational Press' web site to down load it. I've also got a c# application that I've developed to create subscribers, subscriber devices, and subscriptions for any v2.0 instance on the machine. (With the enhancements to v2005, it's not needed so I haven't updated it. But it really helps in v2.0.) You can download it, source and exe, from my web site http://www.webbtechsolutions.com/downloads.aspx. Due to the length of the book I was not able to cover creating custom components (event providers, delivery channels) in the book. :( So you'll likely need to augment it a bit. Shyam Pather covers that aspect in his 600+ page book. Amazon for his name and you'll find it. HTH... and keep posting questions (and answers) in the newsgroup. Joe -- 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 Thu, 19 Oct 2006 06:08:02 -0700, MobileMan [quoted text, click to view] <MobileMan@discussions.microsoft.com> wrote:
>Yes, I agree. The development effort will probably be moderate to heavy. >What this is really all about is we have a desktop client that needs "live >data" sent to it. Allow me to explain ... > >We are building an inventory system and the requirements call for the >Management software to monitor inventory as it's being moved, consumed, and >replentished. The user will pick a specific section of a warehouse and be >able to watch "the numbers" change and people on the warehouse floor move >inventory around. > >Because of this "live" data requirement we are trying to find the best way >for the data to notify the client that it has changed. Of course, the other >approach that we are trying to avoid is having the client application >continuously poll the database to see if anything has changed? Possible on a >small system, but on a large system this becomes very problematic from a >performance perspective. > >So, this leaves us with the data being smart enough to inform us that it >changed. I was reading a book on SQL 05 and found the info on NS .... this >is perfect in theory ... and now because of you book (thank you very much by >the way) we see this is possible on SQL 2000 too. > >We will have to develop a custom event and channel, though, because >techniques like e-mail or SMS are simply too slow (not to mention all the >unneccessary processing overhead that would be required just to update a GUI >that a number changed). Frankly, what we're hoping for is something similar >to .NET Remoting ... the data changed on the SQL box and we send out an event >to the application. The application is listening for that event, and updates >the appropriate item in our GUI upon receipt. A simple concept, but, as they >say, "the devil is in the details" I know this will make for an interesting >implementation. > >Just cracked the cover on your book - we're hoping everything we need to >build this out will be discussed and exampled in your book. Are there any >other sources that you would recommend for this information, or does your >book cover it? >
Thanks Joe. We've gone ahead and ordered the books from Amazon. I
appreciate your help and advice on this. Thank you -- Stay Mobile [quoted text, click to view] "Joe Webb" wrote:
> I hope you find the book useful! It was designed to take someone with > general awareness of SQLNS to competence in a very short amount of > time. I've had good feedback from it and plan to update it to v2005; > although all of the concepts in the book already apply to 2005, the > book doesn't depict the new things like Management Studio integration, > etc. > > When writing it, I was contractually constrained to 160 pages. I ended > up writing nearly 250 pages. After negotiations with the editor, the > book ended up at 172 pages and the balance of the material ended up as > bonus material in PDF format. Make sure you visit Rational Press' web > site to down load it. > > I've also got a c# application that I've developed to create > subscribers, subscriber devices, and subscriptions for any v2.0 > instance on the machine. (With the enhancements to v2005, it's not > needed so I haven't updated it. But it really helps in v2.0.) You can > download it, source and exe, from my web site > http://www.webbtechsolutions.com/downloads.aspx. > > Due to the length of the book I was not able to cover creating custom > components (event providers, delivery channels) in the book. :( So > you'll likely need to augment it a bit. Shyam Pather covers that > aspect in his 600+ page book. Amazon for his name and you'll find it. > > HTH... and keep posting questions (and answers) in the newsgroup. > > Joe > > > > -- > 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 Thu, 19 Oct 2006 06:08:02 -0700, MobileMan > <MobileMan@discussions.microsoft.com> wrote: > > >Yes, I agree. The development effort will probably be moderate to heavy. > >What this is really all about is we have a desktop client that needs "live > >data" sent to it. Allow me to explain ... > > > >We are building an inventory system and the requirements call for the > >Management software to monitor inventory as it's being moved, consumed, and > >replentished. The user will pick a specific section of a warehouse and be > >able to watch "the numbers" change and people on the warehouse floor move > >inventory around. > > > >Because of this "live" data requirement we are trying to find the best way > >for the data to notify the client that it has changed. Of course, the other > >approach that we are trying to avoid is having the client application > >continuously poll the database to see if anything has changed? Possible on a > >small system, but on a large system this becomes very problematic from a > >performance perspective. > > > >So, this leaves us with the data being smart enough to inform us that it > >changed. I was reading a book on SQL 05 and found the info on NS .... this > >is perfect in theory ... and now because of you book (thank you very much by > >the way) we see this is possible on SQL 2000 too. > > > >We will have to develop a custom event and channel, though, because > >techniques like e-mail or SMS are simply too slow (not to mention all the > >unneccessary processing overhead that would be required just to update a GUI > >that a number changed). Frankly, what we're hoping for is something similar > >to .NET Remoting ... the data changed on the SQL box and we send out an event > >to the application. The application is listening for that event, and updates > >the appropriate item in our GUI upon receipt. A simple concept, but, as they > >say, "the devil is in the details" I know this will make for an interesting > >implementation. > > > >Just cracked the cover on your book - we're hoping everything we need to > >build this out will be discussed and exampled in your book. Are there any > >other sources that you would recommend for this information, or does your > >book cover it? > > > >Thanks Joe - we appreicate it your advice and help on this.
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 |