The IliTable class also provides a set of member functions dedicated to managing two-tier tables. A two-tier table is tied to rows that are managed by some external process or system; therefore serving as a bridge between Data Access and this external system. For instance, the IliSQLTable class (described in Hints and Tips for Using Data Access) serves as a bridge to relational database systems. The DirectoryTable sample class serves as a bridge to the file system. See Subclassing Example.

A two-tier table is usually defined by specifying some sort of criteria that will be used to identify a result set extracted from the remote or external system. Precisely how this is done depends on the subclass of IliTable being used. For an IliSQLTable, for example, an SQL SELECT statement has to be specified.

The IliTable::select member function retrieves the data from the external system identified by the above mentioned criteria. This data is then copied into a local row cache managed by the table object.

With a two-tier table, the basic row management member functions (described in section Managing Rows in a Table) perform specific actions, the details of which depend on the specific subclass being used. For more information, refer to the appropriate class in the Rogue Wave Views Data Access Reference Manual.

A two-tier table can retrieve rows in one of the following ways:

The getRowsCount member function returns the number of rows that are located in the local row cache. However, when a two-tier table implements the delayed row retrieval, the value returned by getRowsCount corresponds to the number of rows that have been retrieved to date. It does not take into account those rows that have not been retrieved yet.

The IliTable::fetchCompleted member function returns true when all rows have been retrieved and stored in the local row cache. This member function can therefore be used to check that the row count (as returned by getRowsCount) is definitive.

The IliTable::fetchNext and IliTable::fetchAll functions are used to retrieve explicitly a fixed number of rows or all remaining rows from the result set. However, when any of the insertRow, updateRow, deleteRow, and getValue member functions are called and given a row number outside of the rows in the local row cache, all missing rows up to this row are retrieved. In this way, the delayed retrieval feature is transparent except for the rows count.

The insertRowInCache, updateRowInCache, and deleteRowInCache member functions are similar to their non-inCache counterparts except that they simply act on the local row cache, leaving the remote data store unaffected.

The IliTable::clearRows clears the row cache. For two-tier tables, the external system to which the IliTable object is tied is not affected by the clearRows member function. A subsequent select would retrieve the same rows again.

In a one-tier table, however, the IliTable::clearRows effectively deletes all rows in the IliTable object.