Polling for database changes: SqlDependency, SignalR is Good

Question

it will be good if i need to show change data in db through sql dependency and signalr. suppose my transaction table often changed by many people. suppose in few second data

Answer 1

SQL Change notification works for "changed data returned by the query". This means - if you query for a job with ID=3 - only changes to this record will trigger the notification.

here are good explanations about this: SqlDependency OnChange Not Firing

The thing is - in the sample the app wants to get informed if "any" record in the table gets changed. This works so far - and (in the link above point 1 in the answer) the event fires ONCE.

To retrigger this again you have to submit the query once more. This is what the sample does - it again fetches all the data.

A possible solution (to achieve what you request) is:

A. trigger the request by a call to get data --you don't have to display the results on the client - just execute the query.

B. when the event fires - make the query again - (not sending the data to the client)

C. you can use an other (extra) query to find out what happened or just use the result from B for this

D.) send the information out with signalR

To get the changes YOU have to find a way to compare the data since the only information SQL Server provides is that "Something happened" (and what) - but not which records were affected.

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlnotificationinfo(v=vs.110).aspx

The other problem with the sample (I just guess) is that if you have multiple clients listening - each client will "retrigger" again - this could (I'm not sure) in a lot of subscriptions to the event.

So the next time it will fire multiple times - resulting in multiple requests...

So to extend the above sample you should (additional to the above steps):

1.) Change GetData that it does not retrigger again if a subscription is already made

2.) Provide an extra function that informs the clients about the changes --some kind of "seen by clients" flag --a changes clears this flag (trigger) - the notification clears it

3.) change your database schema that you can easily find changed records --some extra table to hold deleted records in the case you will show what was deleted

A different approach (not using SQLChangeNotifications) would be to hold CLR code in the database. This code could call the hub which notifies the clients. But such a solution depends on several factors.

a.) can a signalR client be run inside SQL Server

b.) does your policy allow that the DB server talks to the web server

c.) does your policy allow SQL CLR integration

e.)....

The second approach looks easier for me since you can trigger the send from a SQL CLR Trigger. This enables you to send the changed data without "extra columns" and "deleted element" tables.