DECLARE-CONNECTION

Syntax

In the SETUP section:

DECLARE-CONNECTION connection_name_txt_lit DSN={uq_txt_lit} [USER={uq_txt_lit}] [PASSWORD={uq_txt_lit}] [PARAMETERS=keyword_str=attr_str;[,keyword_str=attr_str ;...]] END-DECLARE 

In the body of the report:

DECLARE-CONNECTION connection_name DSN={uq_txt_lit|_var} [USER={uq_txt_lit|_var}] [PASSWORD={uq_txt_lit|_var}] [PARAMETERS=keyword_str=attr_str;[, keyword_str=attr_str;...]] END-DECLARE 

Description

Defines the datasource logon parameters prior to logon. Can be used to override the default connection logon parameters.

Parameters

Parameter	Description
connection_name	A user-defined name for describing a datasource connection.
USER, PASSWORD	Traditional logon semantics.
PARAMETERS = keyword_str=attr_str;	Defines a list of keyword-attribute pairs required by a datasource driver for logon. No syntax restriction exists for these entries apart from the delimiting semicolons (;) and equal signs (=). The keywords must match the logon property names listed for a datasource.
NO-DUPLICATE= TRUE|FALSE (default is FALSE)	This optional keyword prevents SQR from automatically creating additional logins to datasources that are busy handling a previous query. Creating a new login in such cases is the default behavior for SQR, which allows a single CONNECTION declaration to be used in a subquery. The behavior, while allowing dynamic logins as needed, causes problems when you are doing both DDL (BEGIN-SQL) and DML (BEGIN-SELECT) against temporary tables in certain vendors' datasources. In such cases, you must fetch from the temporary table using the same login in which it was created. Here, you should code the CONNECTION as NO-DUPLICATE=TRUE, and then use that connection in both the table creation logic of BEGIN-SQL and the row fetching logic of BEGIN-SELECT.

Example

The following example illustrates the DECLARE-CONNECTION command:

declare-connection SAPR3-1
   dsn=SAPR3
   username=guest
   password=guest
end-declare