| | Product Information Help and How-to Training Templates Support and Feedback Technical Resources Additional Resources | Warning: You are viewing this page with an unsupported Web browser. This Web site works best with Microsoft Internet Explorer 6.0 or later, Firefox 1.5, or Netscape Navigator 8.0 or later. Learn more about supported browsers.
Troubleshoot queries (MDB)
All queries I'm getting an unexpected message.
I'm getting the message "Can't bind name <name>."
You may encounter this message if you didn't explicitly declare in the Query Parameters dialog box the parameters used for a crosstab query (crosstab query: A query that calculates a sum, average, count, or other type of total on records, and then groups the result by two types of information: one down the left side of the datasheet and the other across the top.) or a query that a crosstab query or chart is based on. To resolve this, do the following:
- In the query that contains the parameter, specify the parameter and its data type in the Query Parameters dialog box.
How?
-
On the Query menu, click Parameters.
-
In the first Parameter cell, type the first prompt you entered in the query design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.).
-
In the Data Type cell to the right, click the appropriate data type (data type: The characteristic of a field that determines what type of data it can hold. Data types include Boolean, Integer, Long, Currency, Single, Double, Date, String, and Variant (default).) according to the following guidelines:
| If the parameter field data type is |
Click this data type in the Data Type cell |
| Currency, Date/Time, Memo, OLE Object, Text, and Yes/No |
Currency, Date/Time, Memo, OLE Object, Text, and Yes/No |
| Number |
Byte, Single, Double, Integer, Long Integer, and Replication ID. These data types correspond to the five FieldSize property settings of the Number data type. |
| Unknown |
Value. This is a generic data type that accepts any type of data. |
| Binary |
Binary. Used with parameter queries directed to linked tables (linked table: A table stored in a file outside the open database from which Access can access records. You can add, delete, and edit records in a linked table, but you cannot change its structure.) that do recognize this data type (Microsoft Access does not recognize this data type). |
-
Repeat Steps 2 and 3 for each parameter you want to specify a data type for.
- In the same query, set the ColumnHeadings property.
How?
You can change the order or limit the column headings in a crosstab query (crosstab query: A query that calculates a sum, average, count, or other type of total on records, and then groups the result by two types of information: one down the left side of the datasheet and the other across the top.). For example, in column headings containing the months of the year, you can display the months chronologically rather than alphabetically. Or, you can limit the columns to just January through June.
- Open the crosstab query in Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.).
- Click the background of query Design view, outside the design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.) and the field lists (field list: A window that lists all the fields in the underlying record source or database object, except in data access page Design view. In data access page Design view, it lists all the record sources and their fields in the underlying database.).
- On the toolbar, click Properties
to display the query's property sheet.
- In the ColumnHeadings property box, enter the column headings you want to display, in the order in which you want to display them. Between the column headings, type a comma or the list separator for your country/region. (To find the list separator for your country/region, see the regional settings in Microsoft Windows Control Panel.)
The column headings you enter must exactly match the column headings in the query datasheet. For example, if a column heading in the datasheet is "USA," you must enter a column heading of "USA"— not "US." (After you press ENTER or move the pointer to a different location, Microsoft Access places quotation marks around each heading.)
- To view the query's results, click View
on the toolbar.
Notes
- If you run a crosstab query often, or if you use it as the basis for a form, report, or data access page (data access page: A Web page, published from Access, that has a connection to a database. In a data access page, you can view, add to, edit, and manipulate the data stored in the database. A page can also include data from other sources, such as Excel.), you can speed up the query by using the preceding procedure to specify fixed column headings.
- If you frequently use the same column headings in different queries, consider creating a table with one Text (Text data type: In a Microsoft Access database, this is a field data type. Text fields can contain up to 255 characters or the number of characters specified by the FieldSize property, whichever is less.) field to store the column headings. Then open the table and copy the headings into the ColumnHeadings property box as needed.
I'm getting a key violation message.
A key violation occurs if:
If you run such a query, it will not modify the records that cause the key violation.
To modify records in a way that will violate referential integrity, you can break the relationship between the affected tables or turn referential integrity off, and then modify the affected tables one at a time. However, the resulting data in the two tables may then conflict.
I'm getting a validation rule violation message.
A validation rule (validation rule: A property that defines valid input values for a field or record in a table, or a control on a form. Access displays the message specified in the ValidationText property when the rule is violated.) violation occurs if you attempt to update or append records that violate the validation rules for a field or record.
Restrict or validate data
A field validation rule is used to check the value entered into a field as the user leaves the field. A record validation rule controls when an entire record can be saved. Unlike field validation rules, record validation rules can refer to other fields.
You can also determine whether data that already existed before you specified a validation rule or changed the Required or AllowZeroLength property violates the current settings.
- Open a table in Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.).
- Do one of the following:
Define a validation rule to control what values can be entered into a field
- In the upper portion of the window, click the field you want to define a validation rule for.
- In the lower portion of the window, click the ValidationRule property box, and then type the validation rule, or click the Build button
to create the validation rule using the Expression Builder (Expression Builder: An Access tool that you can use to create an expression. It includes a list of common expressions that you can select.).
For example, you could define the validation expression ">9" for a Quantity field to prevent a user from placing an order for fewer than 10 units.
- In the ValidationText property box, type the message that you want displayed when the rule is broken.
For example, for the validation expression ">9", you could enter "You must order 10 or more units."
-
If you set a validation rule in a field that contains data, Microsoft Access will ask if you want to apply the new rule to existing data when you save the table. If you click Yes, Access will warn you when existing data violates the validation rule.
Define a validation rule to control when a record can be saved
- Click Properties
on the toolbar to display the table's property sheet.
- In the ValidationRule property box, type the validation rule. Or click the Build button
to create the validation rule using the Expression Builder (Expression Builder: An Access tool that you can use to create an expression. It includes a list of common expressions that you can select.).
For example, you could define the validation expression "[RequiredDate]<=[OrderDate]+30" to make sure that the date entered into the RequiredDate field is within 30 days of the date in the OrderDate field.
- In the ValidationText property box, type the message that you want Microsoft Access to display when the rule is broken.
For example, for the validation expression "[RequiredDate]<=[OrderDate]+30", you could enter "The required date must be within 30 days of the order date."
-
If you set a validation rule in a table that contains data, Microsoft Access will ask if you want to apply the new rule to existing data when you save the table. If you click Yes, Microsoft Access will warn you when existing data violates the validation rule.
Test data that already existed before you specified a validation rule
I'm getting the message "Query contains ambiguous outer joins."
When you see the following message:
"The SQL statement couldn't be executed, because it contains ambiguous outer joins."
You tried to execute an SQL statement that contains multiple joins (join: An association between a field in one table or query and a field of the same data type in another table or query. Joins tell the program how data is related. Records that don't match may be included or excluded, depending on the type of join.). There are three types of joins in Microsoft Access: inner joins (inner join: A join where records in two tables are combined in a query's results only if values in the joined fields meet a specified condition. In a query, the default join is an inner join that selects records only if values in the joined fields match.) (also called equi-joins), left outer joins (outer join: A join in which each matching record from two tables is combined into one record in the query's results, and one table contributes all of its records, even if the values in the joined field don't match those in the other table.), and right outer joins. In some multiple joins, the results of the query can differ depending on the type of join and the order in which the joins are performed.
Example of a multiple join using three tables
For example, if you have three tables, Consultants, Active Consultants, and Projects, and you create an SQL query by joining these tables in the following way:
Consultants LEFT OUTER JOIN Active Consultants INNER JOIN Projects
Microsoft Access can process this query in two ways:
-
(Consultants LEFT OUTER JOIN Active Consultants) INNER JOIN Projects
Access first creates a left outer join between the Consultants and Active Consultants tables, and then creates an inner join between the results of those two tables and the Projects table.
-
Consultants LEFT OUTER JOIN (Active Consultants INNER JOIN Projects)
Access creates a left outer join between the Consultants table and the results of the inner join between the Active Consultants and Projects tables
Because Microsoft Access can produce different results between these two ways of joining, you must specify which way to join by changing one of the joins or by separating the query into two queries.
Multiple joins that aren't ambiguous
The following combinations of joins can only produce one result and will not generate an "ambiguous outer joins" message:
-
Consultants INNER JOIN Active Consultants INNER JOIN Projects
-
Consultants INNER JOIN Active Consultants LEFT OUTER JOIN Projects
-
Consultants LEFT OUTER JOIN Active Consultants LEFT OUTER JOIN Projects
-
Consultants RIGHT OUTER JOIN Active Consultants INNER JOIN Projects
-
Consultants RIGHT OUTER JOIN Active Consultants LEFT OUTER JOIN Projects
-
Consultants RIGHT OUTER JOIN Active Consultants RIGHT OUTER JOIN Projects
Multiple joins that are ambiguous
The following combinations of joins can produce more than one result and will generate an "ambiguous outer joins" message:
-
Consultants INNER JOIN Active Consultants RIGHT OUTER JOIN Projects
-
Consultants LEFT OUTER JOIN Active Consultants INNER JOIN Projects
-
Consultants LEFT OUTER JOIN Active Consultants RIGHT OUTER JOIN Projects
I'm getting the message "Too few parameters expected."
You may encounter this message if a parameter query (parameter query: A query in which a user interactively specifies one or more criteria values. A parameter query is not a separate kind of query; rather, it extends the flexibility of a query.) exported to the IDC (IDC/HTX files: Microsoft Internet Information Server uses an IDC file and an HTX file to retrieve data from an ODBC data source and format it as an HTML document.) file type doesn't have data types specified in the Query Parameters dialog box.
- In the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.), click Queries
under Objects.
- Click the name of the parameter query you want to modify, and click Design on the Database window toolbar.
- Specify a data type for the parameter.
How?
-
On the Query menu, click Parameters.
-
In the first Parameter cell, type the first prompt you entered in the query design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.).
-
In the Data Type cell to the right, click the appropriate data type (data type: The characteristic of a field that determines what type of data it can hold. Data types include Boolean, Integer, Long, Currency, Single, Double, Date, String, and Variant (default).) according to the following guidelines:
| If the parameter field data type is |
Click this data type in the Data Type cell |
| Currency, Date/Time, Memo, OLE Object, Text, and Yes/No |
Currency, Date/Time, Memo, OLE Object, Text, and Yes/No |
| Number |
Byte, Single, Double, Integer, Long Integer, and Replication ID. These data types correspond to the five FieldSize property settings of the Number data type. |
| Unknown |
Value. This is a generic data type that accepts any type of data. |
| Binary |
Binary. Used with parameter queries directed to linked tables (linked table: A table stored in a file outside the open database from which Access can access records. You can add, delete, and edit records in a linked table, but you cannot change its structure.) that do recognize this data type (Microsoft Access does not recognize this data type). |
-
Repeat Steps 2 and 3 for each parameter you want to specify a data type for.
-
Save and run the query.
I'm getting the message "Operation must use an updatable query."
This error occurs when the current query's Update To row includes a field from either a crosstab query or select query in which an aggregate (aggregate function: A function, such as Sum, Count, Avg, or Var, that you use to calculate totals.) (total) was calculated for the field (using either the Totals row or a domain function (domain aggregate function: A function, such as DAvg or DMax, that is used to calculate statistics over a set of records (a domain).) in the Field row). To update a field using the aggregate of another field, calculate the aggregate in the update query itself, not a different query.
- In query Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.) for the current query, remove the field you added from the crosstab or select query (where an aggregate was calculated for the field).
- In the Update To cell of the field you want to update, enter a domain function that calculates the same aggregate as is calculated for that field in the select or crosstab query.
For example, if you had a calculated field (calculated field: A field, defined in a query, that displays the result of an expression rather than displaying stored data. The value is recalculated each time a value in the expression changes.) named Sales So Far in your Products table, you could update it with the product of the Quantity and UnitPrice fields in the Order Details table by adding it to the design grid in the update query and then entering the following domain function in its Update To cell.
DSum("[Quantity] * [UnitPrice]", "Order Details", "[ProductID]=" & [ProductID])
- To run the query, click Run
on the toolbar.
- To see the results, open the table by clicking Tables
under Objects in the Database window and clicking Open on the Database window toolbar.
The wildcard character in my query is behaving unexpectedly.
The two ANSI SQL query modes (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.), ANSI-89 and ANSI-92, are not compatible and use different wildcard characters. For example, if you run:
When you create a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you need to decide which query mode you are going to use because if you create a later query under a different ANSI SQL query mode than the current mode of your Access database, your query could produce runtime errors or unexpected results.
About using wildcard characters to search for partial or matching values
You use wildcard characters as placeholders for other characters when you are specifying a value you want to find and you:
- Know only part of the value.
- Want to find values that start with a specific letter or match a certain pattern.
Wildcard characters are meant to be used with fields that have the Text data type. You can sometimes use them successfully with other data types, such as dates, if you don't use the Microsoft Windows Control Panel to change the regional settings for these data types.
If you are using Microsoft Jet database engine SQL in a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you can use the following wildcard characters in queries (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) and expressions (expression: Any combination of mathematical or logical operators, constants, functions, and names of fields, controls, and properties that evaluates to a single value. Expressions can perform calculations, manipulate characters, or test data.) to find such things as field values, records, or file names. You can also use these characters in the Find and Replace dialog boxes in an Access database or a Microsoft Access project (Microsoft Access project: An Access file that connects to a Microsoft SQL Server database and is used to create client/server applications. A project file doesn't contain any data or data-definition-based objects such as tables and views.).
| Character |
Description |
Example |
| * |
Matches any number of characters. It can be used as the first or last character in the character string. |
wh* finds what, white, and why |
| ? |
Matches any single alphabetic character. |
B?ll finds ball, bell, and bill |
| [ ] |
Matches any single character within the brackets. |
B[ae]ll finds ball and bell but not bill |
| ! |
Matches any character not in the brackets. |
b[!ae]ll finds bill and bull but not ball or bell |
| - |
Matches any one of a range of characters. You must specify the range in ascending order (A to Z, not Z to A). |
b[a-c]d finds bad, bbd, and bcd |
| # |
Matches any single numeric character. |
1#3 finds 103, 113, 123 |
To find such things as field values, records, or file names in a Microsoft Access project, or in a Microsoft Access database that uses Microsoft SQL Server-compatible syntax, use the following ANSI-92 wildcards.
Note If you are using the Find and Replace dialog boxes in an Access project or in an Access database that uses Microsoft SQL Server-compatible syntax, you must use the Microsoft Jet SQL wildcards.
| Character |
Description |
Example |
| % |
Matches any number of characters. It can be used as the first or last character in the character string. |
wh% finds what, white, and why |
| _ |
Matches any single alphabetic character. |
B_ll finds ball, bell, and bill |
| [ ] |
Matches any single character within the brackets. |
B[ae]ll finds ball and bell but not bill |
| ^ |
Matches any character not in the brackets. |
b[^ae]ll finds bill and bull but not ball or bell |
| - |
Matches any one of a range of characters. You must specify the range in ascending order (A to Z, not Z to A). |
b[a-c]d finds bad, bbd, and bcd |
Notes
- When using wildcard characters to search for other wildcard characters such as an asterisk (*), question mark (?), number sign (#), opening bracket ([), or hyphen (-), you must enclose the item you're searching for in brackets. If you're searching for an exclamation point (!) or a closing bracket (]), you don't need to enclose it in brackets.
For example, to search for a question mark, type [?] in the Find dialog box. If you're searching for a hyphen and other characters simultaneously, place the hyphen before or after all the other characters inside the brackets. (However, if you have an exclamation point (!) after the opening bracket, place the hyphen after the exclamation point.)
- You can't search for the opening and closing brackets ([ ]) together because Microsoft Access interprets this combination as a zero-length string (zero-length string: A string that contains no characters. You can use a zero-length string to indicate that you know no value exists for a field. You enter a zero-length string by typing two double quotation marks with no space between them (" ").). You must enclose the opening and closing brackets in brackets ([[ ]]).
The same underlying query behaves differently in a data access page and form.
The query (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) underlying a form (form: An Access database object on which you place controls for taking actions or for entering, displaying, and editing data in fields.) runs under the current ANSI SQL query mode (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.) setting of the Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.). On the other hand, the query underlying a data access page (data access page: A Web page, published from Access, that has a connection to a database. In a data access page, you can view, add to, edit, and manipulate the data stored in the database. A page can also include data from other sources, such as Excel.) always runs under ANSI-92 SQL query mode because a page connects to your Access database by using ADO (ActiveX Data Objects (ADO): A data access interface that communicates with OLE DB-compliant data sources to connect to, retrieve, manipulate, and update data.) and the Microsoft Jet OLE DB provider, both of which can only use ANSI-92 SQL. Therefore, if the SQL query mode setting of your Access database is ANSI-89, the query underlying the form runs as an ANSI-89 query, but the query underlying a page always runs under ANSI-92 regardless of the Access database setting. To resolve this, use a different query for the form and, if possible, rewrite the query for the form to produce the same results as the underlying query for the page. I'm not getting the records I want.
There are too few records.
- If the type of join you're using retrieves only matching records from the two joined tables, any records in which the joined field contains a Null (Null: A value you can enter in a field or use in expressions or queries to indicate missing or unknown data. In Visual Basic, the Null keyword indicates a Null value. Some fields, such as primary key fields, can't contain Null.) value won't be included in the query's results. You can use the Nz function to convert Null values to a zero, zero-length string, or other specified value so that those records are included in the query's results.
- If you specified criteria (criteria: Conditions you specify to limit which records are included in the result set of a query or filter.), it may be too restrictive. For example, if you specified criteria in the Criteria row for two different fields, both criteria must be true for a record before the query retrieves it. You may want to delete some or all of the criteria to allow the query to return more records.
- If you have entered criteria that combine two or more expressions (expression: Any combination of mathematical or logical operators, constants, functions, and names of fields, controls, and properties that evaluates to a single value. Expressions can perform calculations, manipulate characters, or test data.) with an OR operator on more than one criteria row, you must repeat any other expressions in other fields for each criteria row you have used in order for those other expressions to apply to all criteria. For example, if your combined criteria for a ShipCountry field is "Canada" OR "UK", and you want to limit the ExtendedPrice field to <10000 for both countries, enter all the criteria on one criteria row, or repeat the <10000 expression for each criteria row you use.
- Verify that existing criteria is entered correctly. Check for misspellings, unnecessary spaces, or extra characters. Verify that you set the criteria for the appropriate field and that it's the criteria you want the records to meet.
- If a field name includes a colon, you must enclose the name in brackets whenever you refer to the field in an expression. Otherwise, Microsoft Access interprets the field name as a literal text value, and therefore won't retrieve the records you want.
- Use wildcard characters in the criteria if you aren't sure of or don't want to specify the exact field values. If you're already using wildcard characters and not getting the records you want, you may be using the wildcard characters on the wrong data type.
- Add alternative criteria to select the records you want to work with. You can do this in the query design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.) in the Or row, or in the Criteria row using expressions containing the Or operator.
- If you're using criteria to select records containing specific values in a field or fields, any records with Null values in that field don't match the value, and therefore won't be included in the records that are returned. To include records containing Null values, type Is Null in the Or row.
The records are wrong.
- Check the data you're trying to find. If the data contains extra spaces or other special characters, the criteria (criteria: Conditions you specify to limit which records are included in the result set of a query or filter.) must account for this. You can use wildcard characters in the criteria if you aren't sure of or don't want to specify the exact field values. If you're already using wildcard characters and not getting the records you want, you may be using the wildcard characters on the wrong data type.
- Verify that existing criteria is entered correctly. Check for misspellings, unnecessary spaces, or extra characters. Verify that you set the criteria for the appropriate field and that it's the criteria you want the records to meet.
- Verify that the tables and queries you've added to the upper part of query Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.) are the correct ones.
The query is running under a different ANSI SQL query mode.
You created your query (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) under a different ANSI SQL query mode (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.) than the current mode of your Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.).
Why you should avoid mixing queries created under different ANSI SQL query modes
The two ANSI SQL query modes (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.), ANSI-89 and ANSI-92, are not compatible. When you create a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you need to decide which query mode you are going to use, because mixing queries (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) created in both query modes could produce runtime errors or unexpected results. The range of data types, reserved words, and wildcard characters are different in each query mode.
Example of a query using wildcard characters
A query that uses wildcard characters in a criteria expression can produce different results under each query mode. For example, if you run:
- An ANSI-89 SQL query in a database set to ANSI-92 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U*'
It returns all customers from a country/region named "U*", not all countries/region beginning with the letter "U", because the asterisk (*) is not a wildcard character in ANSI-92 SQL.
- An ANSI-92 SQL query in a database set to ANSI-89 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U%'
It returns all customers from a country/region named "U%", not all countries/regions beginning with the letter "U", because the percent sign (%) is not a wildcard character in ANSI-89 SQL.
Example of a query with a duplicate field and alias name
If a query uses an alias that is the same as a base column name and you create a calculated field using the ambiguous name, the query will produce different results under each query mode. For example, if you run the following query:
SELECT Orders.OrderID AS Freight, Orders.Freight, [Freight]*1.1 AS [New Freight] FROM Orders;
Under ANSI-92 SQL, Access calculates the New Freight value using the Freight field, and therefore increases each Freight by 10%. Under ANSI-89 SQL, Access calculates the New Freight value using the Freight alias, and therefore increases each OrderID by 10%.
How to avoid problems caused by mixing queries under different ANSI SQL query modes in the same database
In general, avoid doing the following to prevent problems caused by mixing queries created under different ANSI SQL query modes:
- Converting an Access database set to ANSI-92 SQL query mode from 2002 - 2003 file format to 2000 or 97 file format. ANSI-92 SQL query mode is only supported in the 2002 - 2003 file format.
- Changing the ANSI SQL query mode for the current database after you've created one or more queries. If you must do this, retest the existing queries to ensure that they still run or produce expected results, and rewrite the queries if necessary.
- Importing queries created under one ANSI SQL query mode into an Access database set to another mode, or exporting queries created under one ANSI SQL query mode to an Access database set to another mode.
- Changing the ANSI SQL query mode in an existing application. This could break your application and require rewriting your application.
In Access 2000, you can only programmatically change the ANSI SQL query mode and any queries created under ANSI-92 mode were hidden in the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.). In Access 2002 or later, you or a user can change ANSI SQL query mode through the user interface and ANSI-92 queries are no longer hidden in the Database window, so you should prevent accidental or intentional changes to the ANSI SQL query mode of your application by helping protect your code and preventing the changing of the query mode through the application's user interface.
-
Using ambiguous aliases and column names. To avoid confusion, ensure that aliases and column names are always unique in an SQL statement.
I'm not getting the columns I want.
There are too many columns.
- Remove the fields in the query design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.) that you don't want to see in the query results.
- Remove the asterisk (*) if you added it to the design grid. The asterisk automatically includes all fields from the underlying table. If you want to keep the asterisk (*), clear the Show check box for all fields except the asterisk; otherwise those fields will appear twice in the query's results.
- Hide fields that you don't need to display in the query's results.
- Verify that the Output All Fields check box isn't selected. (To see if it is selected, on the Tools menu, click Options, and then click the Tables/Queries tab.) If it is, all fields from the underlying table or query will appear in the query's results without being added to the query design grid. If you then add a field to the design grid, say, for setting criteria (criteria: Conditions you specify to limit which records are included in the result set of a query or filter.), you need to clear the Show check box for that field; otherwise, the column appears twice in the query's results. If you want, clear the Output All Fields check box. Changing this option affects the property setting for new queries you create, but it doesn't affect existing queries.
There are too few columns.
- Add more fields to the query design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.) or, if you add the asterisk (*) to the design grid, the query automatically includes all fields from the underlying table or query.
- Add other tables or queries, then add the other fields you need.
- Show hidden fields.
- If the Output All Fields check box is not selected, only the fields in the design grid are retrieved. (To see if it is selected, on the Tools menu, click Options, and then click the Tables/Queries tab.) If it is, all fields from the underlying table or query will appear in the query's results without being added to the query design grid. If you then add a field to the design grid, say, for setting criteria (criteria: Conditions you specify to limit which records are included in the result set of a query or filter.), you need to clear the Show check box for that field; otherwise, the column appears twice in the query's results. Or, if you want, clear the Output All Fields check box. Changing this option only affects the property setting for new queries you create, not existing queries.
The query is running under a different ANSI SQL query mode.
You created your query (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) under a different ANSI SQL query mode (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.) than the current mode of your Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.).
Why you should avoid mixing queries created under different ANSI SQL query modes
The two ANSI SQL query modes (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.), ANSI-89 and ANSI-92, are not compatible. When you create a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you need to decide which query mode you are going to use, because mixing queries (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) created in both query modes could produce runtime errors or unexpected results. The range of data types, reserved words, and wildcard characters are different in each query mode.
Example of a query using wildcard characters
A query that uses wildcard characters in a criteria expression can produce different results under each query mode. For example, if you run:
- An ANSI-89 SQL query in a database set to ANSI-92 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U*'
It returns all customers from a country/region named "U*", not all countries/regions beginning with the letter "U", because the asterisk (*) is not a wildcard character in ANSI-92 SQL.
- An ANSI-92 SQL query in a database set to ANSI-89 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U%'
It returns all customers from a country/region named "U%", not all countries/regions beginning with the letter "U", because the percent sign (%) is not a wildcard character in ANSI-89 SQL.
Example of a query with a duplicate field and alias name
If a query uses an alias that is the same as a base column name and you create a calculated field using the ambiguous name, the query will produce different results under each query mode. For example, if you run the following query:
SELECT Orders.OrderID AS Freight, Orders.Freight, [Freight]*1.1 AS [New Freight] FROM Orders;
Under ANSI-92 SQL, Access calculates the New Freight value using the Freight field, and therefore increases each Freight by 10%. Under ANSI-89 SQL, Access calculates the New Freight value using the Freight alias, and therefore increases each OrderID by 10%.
How to avoid problems caused by mixing queries under different ANSI SQL query modes in the same database
In general, avoid doing the following to prevent problems caused by mixing queries created under different ANSI SQL query modes:
- Converting an Access database set to ANSI-92 SQL query mode from 2002 - 2003 file format to 2000 or 97 file format. ANSI-92 SQL query mode is only supported in the 2002 - 2003 file format.
- Changing the ANSI SQL query mode for the current database after you've created one or more queries. If you must do this, retest the existing queries to ensure that they still run or produce expected results, and rewrite the queries if necessary.
- Importing queries created under one ANSI SQL query mode into an Access database set to another mode, or exporting queries created under one ANSI SQL query mode to an Access database set to another mode.
- Changing the ANSI SQL query mode in an existing application. This could break your application and require rewriting your application.
In Access 2000, you can only programmatically change the ANSI SQL query mode and any queries created under ANSI-92 mode were hidden in the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.). In Access 2002 or later, you or a user can change ANSI SQL query mode through the user interface and ANSI-92 queries are no longer hidden in the Database window, so you should prevent accidental or intentional changes to the ANSI SQL query mode of your application by helping protect your code and preventing the changing of the query mode through the application's user interface.
-
Using ambiguous aliases and column names. To avoid confusion, ensure that aliases and column names are always unique in an SQL statement.
I'm not getting the calculation results I expected.
The results of a totals (aggregate) calculation are wrong.
- If there are records with Null (Null: A value you can enter in a field or use in expressions or queries to indicate missing or unknown data. In Visual Basic, the Null keyword indicates a Null value. Some fields, such as primary key fields, can't contain Null.) (blank) values in the field you are calculating, those records won't be included in the calculation.
- If the query isn't performing the calculation on the correct groups, verify that you have Group By in the Total cell for the field or fields you want to use for grouping calculations. Also, where you specify criteria (criteria: Conditions you specify to limit which records are included in the result set of a query or filter.) in the query design grid determines if records are excluded before the query groups or performs calculations, if groups are excluded before the calculation is performed, or if certain results are excluded after the calculation is performed.
- In a crosstab query (crosstab query: A query that calculates a sum, average, count, or other type of total on records, and then groups the result by two types of information: one down the left side of the datasheet and the other across the top.), you might have too many or too few Group By fields. Add, remove, or change the fields designated as row headings that group the totals vertically. Verify that you're using the correct field's values as column headings that group the totals horizontally.
- Verify that the aggregate (aggregate function: A function, such as Sum, Count, Avg, or Var, that you use to calculate totals.) you selected is the correct one. If not, select a different aggregate from the list in the Total cell.
The arithmetic calculation in the design grid returns a Null (blank) value.
If you use an arithmetic operator (such as +, -, *, /) in an expression (expression: Any combination of mathematical or logical operators, constants, functions, and names of fields, controls, and properties that evaluates to a single value. Expressions can perform calculations, manipulate characters, or test data.), such as UnitsInStock] + [UnitsOnOrder], and one of the fields in the expression contains a Null (Null: A value you can enter in a field or use in expressions or queries to indicate missing or unknown data. In Visual Basic, the Null keyword indicates a Null value. Some fields, such as primary key fields, can't contain Null.) value, then the result of the entire expression will be a Null value. To avoid this, you can convert Null values to zeros or other numbers by using the Nz function.
The query is running under a different ANSI SQL query mode.
You created your query (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) under a different ANSI SQL query mode (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.) than the current mode of your Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.).
Why you should avoid mixing queries created under different ANSI SQL query modes
The two ANSI SQL query modes (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.), ANSI-89 and ANSI-92, are not compatible. When you create a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you need to decide which query mode you are going to use, because mixing queries (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) created in both query modes could produce runtime errors or unexpected results. The range of data types, reserved words, and wildcard characters are different in each query mode.
Example of a query using wildcard characters
A query that uses wildcard characters in a criteria expression can produce different results under each query mode. For example, if you run:
- An ANSI-89 SQL query in a database set to ANSI-92 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U*'
It returns all customers from a country/region named "U*", not all countries/regions beginning with the letter "U", because the asterisk (*) is not a wildcard character in ANSI-92 SQL.
- An ANSI-92 SQL query in a database set to ANSI-89 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U%'
It returns all customers from a country/region named "U%", not all countries/regions beginning with the letter "U", because the percent sign (%) is not a wildcard character in ANSI-89 SQL.
Example of a query with a duplicate field and alias name
If a query uses an alias that is the same as a base column name and you create a calculated field using the ambiguous name, the query will produce different results under each query mode. For example, if you run the following query:
SELECT Orders.OrderID AS Freight, Orders.Freight, [Freight]*1.1 AS [New Freight] FROM Orders;
Under ANSI-92 SQL, Access calculates the New Freight value using the Freight field, and therefore increases each Freight by 10%. Under ANSI-89 SQL, Access calculates the New Freight value using the Freight alias, and therefore increases each OrderID by 10%.
How to avoid problems caused by mixing queries under different ANSI SQL query modes in the same database
In general, avoid doing the following to prevent problems caused by mixing queries created under different ANSI SQL query modes:
- Converting an Access database set to ANSI-92 SQL query mode from 2002 - 2003 file format to 2000 or 97 file format. ANSI-92 SQL query mode is only supported in the 2002 -2003 file format.
- Changing the ANSI SQL query mode for the current database after you've created one or more queries. If you must do this, retest the existing queries to ensure that they still run or produce expected results, and rewrite the queries if necessary.
- Importing queries created under one ANSI SQL query mode into an Access database set to another mode, or exporting queries created under one ANSI SQL query mode to an Access database set to another mode.
- Changing the ANSI SQL query mode in an existing application. This could break your application and require rewriting your application.
In Access 2000, you can only programmatically change the ANSI SQL query mode and any queries created under ANSI-92 mode were hidden in the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.). In Access 2002 or later, you or a user can change ANSI SQL query mode through the user interface and ANSI-92 queries are no longer hidden in the Database window, so you should prevent accidental or intentional changes to the ANSI SQL query mode of your application by helping protect your code and preventing the changing of the query mode through the application's user interface.
-
Using ambiguous aliases and column names. To avoid confusion, ensure that aliases and column names are always unique in an SQL statement.
Specific types of queries Select queries
My AutoLookup query isn't filling in data.
For AutoLookup to work, certain conditions must be met:
- The query must be based on more than one table and the tables must have a one-to-many relationship (one-to-many relationship: An association between two tables in which the primary key value of each record in the primary table corresponds to the value in the matching field or fields of many records in the related table.). (Referential integrity (referential integrity: Rules that you follow to preserve the defined relationships between tables when you enter or delete records.) doesn't have to be enforced.)
- The join (join: An association between a field in one table or query and a field of the same data type in another table or query. Joins tell the program how data is related. Records that don't match may be included or excluded, depending on the type of join.) field on the "one" side of the relationship must have a unique index (unique index: An index defined by setting a field's Indexed property to Yes (No Duplicates). A unique index will not allow duplicate entries in the indexed field. Setting a field as the primary key automatically defines the field as unique.). A unique index means that the field is a primary key (primary key: One or more fields (columns) whose values uniquely identify each record in a table. A primary key cannot allow Null values and must always have a unique index. A primary key is used to relate a table to foreign keys in other tables.) or its Indexed property in table Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.) is set to Yes (No Duplicates).
- The join field you add to the design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.) must come from the table on the "many" side of the one-to-many relationship. (In other words, it's the foreign key (foreign key: One or more table fields (columns) that refer to the primary key field or fields in another table. A foreign key indicates how the tables are related.) for that table.) For AutoLookup to work, this field can't be a primary key and its Indexed property can't be set to Yes (No Duplicates). For example, in a query that includes the Customers and Orders tables, drag to the design grid the CustomerID field from the Orders table, not the one from the Customers table.
- The value you enter in the join field from the "many" side must already exist in the join field from the "one" side.
Microsoft Access automatically joins tables or queries I don't want joined.
Even if you haven't created relationships (relationship: An association that is established between common fields (columns) in two tables. A relationship can be one-to-one, one-to-many, or many-to-many.) between tables, Microsoft Access automatically creates joins if you add two tables to a query and the tables each have a field with the same or compatible data type (data type: The characteristic of a field that determines what type of data it can hold. Data types include Boolean, Integer, Long, Currency, Single, Double, Date, String, and Variant (default).) and if one of the join fields is a primary key (primary key: One or more fields (columns) whose values uniquely identify each record in a table. A primary key cannot allow Null values and must always have a unique index. A primary key is used to relate a table to foreign keys in other tables.). You can enable or disable these automatic joins.
- On the Tools menu, click Options.
- Click the Tables/Queries tab.
- Select or clear the Enable AutoJoin check box.
Note This setting applies to new queries only.
I can't update data from a query.
In some cases, you can edit data in query Datasheet view (Datasheet view: A window that displays data from a table, form, query, view, or stored procedure in a row-and-column format. In Datasheet view, you can edit fields, add and delete data, and search for data.) to change the data in the underlying table. In other cases, you can't. The following information shows whether a query's results can be updated, and if not, whether there is an alternative.
Data is updatable
You can update a query or query field in the following cases:
- A query based on one table
- A query based on tables with a one-to-one relationship (one-to-one relationship: An association between two tables in which the primary key value of each record in the primary table corresponds to the value in the matching field or fields of one, and only one, record in the related table.)
- The query's results contain a Memo (Memo data type: In a Microsoft Access database, this is a field data type. Memo fields can contain up to 65,535 characters.), Hyperlink (hyperlink field: A field that stores hyperlink addresses. In an Access database (.mdb), it's a field with a Hyperlink data type. In an Access project (.adp), it's a field that has the IsHyperlink property set to True.), or OLE Object (OLE object: An object supporting the OLE protocol for object linking and embedding. An OLE object from an OLE server (for example, a Windows Paint picture or a Microsoft Excel spreadsheet) can be linked or embedded in a field, form, or report.)
Data can't be updated
| Query or query field |
Solution |
| Query based on three or more tables in which there is a many-to-one-to-many relationship |
Though you can't update the data in the query directly, you can update the data in a form or data access page (data access page: A Web page, published from Access, that has a connection to a database. In a data access page, you can view, add to, edit, and manipulate the data stored in the database. A page can also include data from other sources, such as Excel.) based on the query if the form's RecordsetType property is set to Dynaset (Inconsistent Updates). |
| Crosstab query (crosstab query: A query that calculates a sum, average, count, or other type of total on records, and then groups the result by two types of information: one down the left side of the datasheet and the other across the top.) |
None |
| SQL pass-through query (pass-through query: An SQL-specific query you use to send commands directly to an ODBC database server. By using pass-through queries, you work directly with the tables on the server instead of having the Microsoft Jet database engine process the data.) |
None |
| Query that calculates a sum, average, count or other type of total on the values in a field, or an update query that references a field in the Update To row from either a crosstab query, select query (select query: A query that asks a question about the data stored in your tables and returns a result set in the form of a datasheet, without changing the data.), or subquery (subquery: An SQL SELECT statement that is inside another select or action query.) that contains totals or aggregate functions |
By using a domain aggregate function (domain aggregate function: A function, such as DAvg or DMax, that is used to calculate statistics over a set of records (a domain).) in the Update To row of an update query, you can reference fields from either a crosstab query, select query, or subquery that contains totals or aggregate functions. |
| Union query (union query: A query that uses the UNION operator to combine the results of two or more select queries.) |
None |
| Query whose UniqueValues property is set to Yes |
None |
| Query that includes a linked ODBC (Open Database Connectivity (ODBC): A standard method of sharing data between databases and programs. ODBC drivers use the standard Structured Query Language (SQL) to gain access to external data.) table with no unique index (unique index: An index defined by setting a field's Indexed property to Yes (No Duplicates). A unique index will not allow duplicate entries in the indexed field. Setting a field as the primary key automatically defines the field as unique.), or a Paradox table without a primary key (primary key: One or more fields (columns) whose values uniquely identify each record in a table. A primary key cannot allow Null values and must always have a unique index. A primary key is used to relate a table to foreign keys in other tables.) |
None |
| Query that includes more than one table or query, and the tables or queries aren't joined by a join line in Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.) |
You must join the tables properly in order to update them. |
| Calculated field (calculated field: A field, defined in a query, that displays the result of an expression rather than displaying stored data. The value is recalculated each time a value in the expression changes.) |
None |
| Field is read-only; the database was opened as read-only or is located on a read-only drive |
None |
| Field in record that has been deleted or locked (locked: The condition of a record, recordset, or database that makes it read-only to all users except the user currently modifying it.) by another user |
A locked record should be updatable as soon as it is unlocked. |
I get prompted for a parameter when I don't expect it.
If you get prompted to type parameters when you attempt to run a query, report, or data access page (data access page: A Web page, published from Access, that has a connection to a database. In a data access page, you can view, add to, edit, and manipulate the data stored in the database. A page can also include data from other sources, such as Excel.), and you don't expect this prompt, one of the following might apply:
The query is running under a different ANSI SQL query mode.
You created your query (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) under a different ANSI SQL query mode (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.) than the current mode of your Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.).
Why you should avoid mixing queries created under different ANSI SQL query modes
The two ANSI SQL query modes (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.), ANSI-89 and ANSI-92, are not compatible. When you create a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you need to decide which query mode you are going to use, because mixing queries (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) created in both query modes could produce runtime errors or unexpected results. The range of data types, reserved words, and wildcard characters are different in each query mode.
Example of a query using wildcard characters
A query that uses wildcard characters in a criteria expression can produce different results under each query mode. For example, if you run:
- An ANSI-89 SQL query in a database set to ANSI-92 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U*'
It returns all customers from a country/region named "U*", not all countries/regions beginning with the letter "U", because the asterisk (*) is not a wildcard character in ANSI-92 SQL.
- An ANSI-92 SQL query in a database set to ANSI-89 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U%'
It returns all customers from a country/region named "U%", not all countries/regions beginning with the letter "U", because the percent sign (%) is not a wildcard character in ANSI-89 SQL.
Example of a query with a duplicate field and alias name
If a query uses an alias that is the same as a base column name and you create a calculated field using the ambiguous name, the query will produce different results under each query mode. For example, if you run the following query:
SELECT Orders.OrderID AS Freight, Orders.Freight, [Freight]*1.1 AS [New Freight] FROM Orders;
Under ANSI-92 SQL, Access calculates the New Freight value using the Freight field, and therefore increases each Freight by 10%. Under ANSI-89 SQL, Access calculates the New Freight value using the Freight alias, and therefore increases each OrderID by 10%.
How to avoid problems caused by mixing queries under different ANSI SQL query modes in the same database
In general, avoid doing the following to prevent problems caused by mixing queries created under different ANSI SQL query modes:
- Converting an Access database set to ANSI-92 SQL query mode from 2002 - 2003 file format to 2000 or 97 file format. ANSI-92 SQL query mode is only supported in the 2002 - 2003 file format.
- Changing the ANSI SQL query mode for the current database after you've created one or more queries. If you must do this, retest the existing queries to ensure that they still run or produce expected results, and rewrite the queries if necessary.
- Importing queries created under one ANSI SQL query mode into an Access database set to another mode, or exporting queries created under one ANSI SQL query mode to an Access database set to another mode.
- Changing the ANSI SQL query mode in an existing application. This could break your application and require rewriting your application.
In Access 2000, you can only programmatically change the ANSI SQL query mode and any queries created under ANSI-92 mode were hidden in the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.). In Access 2002 or later, you or a user can change ANSI SQL query mode through the user interface and ANSI-92 queries are no longer hidden in the Database window, so you should prevent accidental or intentional changes to the ANSI SQL query mode of your application by helping protect your code and preventing the changing of the query mode through the application's user interface.
-
Using ambiguous aliases and column names. To avoid confusion, ensure that aliases and column names are always unique in an SQL statement.
Parameter queries
I get prompted for a parameter when I don't expect it.
If you get prompted to type parameters when you attempt to run a query, report, or data access page (data access page: A Web page, published from Access, that has a connection to a database. In a data access page, you can view, add to, edit, and manipulate the data stored in the database. A page can also include data from other sources, such as Excel.), and you don't expect this prompt, one of the following might apply:
The query is running under a different ANSI SQL query mode.
You created your query (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) under a different ANSI SQL query mode (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.) than the current mode of your Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.).
Why you should avoid mixing queries created under different ANSI SQL query modes
The two ANSI SQL query modes (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.), ANSI-89 and ANSI-92, are not compatible. When you create a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you need to decide which query mode you are going to use, because mixing queries (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) created in both query modes could produce runtime errors or unexpected results. The range of data types, reserved words, and wildcard characters are different in each query mode.
Example of a query using wildcard characters
A query that uses wildcard characters in a criteria expression can produce different results under each query mode. For example, if you run:
- An ANSI-89 SQL query in a database set to ANSI-92 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U*'
It returns all customers from a country/region named "U*", not all countries/regions beginning with the letter "U", because the asterisk (*) is not a wildcard character in ANSI-92 SQL.
- An ANSI-92 SQL query in a database set to ANSI-89 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U%'
It returns all customers from a country/region named "U%", not all countries/regions beginning with the letter "U", because the percent sign (%) is not a wildcard character in ANSI-89 SQL.
Example of a query with a duplicate field and alias name
If a query uses an alias that is the same as a base column name and you create a calculated field using the ambiguous name, the query will produce different results under each query mode. For example, if you run the following query:
SELECT Orders.OrderID AS Freight, Orders.Freight, [Freight]*1.1 AS [New Freight] FROM Orders;
Under ANSI-92 SQL, Access calculates the New Freight value using the Freight field, and therefore increases each Freight by 10%. Under ANSI-89 SQL, Access calculates the New Freight value using the Freight alias, and therefore increases each OrderID by 10%.
How to avoid problems caused by mixing queries under different ANSI SQL query modes in the same database
In general, avoid doing the following to prevent problems caused by mixing queries created under different ANSI SQL query modes:
- Converting an Access database set to ANSI-92 SQL query mode from 2002 - 2003 file format to 2000 or 97 file format. ANSI-92 SQL query mode is only supported in the 2002 - 2003 file format.
- Changing the ANSI SQL query mode for the current database after you've created one or more queries. If you must do this, retest the existing queries to ensure that they still run or produce expected results, and rewrite the queries if necessary.
- Importing queries created under one ANSI SQL query mode into an Access database set to another mode, or exporting queries created under one ANSI SQL query mode to an Access database set to another mode.
- Changing the ANSI SQL query mode in an existing application. This could break your application and require rewriting your application.
In Access 2000, you can only programmatically change the ANSI SQL query mode and any queries created under ANSI-92 mode were hidden in the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.). In Access 2002 or later, you or a user can change ANSI SQL query mode through the user interface and ANSI-92 queries are no longer hidden in the Database window, so you should prevent accidental or intentional changes to the ANSI SQL query mode of your application by helping protect your code and preventing the changing of the query mode through the application's user interface.
-
Using ambiguous aliases and column names. To avoid confusion, ensure that aliases and column names are always unique in an SQL statement.
Crosstab queries
The wrong field values are showing as row or column headings.
Verify that the field whose values you want to use as column headings is in the query design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.) with Column Heading in the Crosstab cell, and that the field or fields whose values you want to use as row headings are in the query design grid with Row Heading in the Crosstab cell. To change the value in a Crosstab cell, click the cell, and then click a value from the list. If you want to display only certain values as column headings, set the query's ColumnHeadings property.
Sort or limit column headings displayed in a crosstab query
You can change the order or limit the column headings in a crosstab query (crosstab query: A query that calculates a sum, average, count, or other type of total on records, and then groups the result by two types of information: one down the left side of the datasheet and the other across the top.). For example, in column headings containing the months of the year, you can display the months chronologically rather than alphabetically. Or, you can limit the columns to just January through June.
- Open the crosstab query in Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.).
- Click the background of query Design view, outside the design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.) and the field lists (field list: A window that lists all the fields in the underlying record source or database object, except in data access page Design view. In data access page Design view, it lists all the record sources and their fields in the underlying database.).
- On the toolbar, click Properties
to display the query's property sheet.
- In the ColumnHeadings property box, enter the column headings you want to display, in the order in which you want to display them. Between the column headings, type a comma or the list separator for your country/region. (To find the list separator for your country/region, see the regional settings in Microsoft Windows Control Panel.)
The column headings you enter must exactly match the column headings in the query datasheet. For example, if a column heading in the datasheet is "USA," you must enter a column heading of "USA"— not "US." (After you press ENTER or move the pointer to a different location, Microsoft Access places quotation marks around each heading.)
- To view the query's results, click View
on the toolbar.
Notes
- If you run a crosstab query often, or if you use it as the basis for a form, report, or data access page (data access page: A Web page, published from Access, that has a connection to a database. In a data access page, you can view, add to, edit, and manipulate the data stored in the database. A page can also include data from other sources, such as Excel.), you can speed up the query by using the preceding procedure to specify fixed column headings.
- If you frequently use the same column headings in different queries, consider creating a table with one Text (Text data type: In a Microsoft Access database, this is a field data type. Text fields can contain up to 255 characters or the number of characters specified by the FieldSize property, whichever is less.) field to store the column headings. Then open the table and copy the headings into the ColumnHeadings property box as needed.
The query is running under a different ANSI SQL query mode.
You created your query (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) under a different ANSI SQL query mode (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.) than the current mode of your Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.).
Why you should avoid mixing queries created under different ANSI SQL query modes
The two ANSI SQL query modes (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.), ANSI-89 and ANSI-92, are not compatible. When you create a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you need to decide which query mode you are going to use, because mixing queries (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) created in both query modes could produce runtime errors or unexpected results. The range of data types, reserved words, and wildcard characters are different in each query mode.
Example of a query using wildcard characters
A query that uses wildcard characters in a criteria expression can produce different results under each query mode. For example, if you run:
- An ANSI-89 SQL query in a database set to ANSI-92 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U*'
It returns all customers from a country/region named "U*", not all countries/regions beginning with the letter "U", because the asterisk (*) is not a wildcard character in ANSI-92 SQL.
- An ANSI-92 SQL query in a database set to ANSI-89 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U%'
It returns all customers from a country/region named "U%", not all countries/regions beginning with the letter "U", because the percent sign (%) is not a wildcard character in ANSI-89 SQL.
Example of a query with a duplicate field and alias name
If a query uses an alias that is the same as a base column name and you create a calculated field using the ambiguous name, the query will produce different results under each query mode. For example, if you run the following query:
SELECT Orders.OrderID AS Freight, Orders.Freight, [Freight]*1.1 AS [New Freight] FROM Orders;
Under ANSI-92 SQL, Access calculates the New Freight value using the Freight field, and therefore increases each Freight by 10%. Under ANSI-89 SQL, Access calculates the New Freight value using the Freight alias, and therefore increases each OrderID by 10%.
How to avoid problems caused by mixing queries under different ANSI SQL query modes in the same database
In general, avoid doing the following to prevent problems caused by mixing queries created under different ANSI SQL query modes:
- Converting an Access database set to ANSI-92 SQL query mode from 2002 - 2003 file format to 2000 or 97 file format. ANSI-92 SQL query mode is only supported in the 2002 - 2003 file format.
- Changing the ANSI SQL query mode for the current database after you've created one or more queries. If you must do this, retest the existing queries to ensure that they still run or produce expected results, and rewrite the queries if necessary.
- Importing queries created under one ANSI SQL query mode into an Access database set to another mode, or exporting queries created under one ANSI SQL query mode to an Access database set to another mode.
- Changing the ANSI SQL query mode in an existing application. This could break your application and require rewriting your application.
In Access 2000, you can only programmatically change the ANSI SQL query mode and any queries created under ANSI-92 mode were hidden in the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.). In Access 2002 or later, you or a user can change ANSI SQL query mode through the user interface and ANSI-92 queries are no longer hidden in the Database window, so you should prevent accidental or intentional changes to the ANSI SQL query mode of your application by helping protect your code and preventing the changing of the query mode through the application's user interface.
-
Using ambiguous aliases and column names. To avoid confusion, ensure that aliases and column names are always unique in an SQL statement.
Action queries (append, update, delete)
The update query didn't perform the update I wanted.
- You need to specify a different update by changing the expression (expression: Any combination of mathematical or logical operators, constants, functions, and names of fields, controls, and properties that evaluates to a single value. Expressions can perform calculations, manipulate characters, or test data.) in the Update To cell. For example, to raise salaries by 5 percent, type [Salary] * 1.05 in the Update To cell of the Salary field.
- Verify that you're updating data in the correct field. If you're updating data in the wrong field, specify an update for a different field. To specify an update for a field, type the expression you want in the Update To cell.
I don't know the best way to delete duplicate records after using the Find Duplicates Wizard.
Delete the duplicate record or the original directly in query Datasheet view (Datasheet view: A window that displays data from a table, form, query, view, or stored procedure in a row-and-column format. In Datasheet view, you can edit fields, add and delete data, and search for data.).
Delete a record
Delete a record in a datasheet or form
- Open a datasheet (Datasheet view: A window that displays data from a table, form, query, view, or stored procedure in a row-and-column format. In Datasheet view, you can edit fields, add and delete data, and search for data.), or open a form in Form view (Form view: A window that displays a form to show or accept data. Form view is the primary means of adding and modifying data in tables. You can also change the design of a form in this view.).
- Click the record you want to delete.
- Click Delete Record
on the toolbar.
Note When you delete data, you might want to delete related data in other tables. For example, if you delete a supplier, you probably want to delete the products that the supplier supplies. In some cases, you can make sure the proper data is deleted by enforcing referential integrity (referential integrity: Rules that you follow to preserve the defined relationships between tables when you enter or delete records.) and turning on cascade deletions.
Delete a record in a data access page
Important Once you delete a record, you cannot undo the deletion from the database.
- On the record navigation toolbar, click Delete
.
Note If you don't see the Delete button, it means one of the following:
- The page does not support deletions.
- The designer of the page has customized the button. Look for custom instructions on how to use the page, or contact the designer.
If you want Microsoft Access to delete all the duplicates and keep the original records automatically, don't use the Find Duplicates Wizard or convert a Find Duplicates query to a delete query.
Delete duplicate records from a table
Deleting duplicate records from a table requires two steps. First, you create a copy of the structure of the table that contains duplicates, and then make primary keys (primary key: One or more fields (columns) whose values uniquely identify each record in a table. A primary key cannot allow Null values and must always have a unique index. A primary key is used to relate a table to foreign keys in other tables.) of all the fields that contain duplicates. Second, you create and run an append query (append query: An action query that adds the records in a query's result set to the end of an existing table.) from the original table to the new table. Because fields that are primary keys can't contain duplicate records, this procedure produces a table without duplicate records.
- Copy the table and make primary keys of fields with duplicates.
How?
- In the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.), click Tables
under Objects.
- Click the name of the table you want to delete duplicate records from.
- Click Copy
on the toolbar (toolbar: A bar with buttons and options that you use to carry out commands. To display a toolbar, click Customize on the Tools menu, and then click the Toolbars tab.).
- Click Paste
on the toolbar.
- In the Paste Table As dialog box, type a name for the copied table, click Structure Only, and then click OK.
- Open the new table in Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.), and select the fields that contained duplicates in the table you copied.
- Click Primary Key
on the toolbar to create a primary key based on the selected fields.
- Save and close the table.
- Append only unique records to the new table.
How?
- Create a new query based on the original table that contains duplicates.
- In query Design view (Design view: A window that shows the design of these database objects: tables, queries, forms, reports, macros, and data access pages. In Design view, you can create new database objects and modify the design of existing ones.), click Query Type
on the toolbar, and then click Append Query.
- In the Append dialog box, click the name of the new table in the Table Name list, and then click OK.
- Include all the fields from the original table by dragging the asterisk (*) to the query design grid (design grid: The grid that you use to design a query or filter in query Design view or in the Advanced Filter/Sort window. For queries, this grid was formerly known as the QBE grid.).
- Click Run
on the toolbar.
- Click Yes when you receive the message that you're about to append rows.
- Click Yes when you receive the message that Microsoft Access can't append all the records in the append query. This transfers only unique records to your new table and discards the duplicates.
- Open the table to see the results.
- When you're sure the new table has the correct unique records, you can delete the original table, and then rename the new table using the name of the original table.
The delete query deleted records from the wrong table.
Make sure the delete query includes:
In the query design grid, From or Where is displayed in the Delete row. From is displayed in the Delete cell of the table you'll delete records from, and Where is displayed in the Delete cell of the field(s) you specify criteria for.
The query is running under a different ANSI SQL query mode.
You created your query (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) under a different ANSI SQL query mode (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.) than the current mode of your Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.).
Why you should avoid mixing queries created under different ANSI SQL query modes
The two ANSI SQL query modes (ANSI SQL query mode: One of two types of SQL syntax: ANSI-89 SQL (also called Microsoft Jet SQL and ANSI SQL), which is the traditional Jet SQL syntax; and ANSI-92 SQL, which has new and different reserved words, syntax rules, and wildcard characters.), ANSI-89 and ANSI-92, are not compatible. When you create a Microsoft Access database (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose. The Microsoft Jet database engine manages the data.), you need to decide which query mode you are going to use, because mixing queries (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form, report, or data access page.) created in both query modes could produce runtime errors or unexpected results. The range of data types, reserved words, and wildcard characters are different in each query mode.
Example of a query using wildcard characters
A query that uses wildcard characters in a criteria expression can produce different results under each query mode. For example, if you run:
- An ANSI-89 SQL query in a database set to ANSI-92 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U*'
It returns all customers from a country/region named "U*", not all countries/regions beginning with the letter "U", because the asterisk (*) is not a wildcard character in ANSI-92 SQL.
- An ANSI-92 SQL query in a database set to ANSI-89 query mode, such as:
SELECT * FROM Customers WHERE Country Like 'U%'
It returns all customers from a country/region named "U%", not all countries/regions beginning with the letter "U", because the percent sign (%) is not a wildcard character in ANSI-89 SQL.
Example of a query with a duplicate field and alias name
If a query uses an alias that is the same as a base column name and you create a calculated field using the ambiguous name, the query will produce different results under each query mode. For example, if you run the following query:
SELECT Orders.OrderID AS Freight, Orders.Freight, [Freight]*1.1 AS [New Freight] FROM Orders;
Under ANSI-92 SQL, Access calculates the New Freight value using the Freight field, and therefore increases each Freight by 10%. Under ANSI-89 SQL, Access calculates the New Freight value using the Freight alias, and therefore increases each OrderID by 10%.
How to avoid problems caused by mixing queries under different ANSI SQL query modes in the same database
In general, avoid doing the following to prevent problems caused by mixing queries created under different ANSI SQL query modes:
- Converting an Access database set to ANSI-92 SQL query mode from 2002 - 2003 file format to 2000 or 97 file format. ANSI-92 SQL query mode is only supported in the 2002 - 2003 file format.
- Changing the ANSI SQL query mode for the current database after you've created one or more queries. If you must do this, retest the existing queries to ensure that they still run or produce expected results, and rewrite the queries if necessary.
- Importing queries created under one ANSI SQL query mode into an Access database set to another mode, or exporting queries created under one ANSI SQL query mode to an Access database set to another mode.
- Changing the ANSI SQL query mode in an existing application. This could break your application and require rewriting your application.
In Access 2000, you can only programmatically change the ANSI SQL query mode and any queries created under ANSI-92 mode were hidden in the Database window (Database window: The window that appears when you open an Access database or an Access project. It displays shortcuts for creating new database objects and opening existing objects.). In Access 2002 or later, you or a user can change ANSI SQL query mode through the user interface and ANSI-92 queries are no longer hidden in the Database window, so you should prevent accidental or intentional changes to the ANSI SQL query mode of your application by helping protect your code and preventing the changing of the query mode through the application's user interface.
-
Using ambiguous aliases and column names. To avoid confusion, ensure that aliases and column names are always unique in an SQL statement.
|