Palm OS Programming, 2nd Edition

Examining Databases in the Sales Sample

Now that you understand how databases and records function within the storage heap space, let’s look at how we use them in our Sales application.

Defining the Sales Databases

The Sales application has three different databases. The first holds customers, the second holds orders (one record for each order), and the third holds items. Here are the constant definitions for the names and types:

#define kCustomerDBType 'Cust'
#define kCustomerDBName "Customers-SLES"
#define kOrderDBType    'Ordr'
#define kOrderDBName    "Orders-SLES"
#define kProductDBType  'Prod'
#define kProductDBName  "Products-SLES"

Reading and Writing the Customer

The customer is stored as the customer ID followed by four null-terminated strings back to back (it’s “packed,” so to speak). An alternative would have been to have four strings, each with a predefined maximum length. That would leave wasted space at the end of each string—a no-no on a device for which memory space is limited. Here’s a structure we use for the customer record (there’s no way to represent the four strings, so we just specify the first one):

typedef struct {
  Int32 customerID;
  char  name[1];  // Aactually may be longer than 1.
} PackedCustomer;

When we’re working with a customer and need to access each of the fields, we use a different structure:

typedef struct {
  Int32   customerID;
  const char *name;
  const char *address;
  const char *city;
  const char *phone;
} Customer;

Example 10-23 is a routine that takes a locked ...