I would like to write C# code which would help me to query a database continuously.
If there is an entry made (not sure when will the entry be made) to a database by some source, it should be processed by my code. (Simply, my code should always monitor the database for an entry).
You basically have two main options.
Firstly, you can add an extra column to your table that is a bit field, perhaps called "HasBeenProcessed". You can then schedule checking for any columns whose HasBeenProcessed is 0. Processed that, then update the column to be 1.
Alternatively, you can look at this StackoverFlow post that describes using the SqlDependency class to have an event raised when a resultset appears differently.
If you are using SQL Server 2008 R2 or SQL Server 2012, you can use StreamInsight to setup events against data changes and patterns. If you are using a previous version > 2005, you can use Notification Services (although StreamInsight is far superior and essentially supercedes Notification Services).
Add a WebService to your code.
Add a insert & update trigger to your table.
Create a CLR function that you can call from the trigger.
In that CLR function, call the webservice with all necessary data.
In the webservice, do whatever you need to do based on the passed parameters.
Add a configuration table, and enter the webservice URL.
Pass the url as argument to your CLR function.
You should call the webservice asynchronously, so the delay is minimized.
Note:
I think it's also possible to call a web-service from pure SQL, so there's not necessarely a need for the CLR.
What are you trying to accomplish? If it's keeping a relatively static but still possibly changing data set (e.g. list of vendors) up to date in a cache, Simon Whitehead's proposal of SqlDependency will serve you well. If it's processing something more akin to requests (e.g. orders), service broker with activation, either internal or external, should be a good fit. Either way, the point is don't have your code constantly going to the database saying "is there something for me?". Instead, have the db tell your application when there's something to do and act accordingly.
Related
I am wondering if there is any provision in c# ASP.NET like: when ever status column in Database was changed I'd like to call a method.
Suggest me some ideas except call the database for every 1 minute or 1 sec something like. And you can suggest me is there any chances to do this from SQL, jQuery.
You can use Service Broker in SQL Server to receive notification in C#. Basically it adds the information in the queue which is read by the C# Code.
https://blog.sqlauthority.com/2009/09/21/sql-server-intorduction-to-service-broker-and-sample-script/
Another way is to use SQL table dependency
https://dzone.com/articles/receive-notifications-with-new-values-when-table-r
This might seem like an odd question, but it's been bugging me for a while now. Given that i'm not a hugely experienced programmer, and i'm the sole application/c# developer in the company, I felt the need to sanity check this with you guys.
We have created an application that handles shipping information internally within our company, this application works with a central DB at our IT office.
We've recently switch DB from mysql to mssql and during the transition we decided to forgo the webservices previously used and connect directly to the DB using Application Role, for added security we only allow access to Store Procedures and all CRUD operations are handle via these.
However we currently have stored procedures for updating every field in one of our objects, which is quite a few stored procedures, and as such quite a bit of work on the client for the DataRepository (needing separate code to call the procedure and pass the right params for each procedure).
So i'm thinking, would it be better to simply update the entire object (in this case, an object represents a table, for example shipments) given that a lot of that data would be change one field at a time after initial insert, and that we are trying to keep the network usage down, as some of the clients will run with limited internet.
Whats the standard practice for this kind of thing? or is there a method that I've overlooked?
I would say that updating all the columns for the entire row is a much more common practice.
If you have a proc for each field, and you change multiple fields in one update, you will have to wrap all the stored procedure calls into a single transaction to avoid the database getting into an inconsistent state. You also have to detect which field changed (which means you need to compare the old row to the new row).
Look into using an Object Relational Mapper (ORM) like Entity Framework for these kinds of operations. You will find that there is not general consensus on whether ORMs are a great solution for all data access needs, but it's hard to argue that they solve the problem of CRUD pretty comprehensively.
Connecting directly to the DB over the internet isn't something I'd switch to in a hurry.
"we decided to forgo the webservices previously used and connect directly to the DB"
What made you decide this?
If you are intent on this model, then a single SPROC to update an entire row would be advantageous over one per column. I have a similar application which uses SPROCs in this way, however the data from the client comes in via XML, then a middleware application on our server end deals with updating the DB.
The standard practice is not to connect to DB over the internet.
Even for small app, this should be the overall model:
Client app -> over internet -> server-side app (WCF WebService) -> LAN/localhost -> SQL
DB
Benefits:
your client app would not even know that you have switched DB implementations.
It would not know anything about DB security, etc.
you, as a programmer, would not be thinking in terms of "rows" and "columns" on client side. Those would be objects and fields.
you would be able to use different protocols: send only single field updates between client app and server app, but update entire rows between server app and DB.
Now, given your situation, updating entire row (the entire object) is definitely more of a standard practice than updating a single column.
It's better to only update what you change if you know what you change (if using an ORM like entity Framework for example), but if you're going down the stored proc route then yes definately update everything in a row at once that's way granular enough.
You should take the switch as an oportunity to change over to LINQ to entities however if you're already in a big change and ditch stored procedures in the process whenever possible
I'm working with C# and Microsoft SQL Server Express 2008. The table will be populated by a remote hardware so i don't have control over SQL command for the insert. Can I set SQL server to generate an event on insert catchable in C# (or other .NET) application?
There are many ways to do that if i would you then i will do something like....
Write insert Trigger on that table and in that trigger call exe
For example :
declare #sqlcmd varchar(200)
SET #SQLCmd = 'c:\dba\sampl_2.exe'
EXEC master..xp_cmdshell #SQLCmd , no_output
and in that exe you can handle whatever you want...
Probably you are looking for: SqlDependency class.
But as far as I remember SQL Server Express does not support SqlDependency features.
If so, I would create one more column, something like "IsProcessed" and once the app processes the row set it to true or something. By using this approach you can query the table using where clause: where IsProcessed is null.
There are several options to do something like this. It's easy to set up an insert trigger in SQL that effectively fires an event during which you can carry out any number of tasks: send a message, write to another table, write to a log. etc.
For me, the question is how best to you get your C# program to "listen" for this trigger event.
One option might be to set up a little WCF program as as listener that responds to messages sent by SQL server when the insert trigger fires. Here's a link to a CodeProject piece about doing something like that.
http://www.codeproject.com/Articles/21149/Invoking-a-WCF-Service-from-a-CLR-Trigger
It's interesting how this kind of question emerges on SO from time to time. And there is still no explicit unique answer that can be given in all situations.
Actually, the question asks on how should a multiple-insert-event be captured in SQL server for a particular table. I hope it is a particular table, because in SQL Server itself there isn't a method to listen DML changes to all tables (something like * from tables) at once. If you want, you can create N triggers (it could be done e.g. using dynamic SQL) on N tables and listen to these, but what if a new table gets added?
Let's think we have a specific table MyTable where we would like to listen for INSERT, UPDATE and DELETE events. One way to do it is implementing a trigger (speciffically AFTER trigger, since INSTEAD OF triggers are not made for this case). Another option is a query notification. But which one do you really need?
Query notification implies that you have to code .NET application. Trigger implies all that is trigger-related: you can have TSQL code, you can even call a web service from your database using CLR trigger. But - what do you need?
So, if you really need to react in the way to just write a log record in a table, use plain old trigger. Otherwise you should think: why do you need really need C# application here?
For example, say you need to catch a delete statement and serialize all deleted rows in XML format to the file system in a file. I would use CLR trigger in EXTERNAL_ACCESS mode to be able to create file and save information to disk.
I have ERP database "A" has only read permission, where i cant create trigger on the table.
A is made for ERP system (Unknown Program for me ). I have another Database "B" that is private to my application this application work on both databases. i want to reflect A's changes(for any insert/Update/Delete) instantly to B.
Is there any Functionality in c# that can work exactly as trigger works in database???
You have few solutions, best one depends on which kind of database you have to support.
Generic solution, changes in A database aren't allowed
If you can't change master database and this must work with every kind of database then you have only one option: polling.
You shouldn't check too often (so forget to do it more or less instantly) to save network traffic and it's better to do in in different ways for insert/update/delete. What you can do depends on how database is structured, for example:
Insert: to catch an insert you may simply check for highest row ID (assuming what you need to monitor has an integer column used as key).
Update: for updates you may check a timestamp column (if it's present).
Delete: this may be more tricky to detect, a first check would be count number of rows, if it's changed and no insert occured then you detected a delete else just subtract the number of inserts.
Generic solution, changes in A database are allowed
If you can change the original database you can decrease network traffic (and complexity) using triggers on database side, when a trigger is fired just put a record in an internal log table (just few columns: one for the change type, one for affected table, one for affected record).
You will need to poll only on this table (using a simple query to check if number of rows increased). Because action (insert/update/delete) is stored in the table you just need to switch on that column to execute proper action.
This has a big disadvantage (in my point of view): it puts logic related to your application inside the master database. This may be terrible or not but it depends on many many factors.
SQL Server/Vendor specific
If you're application is tied to Microsoft SQL Server you can use SqlDependency class to track changes made. It works for SS only but I think there may be implementations for other databases. Disadvantage is that this will always bee specific to a specific vendor (so if A database will change host...you'll have to change your code too).
From 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.
Anyway if you're using SQL Server you have other options, just follow links in MSDN documentation.
Addendum: if you need a more fine control you may check TraceServer and Object:Altered (and friends) classes. This is even more tied to Microsoft SQL Server but it should be usable on a more wide context (and you may keep your applications unaware of these things).
You may find useful, depending on your DBMS:
Change Data Capture (MS SQL)
http://msdn.microsoft.com/en-us/library/bb522489%28v=SQL.100%29.aspx
Database Change Notification (Oracle)
http://docs.oracle.com/cd/B19306_01/appdev.102/b14251/adfns_dcn.htm
http://www.oracle.com/technetwork/issue-archive/2006/06-mar/o26odpnet-093584.html
Unfortunately, there's no SQL92 solution on data change notification
Yes There is excellent post are here please check this out..
http://devzone.advantagedatabase.com/dz/webhelp/advantage9.1/mergedprojects/devguide/part1point5/creating_triggers_in_c_with_visual_studio_net.htm
If this post solve your question then mark as answered..
Thanks
I am in the process of creating a friendlist using ASP.NET/C# and MSSQL 08. Simple datalist that lists the profile image and name of my friends.
Next to the name, I have a label showing current status of my friend. Like for instance, Online, Offile, Away etc.
My question is, how can I change the value of this label, without having a timer that calls the database all the time asking for the current status?
I would like to have the database (sql server 2008) tell me when a change as occured and tell my business logic to update the status label.
Is this possible?
Thanks!
To accomplish what you are looking for.. And this is just how I would do it, is to create a view based on the table with only the items that are needed to accomplish the task.. For instance, UserID | Online_Status.. Then using AJAX, make a call. It would be so small to the user that they would not even notice the bandwidth usage/processing... etc..etc...
This is pretty much exactly what you said you didn't want, but even if you had 1 million users and space them like 3-5 minutes apart.. You should be ok considering it would take milliseconds to perform the check.
Just my two cents..
I don't think you should do it like that. There are techniques to do this using comet but it will consume a lot of resources from your server clearly reducing the number of users that can access your site/app. The problem is that the the server and client needs to have a socket open for the server to be able to push data to the client.
What I would do is to have the client ask if there are any updates, keeping the payload to a minimum. If the server says there is data that changed the client makes another request to get that data.
You could use the SqlDependency class to get notified when the result of a database query changes.
There is an excellent article on MSDN explaining the SqlDependency class.
To use the SqlDependency class in the context of ASP.Net consider the strategy explained in the following video of MIX 2011.
Hope, this helps.
I believe this is what for the SqlCacheDependency is designed for. If you are using SQL Server 2005 or higher*, it implements a push-notification model from SQL Server to your application to notify you of when a change occurs in your dataset. So each time the cache is invalidated you can get the latest data, but until then it was just will read from your cached dataset and save a trip to the database. The documentation for it is here.
*However*,
As stated in the comments and such, this isn't really what SQL Server is designed for at its core, and I don't know to hand actually how efficient this solution is. If I understand your problem correctly, you would need a cache dependency PER USER which could very well be completely unscalable using this solution. Rather than second-guess what is going to be the most efficient solution, you really should develop, test, measure and find out for yourself. Every situation is going to be different, there is no "right way".
* In Sql Server 2000 and 7 it uses a pull-model.
All options given to this moment are valid ones and that's how most websites do it today; however, the OP is asking for some sort push notification mechanism as opposed to pull, and I think for that kind of thing, websockets are the way to do it.