I work on a Delphi program that uses a firebird database to store it’s data. It uses a home grown o.r.m. system. When two users look at the same data, for example in a data grid, and one changes something the other screen gets updated immediately.
The way this works is that the objects in the one program store them self’s in the database. The database has a trigger that registers this change in a auxiliary changes log table. Writing to this changes log table triggers an event. The second program is listening to that event and knows from the entry in the changes log table what object was changed. It will reload that object and raise an event internally in that program. This event will cause all screens that are showing this object and all objects that base their behavior on this object to update.
We would like to switch to .Net and maybe MS SQL.
My question is:
1) How do I do this with MS SQL?
2) Is there a framework that supports this? So I won’t have to port this to .Net
Since the .Net Framework 2.0 and MSSqlServer 2005 versions there is support for change notifications: using the SqlDependency class. You have an example in the codeproject.
Take also a look to some recommendations about using notifications in the msdn.
doesn't sound like this would be too difficult to implement in c#.
try using the "observer pattern" with whatever custom modefications you'd like.
Related
I am working on an assignment to monitor and log various "system-level messages” within our multi-tier .NET 4 WPF, WCF, SQL 2008 application. By messages, I mean details about an event that has occurred in our application, e.g. user logs in and out or data is saved. By logging, I mean that we will be inserting messages into a light-weight SQL table from which clients can poll and display the latest messages.
The source of these messages could come from several different components in our application e.g. Windows Services, WCF Host in IIS, and even stored procedures in the Database. Ultimately these components modify SQL tables each in their own way. So rather than attacking each of these components independently, I’m thinking I might be able to simplify things by saying that the messages need to be “triggered” when certain tables in SQL are modified (updated, inserted).
The first thing that comes to mind would be a trigger on each of the tables which monitor changes and insert records into the light-weight message table. I’ve always (99% of the time) been of the mindset that database triggers are bad news (Are database triggers evil?). And I would personally much rather develop and debug C# than a SQL trigger.
So, in the pursuit of alternatives, I’ve come across Using SqlDependency to Monitor Database Changes which discusses using the SqlDependency class to detect changes. A quick proof of concept seems to work; however, after looking at several code samples, it looks like with each change that’s detected, new SqlConnection, SqlCommand, and SqlDependency objects will have to be reinitialized and I will probably need 3 or 4 queries that will need to be monitored.
Are there better options to detecting changes to SQL tables in C#?
Also, trigger bias aside, this seems like round-about way to simply monitor changes in one set of tables just to re-insert data into another table. There will be some other logic that will need to take place that I would rather implement in C#, but should I just write triggers to do this and be done with it?
Thoughts?
I think your bias against triggers in general is unfounded. People look down upon triggers for the same reason they look down on cursors: in many cases, they are misused and abused. But like a lot of things they certainly have their place and, when used correctly, are the right answer.
There are some other native technologies you should look into:
Change Tracking
http://msdn.microsoft.com/en-us/library/cc280462(SQL.100).aspx
Change Data Capture
http://msdn.microsoft.com/en-us/library/bb522489(SQL.100).aspx
SQL Server Audit
http://msdn.microsoft.com/en-us/library/cc280386(SQL.100).aspx
Though I don't know your edition (some of these are Enterprise features). Some 3rd party solutions exist as well (I haven't used any so I'll leave it up to you to search / research).
We have a process that needs to fire when a change occurs to a specific database table in Oracle. At the moment a similar process has been developed using triggers and a bunch of subsequent database actions that occur when that trigger is fired.
However, in this solution we want to call a .NET component (most likely a service) when the change occurs to a row or bunch of rows in a database table. Now, you could implement a polling mechanism that will check the table at regular intervals for those modifications and then instantiate the service when it finds any. However, I would prefer a more event driven approach.
I assume this is something that has been done elsewhere so I was wondering what approaches other people have used for dealing with such requirements?
Thanks in advance
Edit: The process that fires when a change occurs to the underlying data is essentially a call to an external web service using some of the related data. I am beginning to think whether this call should occur as part of the same process that is submitting the data into the database, rather than being triggered by the data change itself.
You should look at Oracle Database Extensions for .NET.
From the linked article:
Oracle Database Extensions for .NET provides the following:
A Common Language Runtime (CLR) host for Oracle Database
Data access through Oracle Data Provider for .NET classes
Oracle Deployment Wizard for Visual Studio .NET
You would still use triggers to detect the db changes but instead of firing all the db-side logic you describe you would now be able to execute that logic from a .NET module.
If you are using Oracle's .NET driver, you can use Oracle Continuous Query Notification (CQN) to do that.
You just give it a normal SELECT query, and it will fire a callback in your app whenever the resultset for that query changes.
The one caveot I know of is that when it initially runs the query to subscribe for continuous notification, it momentarily requires an exclusive lock. Usually its not a big deal since you just evecute it once at startup, so any other DB queries on the same table will be blocked for a fraction of a second.
It sounds possible but will likely take some leg work. I think you want to look into the Oracle Access Manager
http://download.oracle.com/docs/cd/E12530_01/oam.1014/e10355/toc.htm
This is similar to Paul's; but does not assume that you have Oracle installed on a Windows machine.
You may use dbms_scheduler to create a job that will call your external process.
You may directly call an remote external job from Oracle (this requires Oracle Scheduler Agent to be installed but nothing else)
it requires a bit of leg work to get the authentication set up and such, but this works.
then you utilize an event to start your job(called from your trigger).
This way, you may actually be able to utilize a lot of what you already have coded and just have the oracle scheduler to handle the rest.
Oracle provides two mechanisms to deal with what describe in a rather nice way... on the DB side you implement triggers for detecting the changes or whatever should result in an action on the .NET side...
For the communication you use a publish/subsribe mechanism based on the Oracle built-in queueing technology (called Advanced Queueing Technology, AQ) - for a nice example see http://www.devart.com/dotconnect/oracle/docs/AQ.html (not affiliated, just a happy customer).
Another option is to use built-in DBMS_ALERTER package for communication which is transactional and asynchronous - see for an example http://www.devart.com/dotconnect/oracle/docs/Devart.Data.Oracle~Devart.Data.Oracle.OracleAlerter.html
Just to be clear:
the above technologies (DBMS_ALERTER and AQ) are Oracle built-in ones, not specific to any 3rd-party libraries... you just need an ADO.NET provider supporting them...
EDIT - after the EDIT from the OP:
If you have control over the code or the call to the code that triggers the data change (WebService?) then it is indeed the best way to deal with it is purely on the .NET side of things... this also helps to deal with situations where such a change runs into an error etc.
I'm wondering what the best way to implement this would be.
Basically our project has a requirement that any change made to records in the database should be logged. I already have it completed in C# using Reflection and Generics but I'm 100% sure that I used the best method.
Is there a way to do this from inside the SQL database?
The big key is that the way our project works, the ObjectContext is disconnected, so we couldn't use the built in Change Tracking and had to do our own compares against previous Log items.
If you're using SQL Server 2008 or higher, you can implement either change tracking or change data capture directly on the database. Note that the latter is only available in the Enterprise edition engine. There are pros and cons to each method. You'll have to review each solution for yourself as there isn't enough requirement information to go on in the question.
If you're using SQL Server 2005 or below, you'll have to resort to a trigger-based solution, as suggested by the other answers.
You want to look at database triggers.
depending on the complexity of your datamodel you could setup on update/insert/delete triggers on the relevant tables - these triggers could log whatever is needed (old/new values, User, timestamp etc.)... see http://msdn.microsoft.com/de-de/library/ms189799.aspx
Look at my blog to see how you can track data changes without database scheme modification:
part1,part2
For your project requirement, SQL trigger is the better solution than the current C# reflection. Becaz triggers provides a way for the database management system to actively control, monitor, and manage a group of tables whenever an insert, update, or delete operation is performed. More over, the requirement is full filled at DataBase layer itself and so hosted as the single solution for various front end applications.
I was wondering how to monitor a database for changes programmatically.
Suppose I want to have a .net application which would run after every 100th or(nth) row insertion or row deletion or updation . how can it be achieved?
I know little about triggers.they can be used to fire executable.
But I heard that it isn't a good practice.
Is there any other way?
2]Do database fire events on table updations? and can they be caught in a program?
3]Can SQL reporting services be used here?
(Also assuming that this application is independent from the actual program which does
database manipulation.)
SQL Server 2005 introduced 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.
Check out the MSDN link for more clarity
and sample immplementation
A trigger is really going to be your only way unless you aren't concerned about the accuracy of "100th" or "nth".
The answer to 2 and 3 are no.
You can write managed stored procedures (MSDN example) but that doesn't help you here really. In general triggers can be bad practice since they can block the initial caller but sometimes they are the only solution.
I think you need to question your requirement to place this low-level data monitoring in a separate application. Think about where your data changes could originate -
Do you have full understanding of every:
stored proc within your db (now and future) and which ones update this table?
application that may hit your database (now and future)
If not, then watching the changes right down at the data level (ie within the db) is probably the best option, and that probably means triggers...
Read about "Service Broker" at http://msdn.microsoft.com/en-us/library/ms166104(v=SQL.90).aspx
The requirement is to track all changes made to an entity, track it to know who did it, when he did, etc. For example, I have a Person entity, and a user has changed the name of the person; I'd like to keep that information somewhere.
What's the best approach for this? Or is there an existing framework to achieve this.
I know that SQL 2008 has support for tracking changes, but it's not an option for now, because a lot of our customers are already using SQL 2005.
Is the Logging Application Block of Enterprise Library a good candidate for this requirement? I've check it out a little bit but, I don't see how I can use it to track the who did it, what value has change, when he did it, etc.
We are using C# and .NET framework for our app.
Standrad way is to use events from INotifyPropertyChanging and INotifyPropertyChanged interfaces. And for collections INotifyCollectionChanged. Once you subscribed to this events you can store information wherever you want.
If you using MSSQL you can try Query Notifications
Some sort of AOP solution (like the one in enterprise library) should provide you with enough possibilities to create such a solution.
You can subscribe to a property-invoke method and log the information.