Validation and Error Reporting for Web Database Applications

There is nothing worse for a user than annoying, overly persistent, inaccurate, or uninformative validation. For example, error messages that describe an error but don't specify which field contains the error are difficult to correct. However, there is no correct recipe for balancing validation with system requirements: what is pleasing or mandated by requirements in one application might be annoying or useless in another. In this section, we consider practical validation models for web database applications.

Validation is actually two processes: finding errors and presenting error messages. Finding errors can be interactive-where data is checked as it's entered-or it can be post-validation, where the data is checked after entry. Presenting errors can be field-by-field-where a new error message is presented to the user for each error found-or it can be batched, where all errors are presented as a single message. There are other dimensions to validation and error processing, such as the degree of error that is tolerated and the experience level of the user. However, considering only the basic processes, the choice of when to error-check and when to notify the user, leads to four common approaches:

Interactive validation with field-by-field errors

The data in each field is validated when the user exits or changes the field. If there is an error, the user is alerted to that error and may be required to fix the error before proceeding.

Interactive validation with batch errors

The data in all fields is validated when the user leaves one field. If there are one or more errors, the user is alerted to these, and normally the user can't proceed beyond the current page without fixing all errors.

Post-validation with field-by-field errors

The user first enters all data with no validation. The data is then checked and errors are reported field-by-field in separate error messages to the user. Usually, for each error, the cursor is placed in the field requiring amendment.

Post-validation with batch errors

The user first enters all data with no validation. The data is then checked, and all errors in the data are reported in one message to the user. The user then fixes all errors and resubmits the data for revalidation.

In tutorial 6-without discussing the details-we covered several simple post-validation techniques to check whether mandatory <form> data was entered before inserting or updating data in the database. In addition, we used a batch reporting method, where errors were reported as a list by constructing an error string. In the case study example in this tutorial, we discuss additional validation for the customer <form> data to more carefully inspect both mandatory and optional fields.