SAS/SHARE User's Guide

SAS Data View Programming Considerations

This section describes SAS data views and how they are affected by the use of SAS/SHARE software. It contains a discussion of these topics:

Defining SAS data views
Interpreting SAS data views
Deciding where to interpret SAS data views.

Defining SAS Data Views

Beginning with Version 6 of SAS software, a SAS data set can be of member type DATA (SAS data file) or type VIEW. A data set of type VIEW is called a SAS data view. It contains a definition or description of data that is stored elsewhere. Views can be created using the DATA step, the SQL procedure, or the ACCESS procedure, which is available through SAS/ACCESS software. In most SAS programs, whether the data comes from a SAS data view or a data file is unimportant.

Many SAS/ACCESS interface products, such as DB2 or ORACLE, enable you to update product data through a SAS/ACCESS view. However, for views that are interpreted in the server's session, whether you can update a view's underlying DBMS data depends on the particular SAS/ACCESS interface engine that you are using. For information about how to use SAS/ACCESS engines in a SAS/SHARE server session, see the SAS/ACCESS documentation.

Interpreting SAS Data Views

A SAS data view that is accessed through a server can be interpreted in either the server or client session. For complete information about view interpretation, see Deciding Where to Interpret SAS Data Views.

The client specifies where a SAS data view is interpreted by using the RMTVIEW= option to the LIBNAME statement. When the RMTVIEW= option is set to YES or the option is omitted, a data view is interpreted in the server session. When the option is set to NO, a data view is interpreted in the client session. For more information about the LIBNAME statement and its options, see The LIBNAME Statement.

Interpreting a view consists of loading and calling the view engine to read the view's underlying data and present them as a SAS data set. When a view is interpreted in the client SAS session, the view engine is loaded and called by the client SAS session to read and present the underlying data. When a view is interpreted in the server session, the view engine is loaded and called by the server to read and present the underlying data.

Wherever a SAS data view is interpreted, the underlying data must be accessible to its view engine. The definition of accessible varies according to the type of view:

PROC SQL
DATA step
SAS/ACCESS.

For PROC SQL views, accessible means that all librefs that are used in the view must be pre-defined in the SAS session in which the view is interpreted or included in the USING clause of the query that is stored in the view. Such a libref can be associated with a SAS data library that is accessed through a server, or it can be associated with a data library that is accessed locally. You do not have to specify a libref in a PROC SQL view for data sets in the same data library as the view itself.

For DATA step views, accessible means that any external file (or files) must be available and that any filerefs and librefs that are stored in the view must be defined in the SAS session in which the view is interpreted.

For PROC ACCESS views, accessible means that the interface product and its data, as well as the SAS/ACCESS interface view engine, must be available to the SAS session in which the view is interpreted.

Deciding Where to Interpret SAS Data Views

Deciding where SAS data views should be interpreted in a shared environment depends on the kind of view, on how you plan to use the view's data, and on certain site considerations.

The first consideration is whether the view's underlying data is accessible. If the data is accessible only from one of the sessions, the view must be interpreted there.

If the data is accessible from both the client session and the server session, performance is the next factor to consider. If interpreting the view requires the SAS session to read a large number of rows in order to select a small subset, having the SAS/SHARE server interpret the view greatly reduces the number of records that are transmitted to the client session. This method reduces network load and may be faster than having the client session interpret the view. However, this might put an undesirable processing load on the server (particularly if joins are involved) and adversely affect server performance for other clients. If the view selects most of the input rows or if the selection criteria are processed by a DBMS server, interpreting the view in the client session is probably preferred.

Chapter Contents
Previous
Next
Top of Page