CONNECTION= LIBNAME Statement Option

Specifies whether operations on single or multiple librefs can share a connection to the DBMS.

Valid in: SAS/ACCESS LIBNAME statement
CONNECT statement
Category: Data Access
Default: DBMS-specific
Interactions: MySQL: The GLOBAL, GLOBALREAD, SHARED, and SHAREDREAD values are recommended only with RESULTS=MEMORY. If RESULTS=SERVER, then the underlying data source supports only one cursor per connection. If RESULTS=SERVER, you might get errors with these CONNECTION= option values when you attempt to open multiple simultaneous cursors in the same connection.
For DBMSs that default to CONNECTION=UNIQUE, the LIBNAME connection can fail when you use SQL_FUNCTIONS= for that same DBMS to store the external SQL dictionary.
Data source: Amazon Redshift, Aster, DB2 under UNIX and PC Hosts, DB2 under z/OS, Greenplum, Hadoop, HAWQ, Impala, Informix, JDBC, Microsoft SQL Server, MySQL, Netezza, ODBC, OLE DB, Oracle, PostgreSQL, SAP ASE, SAP HANA, SAP IQ, Snowflake, Teradata, Vertica, Yellowbrick
Note: Support for Yellowbrick was added in SAS 9.4M7.
See: ACCESS= LIBNAME option, CONNECTION_GROUP= LIBNAME option, DBMSTEMP= LIBNAME option, DEFER= LIBNAME option
CAUTION

When you use a GLOBAL or single SHARED connection to access multiple tables, performing a commit or rollback on one table that is being updated might affect all other tables that are open for update. Even if you open a table only for READ, its READ cursor might be resynchronized due to this commit or rollback. If the cursor is resynchronized, there is no guarantee that the new solution table matches the original solution table that was being read.

Syntax

Syntax Description

GLOBAL

specifies that all operations that access DBMS tables in multiple librefs share a single connection if the conditions for sharing a connection are met. You must set CONNECTION=GLOBAL to access temporary tables. For more information, see Conditions for a Shared DBMS Connection.

Interactions One connection is shared for all tables that any libref references for which you specify CONNECTION=GLOBAL.
Most SAS/ACCESS interfaces require CONNECTION=GLOBAL in order to support access to temporary tables. See the DBMSTEMP= LIBNAME option for details about your data source.
When CONNECTION_GROUP= is specified, the default value for CONNECTION= is GLOBAL.
Tip When you specify CONNECTION=GLOBAL, any pass-through code that you include after the LIBNAME statement can share the connection. For details, see the CONNECT statement example.

GLOBALREAD

specifies that all READ operations that access DBMS tables in multiple librefs share a single connection if the conditions for sharing a connection are met. For more information, see Conditions for a Shared DBMS Connection.

A separate connection is established for each table that is opened for update or output operations.

SHARED

specifies that all operations that access DBMS tables in a single libref share a single connection if the conditions for sharing a connection are met. For more information, see Conditions for a Shared DBMS Connection.

Note The CONNECTION= option controls only connections that you use to open tables with a libref. When you specify CONNECTION=SHARED, it has no effect on utility connections or explicit pass-through connections.
Tip Use SHARED to eliminate the deadlock that can occur when you create and load a DBMS table from an existing table that exists in the same database or tablespace. This happens only in certain output processing situations and is the only recommended use for CONNECTION=SHARED.

SHAREDREAD

specifies that all READ operations that access DBMS tables in a single libref share a single connection if the conditions for sharing a connection are met. For more information, see Conditions for a Shared DBMS Connection.

A separate connection is established for every table that is opened for update or output operations.

Tip Where available, this is usually the default value because it offers the best performance and it guarantees data integrity.

UNIQUE

specifies that a separate connection is established every time a DBMS table is accessed by your SAS application.

Tip Use UNIQUE if you want each use of a table to have its own connection.

Details

Overview of the CONNECTION= LIBNAME Option

The main reason for using the CONNECTION= LIBNAME option is to control the number of physical connections to your DBMS. When you specify that you want to share DBMS connections, you enable SAS to use one physical connection across multiple DATA steps and procedure calls. In this way, you limit the number of physical connections for your SAS session. Sharing a connection also enables you to share access to temporary tables across DATA steps and procedure calls.

SAS/ACCESS interfaces that support single or multiple simultaneous connections to the DBMS support this option. Not all values are valid for all SAS/ACCESS interfaces.

For most SAS/ACCESS interfaces, there must be a connection, also known as an attach, to the DBMS server before a user can access any data. Typically, a DBMS connection has one transaction, or work unit, that is active in the connection. This transaction is affected by any SQL commits or rollbacks that the engine performs within the connection while executing the SAS application.

The CONNECTION= option lets you control the number of connections, and therefore transactions, that your SAS/ACCESS interface executes and supports for each LIBNAME statement, SQL pass-through CONNECT statement, or both.

When you connect to the DBMS server via PROC SQL, only the GLOBAL and SHARED values from a LIBNAME statement are passed down.

Default Values

DBMS-Specific Default Values

DBMS

Default

Amazon Redshift

DB2 under UNIX and PC Hosts, DB2 under z/OS

Hadoop

Impala

Informix

JDBC

MySQL

OLE DB

Oracle

PostgreSQL

SAP HANA

SAP IQ

Snowflake

Yellowbrick

SHAREDREAD

Aster

Netezza

Vertica

UNIQUE

Greenplum

HAWQ

Microsoft SQL Server

ODBC

SAP ASE

UNIQUE for a data source that supports only one active open cursor per connection; otherwise, SHAREDREAD

Teradata

UNIQUE for network attached systems (UNIX and PC platforms)

SHAREDREAD for channel-attached systems (z/OS)

Conditions for a Shared DBMS Connection

If you want to share a connection across librefs, the critical connection options that you specify must be the same. You can specify the connection options in a LIBNAME statement or in the CONNECT statement in an SQL procedure call. When SAS/ACCESS compares connection option values, it does not matter whether you use optional quotation marks across libref declarations.

Here are the conditions that must be met to share a physical connection to your DBMS:

  • These connection options must have the same value for each libref declaration:
    USER= ACCOUNT=
    PASSWORD= DATABASE=
    SERVER= SCHEMA= (except Teradata)

    Teradata does not require values for SCHEMA= to be the same across libref declarations.

  • These LIBNAME options must have the same value for each libref declaration:
    DATABASE= SQL_FUNCTIONS=
    SCHEMA= (except Teradata) READ_ISOLATION_LEVEL=
    CONNECTION= READ_LOCK_TYPE=
    CONNECTION_GROUP= READ_MODE_WAIT=
    DBCONINIT= UPDATE_ISOLATION_LEVEL=
    DBCONTERM= UPDATE_LOCK_TYPE=
    DBLIBINIT= UPDATE_MODE_WAIT=
    DBLIBTERM=

If any of these conditions are not met, SAS/ACCESS automatically creates additional physical connections to the DBMS.

Examples

Example 1: Use SHAREDREAD

In this example, MYDBLIB makes the first connection to the DBMS. This connection is used to print the data from MYDBLIB.TAB. MYDBLIB2 makes the second connection to the DBMS. A third connection is used to update MYDBLIB.TAB. The third connection is closed at the end of the PROC SQL UPDATE statement. The first and second connections are closed with the CLEAR option.

/* connection 1 */
libname mydblib oracle user=myusr1 pw=mypwd1 
   path='mysrv1' connection=sharedread;
/* connection 2 */
libname mydblib2 oracle user=myusr1
   pw=mypwd1 path='mysrv1' connection=sharedread;
proc print data=mydblib.tab…
/* connection 3 */
proc sql;
   update mydblib.tab…
libname mydblib clear;
libname mydblib2 clear;

Example 2: Use GLOBALREAD

In this example, the two librefs, MYDBLIB and MYDBLIB2, share the same connection for Read access because CONNECTION=GLOBALREAD and the connection options are identical. The first connection prints the data from MYDBLIB.TAB while a second connection updates MYDBLIB.TAB. The second connection is closed at the end of the step. The first connection is closed with the final LIBNAME statement.

/* connection 1 */
libname mydblib oracle user=mysrv1 pw=mypwd1 
   path='myorapath' connection=globalread;
libname mydblib2 oracle user=mysrv1 pw=mypwd1 
   path='myorapath' connection=globalread;
proc print data=mydblib.tab…
/* connection 2 */
proc sql;
   update mydblib.tab…
/* does not close connection 1 */
libname mydblib clear;
/* closes connection 1 */
libname mydblib2 clear;

Example 3: Use UNIQUE

In this example, the MYDBLIB libref establishes a connection to obtain database information. Another connection is established in order to print the data from MYDBLIB.TAB. That connection is closed at the end of the PRINT procedure. Another connection is established to update MYDBLIB.TAB. That connection is closed at the end of the PROC SQL. The CLEAR option in the LIBNAME statement at the end of this example then closes the connection that was made during the MYDBLIB libref assignment.

libname mydblib oracle user=myusr1 pw=mypwd1 
   path='mysrv1' connection=unique;
proc print data=mydblib.tab…
proc sql;
   update mydblib.tab…
libname mydblib clear;

Example 4: Use SHARED

In this SHARED example, DB2DATA.NEW is created in the database TEST. The DB2DATA.OLD table exists in the same database. So the CONNECTION=SHARED option lets the DB2 engine share the connection for reading the old table and also creating and loading the new table.

libname db2data db2 connection=shared;
data db2data.new (in = 'database test');
   set db2data.old;
run;

If you did not use the CONNECTION= option in this case, you would deadlock in DB2 and receive this error.

ERROR:  Error attempting to CREATE a DBMS table.
ERROR:  DB2 execute error DSNT408I SQLCODE = –911,
ERROR:  THE CURRENT UNIT OF WORK HAS BEEN ROLLED
        BACK DUE TO DEADLOCK.

Example 5: Use GLOBAL

In this example for DB2, both PROC DATASETS invocations appropriately report “no members in directory.” This happens because SESSION.B, as a temporary table, has no entry in the SYSIBM.SYSTABLES system catalog. However, the DATA _NULL_ step and SELECT * from PROC SQL step both return the expected rows. For DB2, when SCHEMA=SESSION, the database first looks for a temporary table before attempting to access any physical schema named SESSION.

libname x db2 connection=global schema=SESSION;
proc datasets lib=x;
quit;
/*
 *  DBMS-specific code to create a temporary table impervious
 *  to commits and populate the table directly in the
 *  DBMS from another table.
 */
proc sql;
connect to db2(connection=global schema=SESSION);
execute ( DECLARE GLOBAL TEMPORARY TABLE SESSION.B LIKE SASDXS.A
          ON COMMIT PRESERVE ROWS
         ) by db2;
execute ( insert into SESSION.B select * from SASDXS.A
         ) by db2;
quit;
/*  Access the temp table through the global libref. */
data _null_;
set x.b;
put _all_;
run;
/*  Access the temp table through the global connection. */
proc sql;
connect to db2 (connection=global schema=SESSION);
select * from connection to db2
( select * from SESSION.B  );
quit;
proc datasets lib=x;
quit;

In this example, two different librefs share one connection.

libname db2lib db2 connection=global;
libname db2data db2 connection=global;
data db2lib.new(in='database test');
   set db2data.old;
run;

If you did not use the CONNECTION= option in this last example, you would deadlock in DB2 and receive this error.

ERROR:  Error attempting to CREATE a DBMS table.
ERROR:  DB2 execute error DSNT408I SQLCODE = –911,
ERROR:  THE CURRENT UNIT OF WORK HAS BEEN ROLLED
        BACK DUE TO DEADLOCK.
Last updated: February 3, 2026