Not that I've ever done this but what about using a trigger on the table then e-mailing the updates (directly out of SQL) to a distribution list. You can, I believe, also send SMS messages.

Cheers, Peter

Sorry I don't have anything to offer as a solution, but I am also intered in the replies since I do have the need to handle this kind of auto-update feature. 

And one of the situation is when sending an update out to a multi-user location, that update should check the database to see if it needs to be updated and then update all clients as well.

On my VFP projects I have logic in place using StoneField Toolkit to update the metadata and used the .EXE version to keep track of those updates.

When we first played with notification services I was quite excited and thought that this would be a great solution for a lot of things...but there are a number of potential issues that come with using notification services.  The first is, you must have a direct connection to the server (i.e. ES will not support notification services, at least for the moment).  Secondly, you have to create a subscription for each query...so if you were to use this throughout the system as a blanket solution, then it could get "sticky." 

Let me give you a couple of ideas on how to address this.  The way we get around a lot of this is through our application server...which I would suspect that most of the applications that get created will not have this, but you can still use the same techniques that we did, just through the client side.

Let's take our Appointment Scheduling software.  In this case, we have a number of front desk people who may be booking and posting appointments.  Additionally, if patients are checking in from more than one location, the "signed-in" displays need to be updated, even if it didn't happen from the computer that I am on.  So we create threaded timers.  These have an incredibly small footprint and are asynchronous (you will want to do this versus using the component timer).  To create a timer it would look like this:

The above declaration would call the method MyCallbackMethod every 1 second...clearly this would be too often for performing some type of scalar method, but you get the idea.  The MyCallbackMethod would look like this:

OK...so once you get this setup and working the way that you like in regards to the timer, then you can begin to test on a state or count, etc.  You could also create a sproc that you call that performs a fair bit of logic if it is required and returns a single value telling you if something has changed and requires an update.  We have been doing this for a while and it works really well and with very little overhead.

No.  Remoting is really slow...so don't try to create anything that uses remoting as a base.  We actually created our own request and response objects (which you could just use HttpResponse and requests for that matter).

Correct...you would have to create subscriptions, etc...this could get hairy for async traffic.

They could really be one in the same in this respect.  You can even create a service that runs as your service (this is what we do).  We just have a service (not web service) that runs as our server.  You could create a TcpIP listener and server on a port that allows traffic to flow both ways.  This is a way to create a tunnel between your server and clients and gives you total control.

This type of approach generally presents a lot of issues...applications may die, power go out, etc. and then you have "junk" and orphan records lying around.  If you are going to try this approach, you are WAY better off creating sprocs and calling scalar methods.

FWIW we have somewhere in the neighborhood of 20 threaded timers in our server and application and it hasn't slown down a thing.  This includes the deployments in the field where we have some clients running on really crappy equipment and connections as well.  So this really comes down to how you design the query.  If you are calling a sproc on the SQL Server, the scalar method isn't going to choke anything down...it should be really fast, especially if you are polling on a 30+ second interval.