Introduction to Table Editor

 Interaction Administrator and Interaction Designer (through the Table Lookup tool) both provide access to a table editor that allows you to create simple, indexed, in-memory databases for fast lookups during CIC interaction processing. The tables are stored on the CIC server and reside in Virtual Memory (VM) while CIC is running. These tables are read-only in the current release.

The Table Editor portrays the table as a set of rows and columns much like a spreadsheet or relational database. You can easily add columns and rows using the toolbar buttons or menu commands. To edit a cell, double-click on it or use one of the keyboard shortcuts. All cell editing is done in place (within each cell). The editor supports multi-level undo and redo operations. When you click on the Save button, CIC re-reads the table into memory and the table values are immediately available for access.

Each column has a label and an index. The label is used to identify each column, and indexed column labels appear in the list of "Columns for Lookup" in the Table Lookup tool in Interaction Designer. Indexes define columns you search quickly for specific values. If a column does not have an index, you cannot use that column as a search key.

Each table is a stand-alone entity. Tables do not obey typical relational operations such as joins and views. Tables are stored on and referenced from the CIC server. Each table and column in that table has a globally unique identifier, a GUID, which uniquely defines each table and each column.

In order to perform a lookup on a table, at least one column in the table must have an index. Table Editor supports two kinds of indexes:

Unique - each entry in the column is unique (for example, account number) and it cannot contain duplicate values. Table Editor warns you if it finds duplicates. Lookups on unique index columns are faster than on columns with duplicate values.

Multiple - each entry in the column may have one or more occurrences of that value in the column (for example, account type, date, and so on). Lookups on multiple value indexes are slower than on columns with unique indexes.

What is the difference between an .i3Table and a .i3TableEX file?

Normally, table data is stored in 2 locations: (1) The column information is stored in the registry; and (2) the data is stored in the .i3Table file. You shouldn't care about these storage structures, they are internal and could change at any time. CIC keeps data in the registry to make lookups/browsing of the different table types quicker.

When you export a table to the .i3TableEx file, it contains the columns found in the registry (1) plus the table data (2). A complete stand-alone 'table'.

CIC stores the data in .i3Table internal format because it may be too big to fit in the registry. We envision large tables may be stored.

Note: For the best performance, tables should contain no more than 2,000 records. Also note that table lookups are case sensitive.