Data Manipulation Language (DML) commands are implemented by action queries: append, update, delete, and make-table. Jet uses QueryDefs for action queries; ADP require stored procedures or functions to support INSERT, UPDATE, DELETE, and SELECT...INTO statements. This section shows the standard syntax for each type of action query, which is identical in Jet SQL and T-SQL. Append queries use the following syntax: INSERT INTO dest_table SELECT [ALL|DISTINCT] select_list FROM source_table [WHERE append_criteria] If you omit the WHERE clause, specified field values of all records of source_table are appended to dest_table. The source_table must exist and have columns that correspond to those you specify in select_list.
For an example of a stored procedure that appends records, see "Adding Records with Append Stored Procedures," p. 831. UPDATE queries use the SET command to assign values to individual columns: UPDATE table_name SET column_name = value [, column_name = value[,...]] [WHERE update_criteria] Separate multiple column_name = value entries by commas if you want to update the data in more than one field. If you omit the WHERE clause, the SET expression acts on every record of the table, which probably isn't your intention. Jet SQL and T-SQL support the ANSI SQL VALUES keyword for adding records to or updating tables the hard way (specifying the value of each column of each record). The later "Taking Advantage of Transactions in Stored Procedures" section has a T-SQL statement that uses the VALUES approach. DELETE queries take the following form: DELETE FROM table_name [WHERE delete_criteria] If you omit the optional WHERE clause in a DELETE query, you delete all records from table_name.
To review creating DELETE stored procedures in the project designer, see "Deleting Table Records," p. 834. Make-table queries use the following syntax: SELECT [ALL|DISTINCT] select_list INTO new_table FROM source_table [WHERE append_criteria] To copy the original table, substitute an asterisk (*) for select_list and omit the optional WHERE clause. Data types and sizes in the new_table are the same as those of the source_table. If your SQL Server source_table has a computed column, the corresponding column in the new_table contains the computed values, not the expression used to compute the column.
For an example of a simple make-table stored procedure, see "Creating and Executing Make-Table and Update Stored Procedures" p. 828. You can execute any of the preceding SQL statements directly against Jet or SQL Server tables from VBA code and an ActiveX Data Objects (ADO) Connection object. Using VBA code to execute SQL statements directly, rather than designing stored procedures for action queries or views and functions to return Recordsets is an option for ADP. Chapter 30, "Understanding Universal Data Access, OLE DB, and ADO," provides examples of generating and executing SQL statements with VBA code. Specifying Parameters for Criteria and Update ValuesWhen you design Jet queries or stored procedures to update table data, you specify parameters to supply values to WHERE clause criteria and, for INSERT and UPDATE queries, field values. If you specify the data type for input parameters, Jet adds a PARAMETERS declaration that precedes the SQL statement. The sequence of the parameter values in the declaration determines the order in which the Enter Parameter Value dialogs appear.
T-SQL uses variables to store parameter values; SQL Server identifies user variables by an @ prefix. T-SQL supports input and output parameters, and return values; this section deals only with input parameters, which are by far the most common type.
The right side of the SET expression, = @Quantity, appears in the New Value cell of the Quantity row of the project designer's grid. The WHERE clause variables appear as = @OrderID and = @ProductID in the Criteria column. Unlike Jet parameters, you can't change the sequence of appearance of the Enter Parameter Value dialogs by rearranging the rows of the grid; the dialog to enter the UPDATE variable always opens first. Note When you execute the preceding UPDATE query, you receive a "The stored procedure executed successfully, but did not return records" message no matter what values you type in the three parameter dialogs (including nothing). Stored procedures that update tables should include T-SQL code to test for parameter value entry errors, especially when you execute them interactively. The "Programming Stored Procedures" topic of SQL Server Books Online has an example of a test for a missing (NULL) parameter value. If you don't clear the Confirm Action Queries check box on the Option dialog's Edit/Find page, Jet action queries display the number of rows that will be affected by execution. The Confirm Record Changes check box values don't apply to execution of T-SQL stored procedures or functions. Taking Advantage of Transactions in Stored ProceduresUnless you specify otherwise, Jet automatically uses transaction processing when updating data in multiple tables with a single SQL statement. SQL Server requires explicit declaration of the beginning of the transaction and its end. When you write a T-SQL statement that makes changes to more than one table, wrap the statement with BEGIN TRAN[SACTION] and COMMIT TRAN[SACTION] statements, as illustrated by the following simple example.
The following stored procedure is one of several that were used to create the NwindXL19.mdb files for Chapter 19, "Linking Access Front-Ends to Jet and Client/Server Tables." The AddOrders.adp application adds four stored procedures to a modified copy of the NorthwindCS database, including the preceding example. The only modification to the copy of the database is removal of the IDENTITY attribute from the OrderID field of the Orders table to permit adding and deleting records while adding records that have consecutive order numbers. Instead of an identity column, the procedure checks for the last OrderID value and adds 1 for the new order number.
Following are brief descriptions of the new T-SQL elements in the preceding example:
This section's example appears complex, but it pales in comparison with stored procedures and SQL scripts that are used in production databases. For an example of a truly complex script, make a copy of ...\Office10\Samples\NorthwindCS.sql as NorthwindCS.txt, and then open it in Notepad. Go to the end of the file, and then Page Up to view the INSERT statements that Microsoft generated to populate the Suppliers and Products tables. Note Use the NorthwindCS.txt copy to prevent making inadvertent changes to NorthwindCS.sql. Much of NorthwindCS.txt's 670KB is devoted to binary data for the bitmaps stored in the OLE Object field of the Categories table. Access 2000's NorthwindCS.sql was even larger (1.4MB), because it included data for the larger bitmaps of the Employees table's Photo field. |