my name is Tayyeb, I have recently finished my course in SQL Server 2005. I am currently working as a Windows System Administrator.
I am a newbie to databases, my question is that we have a database and if a table gets updated then I'd like to receive an email saying what has been updated.
Can anyone help me on this solution?
Thanks in advance
You would want to setup insert and update triggers on the table and have them call the msdb.dbo.sp_send_dbmail stored procedure.
Create a table that stores the datetime for the last update in that particular table.
Set up a trigger for your table that updates the datetime on an update.
Have an external application poll the datetime at a regular interval, and if it is changed, send an e-mail.
Using a trigger is a given. Either solution, DBMail or a polling process, will work. If you go with a polling process, go ahead and make the polling interval something you can change while the polling process is running, if possible. The problem you are going to run into is if you want to test or debug it, you won't want to wait the full polling interval. If the interval is 5 minutes, you either have to restart the poller or have a separate polling interval just for checking if the polling interval changed (can we say recursive?). So write the poller with debugging/testing in mind.
That might be enough to convince you to use the DBMail solution. I've never used it so others will have to speak to that.
Related
I'm optimizing a legacy application and only have access to the database, not the UI code.
There is a specific table insert occurring that I need to catch, so I can do some additional processing, but without adding any obvious lag.
I'm thinking of adding an INSERT trigger which places an entry on a queue, so that processing can continue after returning.
SQL queues using the Service Broker seem to require a 2-way conversation, therefore 2 queues. I don't need this so another possibility could be to use a table as a queue.
But, if I use a table, is there a way for entries to be processed very soon after they arrive, as would be the case with a Service Broker SQL queue? Is the only option to have checks running at a scheduled period? This would be a pain if I need to add more.
A trigger on that "Queue" table would also not be a great idea as it would add to performance lag.
Of course I could always just ignore the response queue, but that doesn't feel right.
I have a desktop application which has the "Alarm" feature. The way I'm thinking to implement is that when user selects the data and time for alarm it gets stored in the database and my application query the database every second and match the current date and time of the system with all date and time in the database and then notify if matches. I don't think querying the database every second is good. I can't think of any other way around. This application is also going to sync the alarm records across multiple devices so storing in database is a must I guess.
How do typical alarm application work in which we can set multiple alarms ?
-Thank You
Try create server layer on top of database. Query from db alarm time, create class who send notifications to client apps when alarm time is done. Maybe try use Quartz library?
How do I get a notification whenever there is a record in a particular table in the database?
If I use a Trigger in MySQL will not work when I change database.
If I make an Ajax request every certain interval, I will make unnecessary requests and I've been punished for it in Hostmonster (escape them).
Another idea?
This guy went through the problem as me:
http://www.schiffner.com/11-excruciating-months-with-hostmonster-have-come-to-an-end/
Thank you.
Sending Ajax requests at regular intervals (long polling) may not be the best solution but I have seen this implementation in many applications and probably it is easy to implement.
One of the solutions that has not been mentioned here is a PHP script running in a scheduler. This question will help you and make things clearer. Schedule alarm notification system php
Do let me know if you need more info.
I'm using the messaging timer feature to schedule asynchronous procedure executions and all seems to be going well but I only tested it for a short time range (setting the timeout to a few hours).
I decided upon this feature because the timer functionality is supposed to be entirely contained "within" single database scope/context (as opposed to depend on the server instance). As a consequence the timer should not be interfered by server restarts, database restoration from backup (provided the backup has been done after the timer setup) etc. If it actually works that way in practice than I'll be really glad but it seems too beautiful to be true so I'd like to be able to check up on the timer. Maybe see how long 'till it fires even.
Is there a query I can run, maybe on the sys.objects table, that enables this?
I've never used this feature myself, but the documentation says that sys.conversation_endpoints.dialog_timer is "The time at which the conversation timer for this dialog sends a DialogTimer message", which I think is what you're looking for.
I am not a great VB programmer, but I am tasked with maintaining/enhancing a VB6 desktop application that uses Sybase ASE as a back-end. This app has about 500 users.
Recently, I added functionality to this application which performs an additional insert/update to a single row in the database, key field being transaction number and the field is indexed. The table being updated generally has about 6000 records in it, as records are removed when transactions are completed. After deployment, the app worked fine for a day and a half before users were reporting slow performance.
Eventually, we traced the performance issue to a table lock in the database and had to roll back to the previous version of the app. The first day of use was on Monday, which is generally a very heavy day for system use, so I'm confused why the issue didn't appear on that day.
In the code that was in place, there is a call to start a Sybase transaction. Within the block between the BeginTrans and CommitTrans, there is a call to a DLL file that updates the database. I placed my new code in a class module in the DLL.
I'm confused as to why a single insert/update to a single row would cause such a problem, especially since the system had been working okay before the change. Is it possible I've exposed a larger problem here? Or that I just need to reconsider my approach?
Thanks ahead for anyone who has been in a similar situation and can offer advice.
It turns out that the culprit was a message box that appears within the scope of the BeginTrans and CommitTrans calls. The user with the message box would maintain a blocking lock on the database until they acknowledged the message. The solution was to move the message box outside of the aforementioned scope.
I am not able to understand the complete picture without the SQL code, that you are using.
Also, if it is a single insert OR update, why are you using a transaction? Is it possible that many users will try to update the same row?
It would be helpful if you posted both the VB code and your SQL (with the query plan if possible). However with the information we have; I would run update statistics table_name against the table to make sure that the query plan is up to date.
If you're sure that your code has to run within a transaction have you tried adding your own transaction block containing your SQL rather than using the one already there?