MobiLink Synchronization User's Guide
  The CustDB Sample Application

Introduction

This chapter introduces you to the CustDB (Customer Database) MobiLink sample application. CustDB is a sales-status application.

The CustDB sample is a valuable resource for the MobiLink developer. It provides you with examples of how to implement many of the techniques you will need to develop MobiLink applications.

The application has been designed to illustrate several common synchronization techniques. To get the most out of this chapter, you should study the sample application as you read.

A version of CustDB is supplied for each supported operating system and for each supported database type.

For the locations of CustDB and setup instructions, see Setting up the CustDB consolidated database.

Following is the schema of CustDB:

Scenario 

The CustDB scenario is as follows.

A consolidated database is located at the head office. The following data is stored in the consolidated database:

• The MobiLink system tables that hold the synchronization metadata.

• The synchronization scripts that implement synchronization logic.

• The CustDB data, including all customer, product, and order information, stored in the rows of base tables.

There are two types of remote databases, mobile managers and sales representatives.

Each mobile sales representative's database contains all products but only those orders assigned to that sales representative while a mobile manager's database contains all products and orders.

Synchronization design 

The synchronization design in the CustDB sample application uses the following features:

• Complete table downloads    All rows and columns of the ULProduct table are shared in their entirety with the remote databases.

• Column subsets    All rows, but not all columns, of the ULCustomer table are shared with the remote databases.

• Row subsets    Different remote users get different sets of rows from the ULOrder table.

  For more information about row subsets, see Partitioning rows among remote databases.

• Timestamp-based synchronization    This is a way of identifying changes that were made to the consolidated database since the last time a device synchronized. The ULCustomer and ULOrder tables are synchronized using a method based on timestamps.

  For more information, see Timestamp-based synchronization.

• Snapshot synchronization    This is a simple method of synchronization that downloads all rows in every synchronization. The ULProduct table is synchronized in this way.

  For more information, see Snapshot synchronization.

• Primary key pools to maintain unique primary keys    It is essential to ensure that primary key values are unique across a complete MobiLink installation. The primary key pool method used in this application is one way of ensuring unique primary keys.

  For more information, see Maintaining unique primary keys using key pools.

  For other ways to ensure that primary keys are unique, see Maintaining unique primary keys.