Running Microsoft Access 97

Chapter 9: Modifying Data with Action Queries

Troubleshooting Action Queries

Microsoft Access analyzes your action query request and the data you are about to change before it commits changes to your database. When it identifies errors, Access always gives you an opportunity to cancel the operation.

Common Action
Query Errors and Problems

Access identifies (traps) four types of errors during the execution of an action query:

• Duplicate primary keys. This type of error occurs if you attempt to append a record to a table or update a record in a table when the result is a duplicate primary key or a duplicate of a unique index key value. Access will not update or append any rows that would create duplicate values in primary keys or unique indexes. For example, if the primary key of a contract archive table is ContractID, Access won't append a record that contains a ContractID already in the table. Before attempting to append such rows, you might have to change the primary key values in the source table to avoid the conflict.
• Data conversion errors. This type of error occurs when you attempt to append data to an existing table and the data type of the receiving field does not match that of the sending field (and the data in the sending field cannot be converted to the appropriate data type). For example, this error will occur if you attempt to append a text field to an integer field and the text field contains either alphabetic characters or a number string that is too large for the integer field. You might also encounter a conversion error in an update query if you use a formula that attempts a calculation on a fieldthat contains characters. (For information on data conversions and potential limitations, see Table 6-1 in Chapter 6, 'Modifying Your Database Design.')
• Locked records. This type of error can occur when you run a delete query or an update query on a table that you share with other users on a network . Access cannot update records that are in the process of being updated by some other user. You might want to wait and try again later when no one else is using the affected records to be sure that your update or deletion occurs.
• Validation rule violations. if any of the rows being inserted or any row being updated violates either a field validation rule or the table validation rule, Access notifies you of an error and does not insert or update any of the rows that fail the validation test.

Another problem that can occur, although it isn't an error as such, is that Access truncates data that is being appended to text or memo fields if the data does not fit. Access does not warn you when this happens. You must be sure (especially with append queries) that the receiving text and memo fields have been defined as large enough to store the incoming data.

An Error Example

Earlier in this chapter, you learned how to create an append query to copy old contracts to an archive table. What do you suppose would happen if you copied rows through September 30, 1996, forgot to delete them from the main table, and then later asked to copy rows through December 31, 1996? If you try this starting with an empty archive table in the Entertainment Schedule database, you'll get an error dialog box similar to the one shown in Figure 9-22.

The dialog box declares that 35 records won't be inserted because of duplicate primary key values. Access didn't find any data conversion errors. Note that if some fields have conversion problems, Access might still append the row but leave the field set to Null. Because this table isn't shared on a network, there aren't any locking errors. When you see this dialog box, you can click the Yes button to proceed with the changes that Access can make without errors. You might find it difficult later, however, to track down all the records that were not updated successfully. Click the No button to cancel the append query.

Deleting Groups of Rows

You're not likely to keep all the data in your database forever. You'll probably summarize some of your detailed information as time goes by and then delete the data you no longer need. You can remove sets of records from your database using a delete query.

Testing with a Select
Query and Parameters

Once you have calculated and saved all the sales data and moved old contracts to the archive table, you should remove the contracts from the active table. This is clearly the kind of query that you will want to save so that you can use it again and again. You can design the query to automatically calculate which records to delete based on the current system date. (If you do this, you should probably change the query qryXmplArchiveOldContracts to work the same way.) The query can also be designed with a parameter so that a user can specify which data to delete when you run the query. Either design makes it unnecessary to change the query at each use.

As with an update query, it's a good idea to test which rows will be affected by a delete query by first building a select query to isolate these records. Start a new query on tblContracts and include the asterisk (*) field. Add the BeginningDate field to the design grid, deselect the Show check box, and add either a parameter criterion or something like Date( ) - 366 (to see all contracts that are more than a year old). If you use a parameter criterion and convert this select query to a delete query, your result should look like that shown in Figure 9-23....