Palm Programming: The Developer's Guide

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 orders (one record for each order), and the third 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). 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 {
   SDWord customerID;
   char  name[1]; // actually 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 {
   SDWord      customerID;
   const char *name;
   const char *address;
   const char *city;
   const char *phone;
} Customer;

Here’s a routine that takes a locked PackedCustomer and fills out a customer—it unpacks the customer. Note that each field points into the PackedCustomer (to avoid allocating additional memory). The customer is valid only while the PackedCustomer remains locked ...