Rather than poll against some tables, I'd like to signal a waiting c# app that there are new rows to be processed in a table, maybe via a trigger. Is there some way for the database to signal to a console app, or am I stuck polling the table looking for new rows?
Take a look at Query Notifications (SQL Server 2005+).
Microsoft SQL Server 2005 introduces
query notifications, new functionality
that allows an application to request
a notification from SQL Server when
the results of a query change. Query
notifications allow programmers to
design applications that query the
database only when there is a change
to information that the application
has previously retrieved.
There is an example here of how to write a simple form app to register a query for notification: http://msdn.microsoft.com/en-us/library/a52dhwx7(VS.80).aspx.
This does require the Service Broker to be enabled on the database.
You should take a look at the notes in the Remarks section of the MSDN SqlDependency documentation to make sure it is the right choice for your scenario
Check if SqlCacheDependency can be of any use...
http://www.asp.net/data-access/tutorials/using-sql-cache-dependencies-cs
If it is SQL Server 2008, You can use Event-Based Activation using Service Broker as well.
I have used WCF with SQLCLR to get data from another process into SQL, worked pretty good apart from some minor quirks to set it up. So you can just call other processes from SQl this way. It's usually quite hard to deploy to customers though, DBA don't like this sort of stuff.
GJ
Check out SQL Service Broker. Using a Queue and the WAITFOR syntax I have changed a custom polling service into a blocking/signal service. You could also look at the event-activation. Either way this would allow for a transactional way to call your external program in a non-polling async way that will not slow down triggers and database locks.
Related
I have a stage table which is like a queue, data keeps coming to this table.
Can I write a window service runs continuously and read data from queue table and apply some business logic on the records, for this approach could you please share some code link, etc?
Or should I consider SQL Server Service Broker?
Please suggest?
If you use a table as a queue, then use a table as a queue. I recommend you read Using tables as Queues.
I do not recommend using Service Broker unless you need activation. Service Broker is designed for distributed applications and comes with significant overhead when compared with a simple queue table (conversations, services and contracts etc).
I have a Windows service that currently outputs logging activity to either a text file or a database (depending on the activity). What I would like to do is to have a way to run another process (probably an executable) that can connect to that service and receive activity updates from that Windows service using like a publish/subcribe approach.
In theory, I guess this can be done by hosting a socket connection on the Windows service and pushing activity data as it happens. I wonder though if there is s better approach? Is there maybe a framework that can do all this for me easily? Or maybe I should use a MQ product to broadcast the application activity?
I am using C# .net version 4.5
There are several ways:
Socket is very good two-way communication
WCF is also another option, also two way communication support
Database - if you need to keep the history of the signals, you probably use one table where server/host inserts into a table and client reads from table using SQL Dependency. You can read new signals without timer or waiting, almost in real time.
Another good option is SignalR.
I have been using all technologies except WCF.
I have a server and 'x' number of clients.
When the server is listening for an inbound connection, it will create a client handler instance (a class that manages the client communication) which will be spun off in a separate thread.
Depending on the command the client sends to the server, the server may need to access a SQL database to store information about that client.
The client handler instance will 'handle' this request. The only problem is, if multiple client handlers are wanting to access the SQL database to do the exact same thing then there is potential for read / write issues.
I was thinking about exposing a static method on the server, calling it from the client handle instances, then locking the function which accesses the SQL database (either read or write).
Is this a good approach or are there better approaches?
Thanks.
Well, you DO know that SQL has locks and a ton of internal mechanisms to serialize access? That this is part of the ACID conditions ingrained in SQL since the 1950's when SQL was created? That the locking mechanism in SQL is very very fine and basically you try to solve a problem that has been solved more than 60 years ago.... because it seems you need to read a book about the basics of SQL.
Under normal circumstances (standard connection string) resource access is serialized in SQL Server (TransactionIsolationLevel serialized), but that can be tuned. I really suggest learning some SQL fundamentals.
I m developing a C# database application. I used SQL Server 2005 as back end and C# .NET 2010 as front end.
My application is installed on each client machine. When database is updated all clients of my system get notified By SQL Server Event Dependency technique.
But now I want to control the number of clients connected to server. That is I only want to give access to 3 clients. For that, I want to add some client/Server code in my application using socket programming.
Please guide me on this issue.
From the SqlDependency Class on MSDN:
SqlDependency was designed to be used in ASP.NET or middle-tier services where there is a relatively small number of servers having dependencies active against the database. It was not designed for use in client applications, where hundreds or thousands of client computers would have SqlDependency objects set up for a single database server. If you are developing an application where you need reliable sub-second notifications when data changes, review the sections Planning an Efficient Query Notifications Strategy and Alternatives to Query Notifications in the Planning for Notifications topic in SQL Server Books Online.
In your particular scenario, I guess it would be a good idea to have a middle layer server which manages the client machines and which will use the SQLDependency to be notified by the changes in the database. Then, it will push notifications to batches of n client machines, following the logic you expect.
I have a REST web service that is used for comunication with multiple clients, some sort of chat, but I have to make all the changes into the database as soon as the clients comunicate something and then inform all the others clients when a change is made.
I basically get a POST request and I have to reply as soon as an entry is mofified.
Now I make my thread sleep 1 second and then keep recreating the context every second for each request and if there are changes to the database I send the response.
This looks ugly to me and I wonder if there is some event or async method to be notified when a specific entry in the database is modified?
Thank you Advance.
If you're using MS SQL Server, you might have success with using Sql Dependencies. Here's a link to a brief tutorial: C# & SqlDependency - Monitoring your database for data changes.
Microsoft's successor to Notification Services, SQL Server 2008 R2 – Complex Event Processing (CEP) Technology might also serve your purposes, but I know nothing about it but what's on the web page.