Restrict data input by using a validation rule

You can vet or validate data as it is input to help improve accuracy and consistency, by using validation rules. There are three ways to use validation rules:

  • Field Validation Rule You can use a validation rule to specify a criterion that all valid field values must meet. For example, a date field might have a validation rule that disallows values in the past.
  • Record Validation Rule You can use a validation rule to specify a condition that all valid records must satisfy. For example, a record with two date fields might require that values of one field always precede values of the other field (e.g., StartDate is before EndDate).
  • Validation on a form You can use the Validation Rule property of a control on a form to specify a criterion that all values input to that control must meet. The Validation Rule control property works like a Field Validation Rule.
In this article


Overview

This article explains how to use validation rules and validation text in table fields and form controls. A validation rule is one way to restrict input in a table field or a control (such as a text box) on a form. Validation text lets you provide a message to help users who input data that is not valid.

When data is entered, Access checks to see whether the input breaks a validation rule – if so, the input is not accepted, and Access displays a message.

Access provides a number of ways to restrict input:

  • Data types    Every table field has a data type that restricts what users can enter. For example, a Date/Time field accepts only dates and times, a Currency field accepts only monetary data, and so on.
  • Field properties    Some field properties restrict data input. For example, the Field Size property of a field restricts input by limiting the amount of data.

You can also use the Validation Rule property to require specific values, and the Validation Text property to alert your users to any mistakes. For example, entering a rule such as >100 And <1000 in the Validation Rule property forces users to enter values between 100 and 1,000. A rule such as [EndDate]>=[StartDate] forces users to enter an ending date that occurs on or after a starting date. Entering text such as "Enter values between 100 and 1,000" or "Enter an ending date on or after the start date" in the Validation Text property tells users when they have made a mistake and how to fix the error.

  • Input masks    You can use an input mask to validate data by forcing users to enter values in a specific way. For example, an input mask can force users to enter dates in a European format, such as 2007.04.14.

You can use these methods of validating data alone or in combination with each other. Data types are not optional, and provide the most basic type of data validation.

For more information about data types, field sizes, and input masks, see the article Introduction to data types and field properties.

Types of validation rules

You can create two basic types of validation rules:

  • Field validation rules    Use a field validation rule to check the value that you enter in a field when you leave the field. For example, suppose you have a Date field, and you enter >=#01/01/2010# in the Validation Rule property of that field. Your rule now requires users to enter dates on or after January 1, 2010. If you enter a date earlier than 2010 and then try to place the focus on another field, Access prevents you from leaving the current field until you fix the problem.
  • Record validation rules    Use a record validation rule to control when you can save a record (a row in a table). Unlike a field validation rule, a record validation rule refers to other fields in the same table. You create record validation rules when you need to check the values in one field against the values in another. For example, suppose your business requires you to ship products within 30 days and, if you don't ship within that time, you must refund part of the purchase price to your customer. You can define a record validation rule such as [RequiredDate]<=[OrderDate]+30 to ensure that someone doesn't enter a ship date (the value in the RequiredDate field) too far into the future.

If the syntax for validation rules looks cryptic, see the section What you can put in a validation rule for an explanation of the syntax and some example validation rules.

Where you can use validation rules

You can define validation rules for table fields and for controls on forms. When you define rules for tables, those rules apply when you import data. To add validation rules to a table, you open the table and use commands on the Fields tab of the ribbon. To add validation rules to a form, you open the form in Layout view and add rules to the properties of individual controls.

The steps in the section Validate data during entry in table fields explain how to add validation rules to table fields. The steps in the section Validate data during entry in forms, later in this article, explain how to add rules to the properties in individual controls.

What you can put in a validation rule

Your validation rules can contain expressions — functions that return a single value. You can use an expression to perform calculations, manipulate characters, or test data. A validation rule expression tests data. For example, an expression can check for one of a series of values, such as "Tokyo" Or "Moscow" Or "Paris" Or "Helsinki". Expressions can also perform mathematical operations. For example, the expression <100 forces users to enter values that are less than 100. The expression ([OrderDate] - [ShipDate]) calculates the number of days that elapsed between the time an order was placed and the time it shipped.

For more information about expressions, see the article Create an expression.

For examples of ways you can use expressions to validate data, see the section Validate data in a record.

Top of Page Top of Page

Add a validation rule to a table

You can add a field validation rule and/or a record validation rule. A field validation rule checks input to a field, and is applied when the focus leaves the field. A record validation rule checks input to one or more fields is applied when the focus leaves the record. Usually, a record validation rule compares the values of two or more fields.

 Note    The following field types do not support validation rules:

  • AutoNumber
  • OLE Object
  • Attachment
  • ReplicationID

Create a field validation rule

  1. Select the field that you want to validate.
  2. On the Fields tab, in the Field Validation group, click Validation, and then click Field Validation Rule.
  3. Use the Expression Builder to create the rule. For more information about using the Expression Builder, see the article Use the Expression Builder.

Create a message to display for field input that is not valid

  1. Select the field that needs a message for input that is not valid. The field should already have a validation rule.
  2. On the Fields tab, in the Field Validation group, click Validation, and then click Field Validation Message.
  3. Enter an appropriate message. For example, if the validation rule is >10, the message might be “Enter a value that is less than 10.”

For some examples of field validation rules and messages, see the section Validation reference.

Create a record validation rule

  1. Open the table for which you want to validate records.
  2. On the Fields tab, in the Field Validation group, click Validation, and then click Record Validation Rule.
  3. Use the Expression Builder to create the rule. For more information about using the Expression Builder, see the article Use the Expression Builder.

Create a message to display for record input that is not valid

  1. Open the table that needs a message for input that is not valid. The table should already have a record validation rule.
  2. On the Fields tab, in the Field Validation group, click Validation, and then click Record Validation Message.
  3. Enter an appropriate message. For example, if the validation rule is [StartDate]<[EndDate], the message might be “StartDate must precede EndDate.”

Top of Page Top of Page

Test existing data against a new validation rule

If you add a validation rule to an existing table, you might want to test the rule to see whether any existing data is not valid.

 Note    The following procedure does not work with web tables.

  1. Open the table that you want to test in Design View.

On the Design tab, in the Tools group, click Test Validation Rules.

  1. Click Yes to close the alert message and start the test.
  2. If prompted to save your table, Click Yes.
  3. You might see a variety of other alert messages as you proceed. Read the instructions in each message, and then click Yes or No, as appropriate, to complete or stop the testing.

Top of Page Top of Page

Add a validation rule to a control on a form

You can use the Validation Rule property the Validation Text property of a form control to validate data that is input to that control and to help users who input data that is not valid.

 Note    If you create a form automatically from a table by using one of the Form commands on the ribbon, any validation for fields in the underlying table are inherited by the corresponding controls on the form.

A control can have a different validation rule from the table field to which the control is bound. This is useful if you want the form to be more restrictive than the table. The form rule is applied, and then the table rule is applied. If the table is more restrictive than the form, the rule defined for the table field takes precedence. If the rules are mutually exclusive, they prevent you from entering any data at all.

For example, suppose you apply the following rule to a date field in a table:

<#01/01/2010#

But you then apply this rule to the form control that is bound to the date field:

>=#01/01/2010#

The date field now requires values earlier than the year 2010, but the form control requires dates have that year or later, thus preventing you from entering any data at all.

Create a validation rule for a control

  1. Right-click the form that you want to change, and then click Layout View.
  2. Right-click the control that you want to change, and then click Properties to open the property sheet for the control.
  3. Click the All tab, and then enter your validation rule in the Validation Rule property box.

     Tip    Click the Build button to start the Expression Builder.

    For more information about using the Expression Builder, see the article Use the Expression Builder.
  4. Enter a message in the Validation Text property box.

Top of Page Top of Page

Validation rule reference

Validation rules use Access expression syntax. For more information about expressions, see the article Introduction to expressions.

Validation rule and validation text examples

Validation rule Validation text
<>0 Enter a nonzero value.
>=0

Value must be zero or greater.

-or-

You must enter a positive number.

0 or >100 Value must be either 0 or greater than 100.
BETWEEN 0 AND 1 Enter a value with a percent sign. (For use with a field that stores number values as percentages).
<#01/01/2007# Enter a date before 2007.
>=#01/01/2007# AND <#01/01/2008# Date must occur in 2007.
<Date() Birth date cannot be in the future.
StrComp(UCase([LastName]),
[LastName],0) = 0
Data in a field named LastName must be uppercase.
>=Int(Now()) Enter today's date.
M Or F Enter M for male or F for female.
LIKE "[A-Z]*@[A-Z].com" OR "[A-Z]*@[A-Z].net" OR "[A-Z]*@[A-Z].org" Enter a valid .com, .net, or .org e-mail address.
[RequiredDate]<=[OrderDate]+30 Enter a required date that occurs no more than 30 days after the order date.
[EndDate]>=[StartDate] Enter an ending date on or after the start date.

Syntax examples for common validation rule operators

Operator Function Example
NOT Tests for converse values. Use before any comparison operator except IS NOT NULL. NOT > 10 (the same as <=10).
IN Tests for values equal to existing members in a list. Comparison value must be a comma-separated list enclosed in parentheses. IN ("Tokyo","Paris","Moscow")
BETWEEN Tests for a range of values. You must use two comparison values — low and high — and you must separate those values with the AND separator. BETWEEN 100 AND 1000 (the same as >=100 AND <=1000)
LIKE Matches pattern strings in Text and Memo fields. LIKE "Geo*"
IS NOT NULL Forces users to enter values in the field. This is the same as setting the Required field property to Yes. However, when you enable the Required property and a user fails to enter a value, Access displays a somewhat unfriendly error message. Typically, your database is easier to use if you use IS NOT NULL and enter a friendly message in the Validation Text property. IS NOT NULL
AND Specifies that all parts of the validation rule must be true.

>= #01/01/2007# AND <=#03/06/2008#

 Note   You can also use AND to combine validation rules. For example: NOT "UK" AND LIKE "U*".

OR Specifies that some but not all parts of the validation rule must be true. January OR February
< Less than.
<= Less than or equal to.
> Greater than.
>= Greater than or equal to.
= Equal to.
<> Not equal to.

Using wildcard characters in validation rules

You can use wildcard characters in your validation rules. Keep in mind that Access supports two sets of wildcard characters: ANSI-89 and ANSI-92. Each of those standards uses a different set of wildcard characters.

By default, all .accdb and .mdb files use the ANSI-89 standard; conversely, Access projects use the ANSI-92 standard. If you are new to Access, in an Access project, the tables in your database reside on a computer running Microsoft SQL Server, and the forms, reports and other objects reside on other computers.

You can change the ANSI standard for a database to ANSI-92 by using the following procedure:

  1. On the File tab, click Options.
  2. In the Access Options dialog box, click Object Designers.
  3. In the Query design section, under SQL Server Compatible Syntax (ANSI-92), select This database.

For more information about using wildcard characters and the ANSI standards for SQL, see the article Access wildcard character reference.

Top of Page Top of Page

 
 
Applies to:
Access 2010