Migrating from CommDb to the CommsDat API

This section highlights some of the issues in the migration from the CommDb to the CommsDat API.

The CommsDat API replaces CommDb. Users of CommDb do not need to make changes to their code. Symbian platform provides a shim that translates the calls to the CommDb API to calls to the CommsDat API.

The CommDb API will be withdrawn in the future. Developers are recommended to migrate to the CommsDat API.

Removal of the CommDb SQL API

The Commdb SQL API is removed.

The CommDb API allows tools and applications to select views of database tables that match field values. The CommDb API also allows tools and applications to create new user defined tables in the database at run time.

The CommsDat keeps this behaviour. Tools and applications can select sets of records by pattern matching fields in a primed table, record or field object with records in the database. Tools and applications can also use the CommsDat API to define and store user defined records.

Referring to database elements by Id instead of by Name

The Commdb API has an interface based on column names. This method is not efficient.

The CommsDat API allows tools and applications to find elements in the database by numeric id and to provide direct access through mapped data objects. You can continue to find elements in the Comms Database by name. The Nifman API continues to use this method. This method is not recommended, because it is very inefficient.

Retrieving small amounts of data

Tools and applications do not need to simulate the use of a whole view when they use the CMDBRecordSet <T> class. Tools and applications can use CMDBRecordSet <T> objects for data retrieval.

Use record tags instead of record names in user defined fields

Many CommDb searches are for records by user defined record name. This type of search is not efficient.

The use of numeric Ids improves the performance of searches. User defined records can define a record tag field. Tools and applications give this field the unique numeric Id KCDTIdRecordTag. Current procedure fills this field with the record Id of the record. This procedure provides backward compatibility with CommdbId. The field value can be any numeric record tag. For example, a UID value gives a convenient way to link records .

See Creating a User Defined Table: Tutorial