How do you email errors in ASP?

[jim_denney]

We have some ASP pages for online registration of classes. The data is retrieved from an Access database and when the data is entered correctly, everything works fine. Unfortunately, the data is entered by humans, so errors are a common part of the equation.

Each course a person signs up for should list any number of classes assigned to the course. But sometimes, the data entry people forget to enter the classes. Or they will put in the wrong info and keep the classes from pulling up in the queries.

We can trap for the errors and display appropriate messages, but would like the data entry people to be notified automatically when the errors occur so the data can be corrected.

Any ideas on how to send an email when an error is encountered while the page is loading or being created by ASP?

[glenngv]

Why not just trap erroneous entries and prevent the user from saving the data until corrected?

[jim_denney]

Trapping for errors as the data is entered would require too much code. The initial data entry is performed on another system, then event info is pushed to the web server for on-line registration. In addition, we underestimated managements abilities to create new options for the registration process as well as overestimating the data entry staffs abilities to comprehend the registration process.

There are currently 8 different types of registration, each requireing a seperate web page to process registrants. Some types may have options for early, regular and late registration, some do not. Some offer discounts to members of groups, some do not. Some offer discounts to some or all registrants as more registrants from the same organization sign up. Some programs consist of a single event, others can allow for multiple events. A registrant can sign up for one or any number of events, some of which might offer additional discounts if signed up for as a package.

So the number of events, types of event registration, options for early, regular, late registration, etc. make it too difficult to trap for errors as the data is entered.

We already know where the errors are happening on the web site. We currently display a message letting the person know there is a problem and asking them to contact the company so the problem can be corrected. But 9 times out of 10, the person simply backs out of the application and doesn't let anyone know. So the company is loosing potential registrations and money.

Since we know where the errors occur, it would be much better if we could e-mail the data entry people to let them know that a problem exists with a specific program, so corrections could be made as needed. The advantage of e-mail is that it notifies the user immediately when received, verses creating reports that must be run by someone when they remember to run them.

[A1ien51]

Do a quick search on google for an ASP email code which is free. Then all you need to do is call the function whenever you trap the error.

Eric

[jim_denney]

Thanks for the suggestion. I followed several links, some which were too complicated or unusable. I finally found a satifactory bit of code. Since I spent so much time locating this, I am putting the solution for others to use.

First, you have to have CDONTS on the server. It should have been installed with the server software, but if not it is available in Service Pacj 4. We are using Windows 2000, and the code works well. Eventually we will move to ASP.Net, but for now the ASP does fine.

Since I had already trapped for the errors, all I had to do was put the code where it was needed. The code is as follows:

<%
Dim objMail
Dim strSubject
Dim strBody
strSubject = "Data Record"
strBody = strTemplate

' First create an instance of the NewMail Object
Set objMail = Server.CreateObject("CDONTS.NewMail")
objMail.From = "from_who@somewherei.com"
objMail.To = "to_who@another_place.com"
objMail.Bcc = "if_cc_needed@another_place.com"

objMail.Subject = "The email message you want to send goes here. You can use ASP to include other info, or just hard code a message. We are sending the offending ASP page, as well as user info so we can contact them if needed for more info."

' In order to send the email in HTML format we have to set both MailFormat and BodyFormat equal to zero

objMail.MailFormat = 0
objMail.BodyFormat = 0
objMail.Importance = 2
objMail.Send
Set objMail = Nothing
%>

This was so simple to do, its hard to imagine I spent so much time looking for how it was done.

[glenngv]

We can trap for the errors and display appropriate messages, ...
Trapping for errors as the data is entered would require too much code. :confused:

If there is indeed error trapping, then you can just say something like:

The following field(s) contains invalid entries. Please correct them to continue registration by pressing the browser's BACK button:

Field 1
Field 2
Field 3
...

My point is, if you can trap the error while the user is entering the data, why not inform them at once (so that it can be corrected promptly) instead of mailing them later?

[jim_denney]

I will repeat, there are too many options that may apply when the data is input to make error trapping at that time possible. Sometimes the juice isn't worth the squeeze. And idiot-proofing applications does not work, they constantly invent better idiots than we can program for.

Don't get the impression that we are not validating data as input. We have hundreds of lines of code to validate data as it is captured. But when it comes to validating the events as they are input, they are too many decisions to make it cost-efficient.

To idoit-proof the data, we would have to look at the type of registration selected, the all of the types of events and then determine if they should have pre-reg, std reg, late reg, one event or multiple events (no way of knowing since some programs have either/or), discounts for multiple registrations, etc. Then we would have to cross reference everything:
If multiple registration types (i.e.pre-reg, std-reg, late-reg, etc.), have multiple dates been input, AND have event costs info been input for each type (i.e.pre-reg, std-reg, late-reg, etc.) AND/OR
If multiple events, has the multiple event info been input AND/OR
If multiple registrations offer discounts, have the fees been input for the different cost ranges (i.e. 1, 2-4, 4-10, 3-7, etc.)AND/OR
If multiple registrations offer discounts, is the discount applied to everyone, or only those past the specified number of registrants AND/OR
Have the fees been input for member vs. non-member registration AND/OR
If a single program has multiple events AND some of the events offer discounts based on info related to members AND/OR the number of people signed up for the event, has that information been input AND/OR
If a specific program offers additional discounts to members meeting certain criteria, has the required additional info been input.

When you start trying to graph it out, your decision tree starts looking like a briar patch. This is not a simple registration like you would find in a university. There may be multiple prices for programs that may have multiple events, and any event can have mutiple fees based on any number of variables that may or may not apply to the specific class and type of registration specified.

We can not put the checks on the program editing screen, because the events are a related table and are input on another screen. You can not check against data that hasn't been input.

You can put checks on the event editing screen, but it doesn't keep users from changing data on the first screen and rendering the event data useless. So we would have to put code on both screens.

Of course we could actually do the error trapping. It would only take a few weeks and a few thousand lines of code that would need to be constantly updated as more registration types and methods are created by imaginative administration officials to push numerous promotions.

Or we could spend a couple of weeks writing a program to check the data and have it run before data is pushed to the web database.

But the next time someone comes up with a "great, new, improved promotional" registration type, we are back at square one. And that happens very often. Again, sometimes the juice isn't worth the squeeze.

The email solution works fine now, was inexpensive, easily implemented and does what we want it to do. If new registration types and methods are created that do not fit into anything we currently have, we simply create a new web page as needed and put the email code in place.;)