solidDB Help : Programming : Using HotStandby with applications : Transparent Connectivity : Defining the Transparent Connectivity connection : Transparent Connectivity with ODBC
  
Transparent Connectivity with ODBC
When using solidDB Transparent Connectivity (TC), the client enacts only one logical connection called the TC connection. With ODBC applications, the TC connection can be specified in the following ways:
SQLConnect function:
rc = SQLConnect(comHandle, "solidDB_TC_Info", ...
Client-side solid.ini file:
[Com]
Connect = solidDB_TC_Info
where:
solidDB_TC_Info::= {[failure_transparency_level_attribute] [preferred_access_attribute] connect_target_list} | cluster_info
failure_transparency_level_attribute::= TF_LEVEL={NONE | CONNECTION | SESSION}
preferred_access_attribute::= PREFERRED_ACCESS={WRITE_MOSTLY | READ_MOSTLY | LOCAL_READ}
connect_target_list::= [SERVERS=]connect_string[, connect_string...]
cluster_info::= CLUSTER= connect_string[, connect_string...]
For example:
TF=SESSION SERVERS=tcp 2315 tcp 1315
The following abbreviations can be used.
 
Abbreviation
Corresponding syntax
TF
TF_LEVEL
CO
CONNECTION
SES
SESSION
PA
PREFERRED_ACCESS
RM
READ_MOSTLY
WM
WRITE_MOSTLY
LR
LOCAL_READ
S
SERVERS
failure_transparency_level_attribute (failover)
Failure transparency handles the masking of failures. The failure transparency level is set with the TF_LEVEL attribute in the TC connection string. The following levels are available:
NONE – failure transparency is disabled (default).
CONNECTION – the server connection is preserved.
SESSION – certain session attributes that have non-default values are preserved.
If TF_LEVEL is not specified (or TF_LEVEL=NONE), the connection behavior falls back to Basic Connectivity.
For more information about the levels, see Failure transparency in Transparent Connectivity.
preferred_access_attribute (load balancing)
The preferred access attribute (PREFERRED_ACCESS) indicates whether the load balancing of read-only loads is applied or not. The following levels are available:
WRITE_MOSTLY – the read workload is directed to the primary server (default). All transactions are executed on the primary server.
READ_MOSTLY – the read workload is shared between the primary and secondary servers as defined by the Cluster.ReadMostlyLoadPercentAtPrimary parameter, see Cluster section. The write transactions are directed to the primary server..
LOCAL_READ – load balancing by executing read-only transactions locally when possible. Read-only transactions are always directed to the local server, be it the primary or secondary server. If the local server cannot be found, the assigned workload connection for the primary server is used (first network-based connection that is defined in the connect string). Write transactions are always executed on the primary server.
Note When using SMA with TC, if you set the load balancing method to READ_MOSTLY or WRITE_MOSTLY, a network connection is used instead of the SMA connection. Thus, when using SMA with TC, always set the load balancing method to LOCAL_READ.
If the PREFERRED_ACCESS attribute is not specified, the connection behavior falls back to Basic Connectivity.
For more information about the levels, see Load balancing in Transparent Connectivity.
connect_target_list: (server addresses)
The connect target list includes a list of server addresses. If the HSB configuration includes SMA, a SMA-specific connect target list must be used.
The driver scans the list from left to right and try to find the primary and secondary servers. Therefore, the preferred configuration should be put at the beginning of the list. The rest of the list can contain some spare addresses that might be activated at some point during the system lifetime. Keep the list short; in error situations, it can take a long time before the error is returned to the application. The addresses are tried one by one, adhering to the login timeouts that are specified (network-based connections). The number of addresses in the list is unlimited.
Note If your setup uses multi-home servers to deploy different networks for the connections between the application and the servers and the servers themselves, see Configuring server addresses with multi-home servers.
The syntax of the connect target list for network-based applications is:
[SERVERS:] network_connect_string, network_connect_string
The syntax of the connect target list for SMA applications is:
[SERVERS:] sma_connect_string, network_connect_string
network_connect_string
A connect string for network-based connections has the following format:
protocol_name [options] [host_computer_name] server_name
where options can be any combination of the following options:
 
Option
Description
Protocol
-4
Specifies that client connects using IPv4 protocol only.
TCP/IP
-6
Specifies that client connects using IPv6 protocol only.
In Windows environments, this option is mandatory if IPv6 protocol is used.
TCP/IP
-isource_address
Specifies an explicit connecting socket source address for cases where the system default source IP address binding does not meet application needs.
source_address can be an IP address or a host name.
TCP/IP
-z
Enables data compression for the connection
Important  
Data compression is not available for HotStandby connections (HotStandby.Connect) and NetBackup connections (ADMIN COMMAND 'netbackup').
Data compression for netcopy connections cannot be enabled with the -z option. Instead, use the HotStandby.NetcopyRpcCompress=yes parameter setting.
All
-c milliseconds
Specifies the login timeout (the default is operating-system-specific). A login request fails after the specified time has elapsed.
TCP/IP
-r milliseconds
Specifies the connection (or read) timeout. A network request fails when no response is received during the time specified. The value 0 (default) sets the timeout to infinite (operating system default timeout applies).
TCP/IP
-ofilename
Turns on the network trace facility and defines the name of the trace output file See Network trace facility for details.
All
-plevel
Pings the server at the given level (0-5).
Clients can always use the solidDB Ping facility at level 1 (0 is no operation/default). Levels 2, 3, 4 or 5 can be used only if the server is set to use the Ping facility at least at the same level.
See Ping facility for details.
All
-t
Turns on the network trace facility
See Network trace facility for details.
All
host_computer_name is needed with TCP/IP and Named Pipes protocols, if the client and server are running on different machines.
server_name depends on the communication protocol:
In TCP/IP protocol, server_name is a service port number, such as 2315.
In other protocols, server_name is a name, such as solidDB or chicago_office.
For details on the syntax in different communication protocols, see Communication protocols.
Notes
The protocol_name and the server_name must match the ones that the server is using in its network listening name.
If given at the connection time, the connect string must be enclosed in double quotation marks.
All components of the connect string are case insensitive.
sma_connect_string
A connect string for SMA-based connections has the following format:
sma protocol_name port_number | pipe_name
When SMA is used, applications on each computer must be able to connect to the local server with a SMA connection and to the remote server with a network-based connection. This means that the list of server addresses takes the following format:
connect_target_list::= [SERVERS=]sma_connect_string, network_connect_string
cluster_info::= CLUSTER sma_connect_string, network_connect_string
For example:
sma tcp 2315, tcp 192.168.255.1 1315
cluster_info
The CLUSTER keyword sets TF_LEVEL to SESSION and PREFERRED_ACCESS to READ_MOSTLY automatically.
For example, the following TC connection string and the CLUSTER string are interchangeable:
TF_LEVEL=SESSION PREFERRED_ACCESS=READ_MOSTLY SERVERS=tcp srv1.acme.com 1315, tcp srv2.acme.com 1315
CLUSTER=tcp srv1.acme.com 1315, tcp srv2.acme.com 1315
Note The cluster configuration can also be defined in the [Data Sources] section of the client-side solid.ini file, in which case the connect string in SQLConnect can use the logical name. For example:
rc = SQLConnect(comHandle, "Cluster1", ...
[Data Sources]
Cluster1=
  TF_LEVEL=SESSIONPREFERRED_ACCESS=READ_MOSTLY
  SERVERS=
    tcp -c 1000 srv1.dom.acme.com 1315,
    tcp srv2.dom.acme.com     1315,
    tcp srv3.dom.acme.com 1316
SQLConnect examples
rc = SQLConnect(comHandle, "TF=CONNECTION
      PA=READ_MOSTLY
      SERVERS=
      tcp -c 1000 srv1.dom.acme.com 1315,
      tcp srv2.dom.acme.com 1315,
      tcp srv3.dom.acme.com 1316", ...
rc = SQLConnect(comHandle, "CLUSTER=
      tcp -c 1000 srv1.dom.acme.com 1315,
      tcp srv2.dom.acme.com 1315,
      tcp srv3.dom.acme.com 1316", ...
SMA setup: SQLConnect on the application on Computer1 (srv1.dom.acme.com)
rc = SQLConnect(comHandle, "TF=CONNECTION
      PA=LOCAL_READ
      SERVERS=
      sma tcp 1315,
      tcp srv2.dom.acme.com 2315", ...
SMA setup: SQLConnect on the application on Computer2 (srv2.dom.acme.com)
rc = SQLConnect(comHandle, "TF=CONNECTION
      PA=LOCAL_READ
      SERVERS=
      sma tcp 2315,
      tcp srv1.dom.acme.com 1315", ...
Client-side solid.ini examples
For layout reasons, the Com.Connect parameter values in the following examples are split on several lines. In your solid.ini file, the entire parameter entry must be on one line.
[Com]
Connect = TF=CONNECTION
      PA=READ_MOSTLY
      SERVERS=
         tcp -c 1000 srv1.dom.acme.com 1315,
         tcp srv2.dom.acme.com 1315,
         tcp srv3.dom.acme.com 1316
SMA setup: solid.ini file on Computer1 (srv1.dom.acme.com)
[Com]
Connect = TF=CONNECTION
      PA=LOCAL_READ
      SERVERS=
         sma tcp 1315,
         tcp srv2.dom.acme.com 2315
SMA setup: solid.ini file on Computer2 (srv2.dom.acme.com)
[Com]
Connect = TF=CONNECTION
      PA=LOCAL_READ
      SERVERS=
         sma tcp 2315,
         tcp srv1.dom.acme.com 1315
Go up to
Defining the Transparent Connectivity connection