5

SQL Server Query Notifications is a great tool, but it doesn't seem built to scale very well. Every application that wants/needs notifications has to keep an open connection to the database for the duration of the time it wants notifications (typically the entire time the application is running).

I am open to creative solutions. Off the top of my head I just thought of putting a service on the server that would subscribe to SQL Server Query Notifications which could then notify the client applications. In this case you have only 1 database connection open (and why not just leave it open all the time), and then your client applications could just subscribe to the service for notification.

Ideas??

richard
  • 12,263
  • 23
  • 95
  • 151
  • What problem are these open database connections causing you? – Damien_The_Unbeliever May 11 '11 at 06:39
  • Well none really. In my case it doesn't matter. I currently don't have more than 20 users on at a time. But I could conceivably have up to 350 (if everyone at the client is using the application at the same time). But really, I just want to know so I have another trick in my bag. And if there is a scalable alternative, I will use that instead since it's better to be safe than sorry. :-) – richard May 11 '11 at 06:42
  • How about creating a service that feeds the client applications the data? That way only the service needs the active database connection, and you have more options for scalability in client-server connections. – IAmJersh Feb 06 '19 at 09:57

1 Answers1

-1

You may want to look into building your own solution using SQL Server Service Broker and db_mail or external activators.

Michael
  • 34
  • 1
  • 1
    That's a neat idea. So something like having SQL server send an email to an email address that gets processed by a .NET app? – richard May 14 '11 at 08:04