Queries 2012
Queries 2012
United States
home products support o All Support o Excel o Word o Outlook o PowerPoint o Office Training o Office Videos o Get Started with Office
images templates o All Templates o Education Collection o Hiring and Recruiting Collection o Resume Collection
o
downloads more o All Office.com o Career Center o Office Blogs o Office Labs o Office for Mac o Office for IT Pros o Office for Developers o All Microsoft Sites
This article explains how to add validation rules to a database. Validation rules restrict what users can enter in a given field, and also help ensure that your database users enter the proper types or amounts of data.
Understand validation rules Validate data during entry in table fields Validate data during entry in forms Validate data during import operations Validation rule reference
Data types Data types typically provide the first layer of validation. When you design a database table, you define a data type for each field in the table, and that data type 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 sizes Field sizes provide another layer of validation. For example, if you create a field that stores first names, you can set it to accept a maximum of 20 characters. Doing so can prevent a malicious user from pasting in large amounts of gibberish text into the field, or it can prevent an inexperienced user from mistakenly entering a first and last name in a field designed only to hold a first name.
Table properties Table properties provide very specific types of validation. For example, you can set the Required property to Yes and, as a result, force users to enter a value in a field. 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. For the steps needed to add a validation rule to a table field, see the section Validate data during entry in table fields, later in this article.
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 some or all of those techniques to validate your data. Some of those features, such as data types, become part of your database by default, but you can use other techniques, such as field properties, validation rules, and input masks, at your discretion. This article explains how to use the Validation Text and Validation Rule properties in table fields, queries, and form controls. A complete discussion of other validation tools, such as data types, field sizes, and input masks, is beyond the scope of this article. For more information about data types and field sizes, see the article Modify or change the data type set for a field. For more information about input masks, see the article Create an input mask to enter field or control values in a specific format.
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/2007# in the Validation Rule property of that field. Your rule now requires users to enter dates on or after January 1, 2007. If you enter a date earlier than 2007 and then try to place the focus on another field, Access prevents you from leaving the current field until you fix the problem.
Record (or table) validation rules Use a record validation rule to control when you can save a record (a row in a table). Unlike field validation rules, record validation rules refer 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, the tables in the section What you can put in a validation rule explain the syntax and provide some example validation rules.
You can define validation rules for tables 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 in Design view and set various table properties. To add validation rules to a form, you open the form in Design 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 the properties in 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.
In the lower section of the table designer, on the General tab, select the Validation Rule property box, and then enter your validation rule. -or-
For more information about using the Expression Builder, see the article Create an expression. Enter a rule that applies only to the field. For example, you can enter >0 to force users to enter positive values. Keep in mind that a validation rule for a field does not reference other fields in the table. If the rule does reference other fields, you are creating record-level validation.
4.
Select the Validation Text property box and enter a validation message. The message you enter depends on your validation rule. Keep the message short and try to explain where the user is going wrong. To continue the example from the previous step, you could use Enter only positive numbers as the validation text.
5.
NOTE For more examples of field-level validation, see the section Validation reference, later in this article.
2.
Click
For more information about using the Expression Builder, see the article Create an expression. A record-level validation rule references more than one table field. For example, a rule such as [RequiredDate]<=[OrderDate]+30 references two table fields, RequiredDate and OrderDate, and it ensures that users enter ship dates that occur no later than 30 days after an order is entered. For more examples of record-level validation, see the section Validation reference. 3. Save your changes.
2. 3. 4. 5.
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.
1.
Access opens a new query in Design view, and displays the Show Table dialog box.
2.
In the Show Table dialog box, select the table or tables that you want to use in your query, click Add to add them to the query, and then click Close. The selected tables appear as windows in the upper section of the query designer. 3. In each table, double-click the fields that you want to include in your query. -orDrag the fields from the table and drop them on a blank cell in the Field row in the lower section of the design grid. Make sure that you add the field that contains your validation rule.
4.
In the Criteria cell of the field that contains your validation rule, enter the opposite of that rule. For example, if you use BETWEEN 100 AND 1000, enter <100 OR >1000.
5.
TOP OF PAGE
control.
Click
For more information about using the Expression Builder, see the article Create an expression.
4.
5.
Enter a message in the Validation Text property box. Save your changes.
Lock a control
1. Follow steps 1-2 in the previous section to open the property sheet for the control that you want to lock. Click the All tab, locate the Enabled and Locked property boxes, and then do one of the following:
2.
To disable the control (make the control appear dimmed and unable to receive focus), set the Enabled property to No. To make the data in the control readable, but not allow users to change the data, set the Locked property to Yes. If you set the Enabled property to No and the Locked property to Yes, the control won't appear dimmed, but it won't be able to receive focus.
TOP OF PAGE
Import or link to data in another Access database Import or link to data in an Excel workbook Import from or link to a SharePoint list Import or link to data in a text file
TOP OF PAGE
VALIDATION RULE
<>0 >=0
VALIDATION TEXT
Enter a nonzero value. Value must be zero or greater. -orYou must enter a positive number. Value must be either 0 or greater than 100. Enter a value with a percent sign. (For use with a field that stores number values as percentages). Enter a date before 2007. Date must occur in 2007. Birth date cannot be in the future. Data in a field named LastName must be uppercase. Enter today's date. Enter M for male or F for female. Enter a valid .com, .net, or .org e-mail address. Enter a required date that occurs no more than 30 days after the order date. Enter an ending date on or after the start date.
0 or >100 BETWEEN 0 AND 1 <#01/01/2007# >=#01/01/2007# AND <#01/01/2008# <Date() StrComp(UCase([LastName]), [LastName],0) = 0 >=Int(Now()) M Or F LIKE "[A-Z]*@[A-Z].com" OR "[A-Z]*@[A-Z].net" OR "[AZ]*@[A-Z].org" [RequiredDate]<=[OrderDate]+30 [EndDate]>=[StartDate]
The expressions in your validation rules don't use any special syntax. The information in this section explains the syntax for some of the more common types of validation rules. As you proceed, remember that expressions and functions can be very complex, and a comprehensive discussion is beyond the scope of this article. For more information about expressions, see the article Create an expression. For more information about functions, see the article Functions (arranged by category). Keep these rules in mind as you create expressions:
Surround the names of table fields with square brackets, like so: [RequiredDate]<=[OrderDate]+30. Surround dates with pound signs (#), like so: <#01/01/2007#
Surround text values with double quotation marks, like so: IN ("Tokyo","Paris","Moscow"). Also, note that you separate items with commas, and you place lists inside parentheses. In addition to those rules, the following table shows the common arithmetic operators and provides examples of how you can use them.
OPERATOR
NOT
FUNCTION
EXAMPLE
Tests for converse values. Use before any comparison operator except IS NOT NOT > 10 (the same as <=10). NULL. Tests for values equal to existing members in a list. Comparison value must be IN ("Tokyo","Paris","Moscow") a comma-separated list enclosed in parentheses. 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. Matches pattern strings in Text and Memo fields. BETWEEN 100 AND 1000 (the same as >=100 AND <=1000) LIKE "Geo*"
IN
BETWEEN
Forces users to enter values in the field. This is the same as setting the IS NOT NULL 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. Specifies that all the data that you enter must be true or fall within limits that you specify. >= #01/01/2007# AND <=#03/06/2008#
NOTE You can also use AND to combine validation rules. For example: NOT "UK" AND LIKE "U*". January OR February
AND
Specifies that one or more pieces of data can be true. Less than. Less than or equal to. Greater than. Greater than or equal to. Equal to. Not equal to.
TOP OF PAGE
No
Contact Us | Submit Feedback | Legal | Trademarks | Privacy | Accessibility 2012 Microsoft Corporation. All rights reserved.