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

796 Temporary Table Support for Teradata 4 Chapter 28clause. In contrast, FastExport is optimal because only one SQL statement istransmitted to the Teradata DBMS. However, older editions of the Teradata DBMSplace severe restrictions on the system-wide number of simultaneous FastExportoperations that are allowed. Even with newer versions of Teradata, your databaseadministrator might be concerned about large numbers of FastExport operations.Threaded reads with partitioning WHERE clauses also place higher workload onTeradata and might not be appropriate on a widespread basis. Both technologiesexpedite throughput between SAS and the Teradata DBMS, but should be usedjudiciously. For this reason, only SAS threaded applications are eligible for threadedread by default. To enable more threaded reads or to turn them off entirely, use theDBSLICEPARM= option.Even when FastExport is available, you can force SAS/ACCESS to Teradata togenerate partitioning WHERE clauses on your behalf. This is accomplished with theDBI argument to the DBSLICEPARM= option (DBSLICEPARM=DBI). This feature isavailable primarily to enable comparisons of these techniques. In general, you shoulduse FastExport if it is available.The explicit SQL feature of PROC SQL supports FastExport. Partitioning of WHEREclauses is not supported for explicit SQL.Temporary Table Support for TeradataOverviewFor general information about this feature, see “Temporary Table Support for SAS/ACCESS” on page 38.Establishing a Temporary TableWhen you specify CONNECTION=GLOBAL, you can reference a temporary tablethroughout a SAS session, in both DATA steps and procedures. Due to a Teradatalimitation, FastLoad and FastExport do not support use of temporary tables at this time.Teradata supports two types of temporary tables, global and volatile. With the use ofglobal temporary tables, the rows are deleted after the connection is closed but the tabledefinition itself remains. With volatile temporary tables, the table (and all rows) aredropped when the connection is closed.When accessing a volatile table with a LIBNAME statement, it is recommended thatyou do not use these options:3 DATABASE= (as a LIBNAME option)3 SCHEMA= (as a data set or LIBNAME option)If you use either DATABASE= or SCHEMA=, you must specify DBMSTEMP=YES inthe LIBNAME statement to denote that all tables accessed through it and all tablesthat it creates are volatile tables.DBMSTEMP= also causes all table names to be not fully qualified for eitherSCHEMA= or DATABASE=. In this case, you should use the LIBNAME statement onlyto access tables—either permanent or volatile—within your default database or schema.