SAS/ACCESS 9.2 for Relational Databases: Reference, Fourth Edition

Optimizing Your SQL Usage 4 When Passing Joins to the DBMS Will Fail 45Passing the DELETE Statement to Empty a TableWhen you use the SAS/ACCESS LIBNAME statement with the DIRECT_EXE optionset to DELETE, the SAS SQL DELETE statement gets passed to the DBMS forexecution as long as it contains no WHERE clause. The DBMS deletes all rows but doesnot delete the table itself.This example shows how a DELETE statement is passed to Oracle to empty the EMPtable.libname myoralib oracle user=testuser password=testpass direct_exe=delete;proc sql;delete from myoralib.emp;quit;Oracle then executes this code:delete from empWhen Passing Joins to the DBMS Will FailBy default, SAS/ACCESS tries to pass certain types of SQL statements directly tothe DBMS for processing. Most notable are SQL join statements that would otherwisebe processed as individual queries to each data source that belonged to the join. In thatinstance, the join would then be performed internally by PROC SQL. Passing the join tothe DBMS for direct processing can result in significant performance gains.However, there are several reasons why a join statement under PROC SQL mightnot be passed to the DBMS for processing. In general, the success of the join dependsupon the nature of the SQL that was coded and the DBMS’s acceptance of thegenerated syntax. It is also greatly influenced by the use of option settings. Thefollowing are the primary reasons why join statements might fail to be passed:3 The generated SQL syntax is not accepted by the DBMS.PROC SQL attempts to pass the SQL join query directly to the DBMS forprocessing. The DBMS can reject the syntax for any number of reasons. In thisevent, PROC SQL attempts to open both tables individually and perform the joininternally.3 The SQL query involves multiple librefs that do not share connectioncharacteristics.If the librefs are specified using different servers, user IDs, or any otherconnection options, PROC SQL does not attempt to pass the statement to theDBMS for direct processing.3 The use of data set options in the query.The specification of any data set option on a table that is referenced in the SQLquery prohibits the statement from successfully passing to the DBMS for directprocessing.3 The use of certain LIBNAME options.The specification of LIBNAME options that request member level controls, suchas table locks (“READ_LOCK_TYPE= LIBNAME Option” on page 176 or“UPDATE_LOCK_TYPE= LIBNAME Option” on page 196), prohibits thestatement from successfully passing to the DBMS for direct processing.3 The “DIRECT_SQL= LIBNAME Option” on page 143 option setting.