I have an sql database where I store an email message, subject, recipients and the data time when this message has be to be emailed. How can I do it programmaticaly via console app lets say that I hook as an executable via task scheduler?
What should I use - Thread Timer in order to determine when to fire off the email?
Never done this before really hoping that someone can help.
I've tried Quartz but can't figure it out.
You'll need to know how to connect to a database, create tables, query the database, send emails, your question is too general to answer it in one post but the below is an overview.
Use a database to hold the email. Make one of the columns in the database equal to the time when you want the message sent. Have the application query the database a few times a minute and if the datetime of the TimeToSend is greater than or equal to Datetime.Now() send the email. Once the email is sent either delete it or move it to a SentEmails database table. This would allow another separate program(s) to drop new emails into the database to be sent at a future time.
You could add more columns to specify things like how often the email should be sent or other conditions that you can evaluate through code to add whatever flexibility is required.
Related
I have a 3 layer web app in C#.
I have a simple method in the business layer that calls another one in the database layer to insert info in the database.
When the control return to the business layer, I checked the result variable, and if it's positive it means that the info was inserted in the database. Then, if positive, I called another method to send an email.
I was wondering, that would happen if the server goes offline just in the middle of this? For example just after the info was inserted but before the mail was dispatched.
How can I solve this situation and make this block of code run in an atomic way? Using a transaction? (not sure how to use one through different methods in different class libraries).
Many thanks.
Separate these issues. Have your business layer write the values, with a new field "MailSent" or something set to False. Have another service poll the results table for unsent mails, and work through those.
You can run all of your database operations within a transaction, but you truly can't ensure that the mail is being sent out in the middle of the transaction. Even thought you can dispatch an email to a smtp server for delivery, the mail DELIVERY IS NOT GUARANTEED ANYHOW!!!
The mail server may be unable to connect outward toward the internet or wherever it has to relay mail to.
It may be able to connect out, but weird stuff happens and the message may be delayed (as in the case where it connects right away, but connection is dropped)
Don't drive yourself crazy. It's a short drive.
Sending an email via relay sometimes takes time, so you do not want to wait whether email is fail or successful.
However, there is not right or wrong answer. Here is my two cents.
As you said, second code of block is sending email. In our sites, we use separate process to send out emails. Here is how it works –
Use transaction to enter information to Info table and EmailQueue table in database
Background process picks up emails from EmailQueue (let say every 5 minutes) and send out email
If email is successful, mark the email as sent
If email is fail, increase the attempt counter until it reach some limits (let say 3 times)
If server goes offline like you said and come backup again, the background process will pick up emails from EmailQueue (which haven't been send and less than attempt limits).
Inspite of returning a boolean result. Maintain a table called Outbox and insert a row in it if condition satisfies.
And when control comes back to your business layer as mentioned in your question. Process all the outbox mails i.e., sent all the mails present in outbox and delete the entry from outbox or update a column in Outbox table which will represent email status.
I need to update the user's messages when a new one was sent to him.
I know that I can create a SQL Trigger and get it using CLR Triggers.
But how do I notify the user without having some method polling to see if something's changed?
How do I know that I have new messages without check the database every time?
It's 100% similar to an email system or the facebook message system.
One user will send a message to another, how to get that new message without having a method checking the database for changes from time to time?
I'm using SQL Server 2008 and ASP.NET MVC3.
Thanks.
Please take a look at the SignalR (https://github.com/SignalR). You'd have to perform tests on how it behaves in your environment.
Is there a way for me, with a WPF browser application, to schedule an email to be sent? What I will have is a date, date of user subscription, and then I would like it to send the user an email 5 days before their membership expires. How can I achieve this?
The easiest way to do this is to write a record to a database table (say a email task table) then write a Windows service that polls this table say every minute, checks for any emails that need to be sent and then sends them.
Seems to be you'll have to do something on the server side with a scheduled job/task checking daily for who needs to get an email sent to them.
AFAIK the SMTP server sends the emails immediately so you have to persist this queue in your application (or use MSMQ as queue storage) and have some part of your application executing the delivery at required time.
At this point my question is, if you can send when you know is the time to send, can't you send directly later without using the queue or do you have any logic in your application so that the email you would generate today can't be generated at later time?
I would probably create a Windows Service or, even better, have a scheduled task calling my application every day at midnight then the application verifies to whom the email should be sent right now, creates it and sends it out.
I have a web application from which emails should be sent after specific actions. I have some alternatives for handling this I'm not sure which one is the best.
The first is that, when a user does an action the email is being sent directly from the ASP.NET application. But I think this is not a really reliable system because if the SMTP server is down or something else happens, the user just gets a feedback that his action cannot be completed.
As an alternative I was thinking about implementing a queuing system for what I have some ideas:
Push emails to send, into a database table, and a service application periodically checks for new messages, then sends them. On successful send it marks the email task completed.
Use MSMQ for queing. In this case the whole email could be passed as a message; or the other way is to store the message with attachments into a db table, and pass only the data which is required to query the db table and send the message. In this case I don't have to deal with size limits of MSMQ (because of attachments).
something else, like a local WCF service to notify the service
Which way you think is the best?
Use MSMQ is not good solution since has a limitation of 4 MB of each size. http://blogs.msdn.com/b/johnbreakwell/archive/2007/08/22/why-is-there-a-4mb-limit-on-msmq-messages.aspx
Worse case scenario, if MSMQ is failed like it process throw error or suddenly shutdown, it will loss many message. In my case, this solution is good when hardware and software is instaled in almost ideal
Use database and window service is better since it is a simple and doesn't need much effort.
I usually use a combination of database and file. The database contains table to save a header information and a flag that message has been action (either success or error or else) and files contains message (either html or plain) and attachment in original format.
When process is run to send, it is quicker to assemble a message from files rather than from querying blob/clob.
Since they are using file system on the application, you can add hardware like server or components or else to add availibility of the system easily.
Database can be added too, but it will cost you more license in databse software.
I add a test send email after send email in x times to make sure it is works well; this test email is send to my self or dummy inbox and an application to check the test email that is the same email that send and receive. If it is the same, sending pending email will continue again
Another way if you are using MS Exchange, you can use message queue by utilize its web service to queue send. This is an easy way but you need license.
You can see on MSDN library how to utilize MS Exchange web service.
You can use an email server like hmail. In order to push emails into a queue, you can push them to a mail server. To do that, you can write a windows form application that has a timer object that checks every row that has a Status 0(not sent) in email table. When the thread sends it to the mail server, it will be marked as 1(sent).
You can also classify your emails if you use DB. Different actions can send different emails. You can store this info in DB also so that your windows form application thread will now which email template to send.
We are writing a feature to send a reminder email to customers in x number of days and just wondered if it was possible to delay the sending of the emails similar to how you can in Outlook (New Mail > Options button > Do not deliver before) in C#.
Does anyone know of a way of doing this?
If you want to submit the email to an SMTP server to hold for a number of days, the server would have to support this feature. I would recommend against doing it that way, however. If you had a problem with missing emails it could be hard to track down.
Here's what I would do:
Schedule the emails in your system by making a table entry.
Include a "SendDate" column in the table where you can set a date in the future
Write a Windows service that wakes up once every 15 minutes (for example) and sends the emails in that table where SendDate < currentDate
One possibility is to create a service that runs on a scheduled task processing 'pending' mail. You might store the pending mail in a SQL Database. (Dave details this)
This article looks promissing if you would like to avoid a 'real' service
http://www.codeproject.com/KB/aspnet/ASPNETService.aspx
No.
The way to accomplish this would be for your application to write the email to a queue (could be database, file, MSMQ, etc), and then write a separate process that, at a later date, reads mail from that queue and sends it.
As far as I know, the SMTP protocol doesn't have any kind of "delayed send" feature. Also, the feature you reference in Outlook actually just keeps it in your client's outbox until the designated date, so it's a client-side feature, not a server-side feature.
The SmtpClient is a pretty dumb client and doesn't support this -- sends are immediate whether they are synchronous or asynchronous. You may be able to do it using an Exchange integration. I'm not sure what APIs are exposed for Exchange, though. The simplest way would be to keep the message in a database table along with the time-to-send and have an off-line process that regularly scans this table and looks for messages whose time-to-send value has passed and are not marked as sent.