Show Hide

 

Feedback

  • Contents
 

DB Put Data List

This Database tool writes attribute data to an ODBC CIC Data Source as a row of data. If the database table already has this row, it will be updated; otherwise, a new row will be inserted. A new insert is executed as follows: ‘Insert into Table Name Value (Comma-Separated Attribute Names) values (Comma-Separated Attribute Values)’. An update is executed as follows: ‘Update Table Name Value, set Attribute Name1=Attribute Value1, Attribute Name2=Attribute Value2, ..... where Where Clause Value).

This tool was created for use with the Interaction Dialer application that will read and write many call attributes to and from a data source. In most cases, you can use the Set Attribute tool to set the value of a default or custom call attribute.

Inputs

IC Data Source

This must be an CIC Data Source (configured in Interaction Administrator) that refers to an ODBC DSN.

Table Name

The name of the table to which the attributes are written.

Where Clause

The row to write. For example, "Agent = 4". You should not specify more than one row. If you do specify more than one row, every matching row is updated, which is normally not desired behavior. This Where Clause is optional, and if omitted, a suitable Where Clause is generated automatically as long as your ODBC driver supports the SQLPrimaryKeys API (see note 1 below). Note that this is only optional for DB Put Data List; it is required in DB Get Data List since there is no input data to generate the clause from.

Attribute Name Prefix

The value to prepend to the attribute name before writing it to the data source. For example, if the attribute name is "Attribute1" and you specify "IntDialer_" as the prefix, "IntDialer_Attribute1" is listed in written to the data source. This parameter is optional.

Attribute Name Suffix

The value to append to the attribute name before writing it to the data source. For example, if the attribute name is "Attribute1" and you specify "_IntDialer" as the suffix, "Attribute1_IntDialer" is listed in written to the data source. This parameter is optional.

Timeout

The number of seconds to wait for this operation to complete successfully before taking the failure path. Any value less than or equal to zero results in the default value of 60 seconds being used. You may specify a decimal value, such as 5.5.

Attribute Names

A list of strings value containing the list of attribute names to be written to the data source.

Attribute Values

A list of attribute values parallel to the list of Attribute Names. If the number of values does not match the number of names, this step will take the Failure exit path.

Exit Paths

Success

If the operation is successful, this tool takes the Success exit path.

Failure

This tool takes the Failure exit path if the syntax of the Where clause in incorrect or if the CIC Data Source is configured incorrectly.

Notes

  1. To prevent updating the primary key (which is not allowed by many RDBMSs, even if the value will not change) this tool uses the ODBC API SQLPrimaryKeys. Although this API is supported by most ODBC drivers, it is a Level 2 extension API and therefore you may run into an occasional driver that doesn’t support it. If your ODBC driver doesn’t support SQLPrimaryKeys, this tool will still work, but you must manually remove the primary key attribute(s) and value(s) from the input lists when updating. When inserting, the primary key data must still be present (unless your primary key is an auto-increment type – see note 2 below).

  2. If your primary key is an auto-increment type you must exclude it from inserts, which means you can just exclude it always. Note that the SQL Server uniqueindentifier type is not included here, since it must be supplied as data (usually with the NEWID() function) during the insert.

  3. Currently, the only non-updateable data type that is recognized and automatically excluded is the SQL Server timestamp type. If your RDBMS has other types that are not updateable, you will need to manually exclude them (and please report these to Genesys so that they can be incorporated into future releases).

  4. SQLPrimaryKeys requires, as inputs, a catalog name and a schema name. Usually, but not always, the catalog will correspond to the database name; the schema name will usually, but not always, correspond to the owner/creator of the table (the "qualifier"). By default, this tool will use the qualifier entry of the CIC data source for the schema, and it will look for a DB= or a DATABASE= entry in the Additional Information entry for the catalog. However, SQLPrimaryKeys has some obscure semantics regarding NULL vs. empty ("") strings for the catalog and schema names. Basically, you would use NULL as a wildcard to mean all catalogs or all schemas. Unless the table name is unique in a catalog (or across all catalogs if NULL is used for the catalog), this is clearly a problem for this tool, since it is expected to update exactly one table. The use of empty stings is fairly rare, and an empty schema means those tables that do not have schemas, and an empty catalog means those tables that don’t have catalogs. A problem arises, however, because currently an empty/missing qualifier CIC data source entry means to use the default (e.g. "dbo"). The same applies to a missing database entry in the Additional Information field. To solve this problem, this tool will first look for an optional CATALOG= and a SCHEMA= entry in the Additional Information field that will be used to override any qualifier entry or database entry. To denote a NULL catalog or schema input, use the keyword NULL (e.g. CATALOG=NULL;); to denote an empty catalog or schema input, omit any characters (e.g. SCHEMA=;). As another example, if the catalog does not correspond to the database (or you don’t feel like adding a database entry to the Additional Information), you can specify it explicitly (e.g. CATALOG=mktg2;).