Now that we have seen how to use SourcePro DB, let's see what makes it work. A unique feature of SourcePro DB is how it deals with diverse data types. One of the traditional obstacles to writing portable database applications is the diverse representation of data by database manufacturers. Certainly each vendor provides something that behaves like an integer, something that behaves like a floating point number, and so on. But significant differences exist, based on these issues:

• How are structured data types like string, date, time, or money represented? Typically, a database vendor provides a representation for each data type that can be stored in its database, and a collection of routines to manipulate that representation. Different vendors supply different representations.

• How are NULL values represented? Relational databases support the notion of missing or unknown values called NULLs, but this concept is not directly supported in languages like C or C++. Database APIs can represent the nullness of a value outside of the value itself with a null indicator variable, or they can indicate a null value with a NULL pointer. Different techniques lead to different implementations at the application level.

• How is data delivered to an application program? In general, either the application supplies a pointer to an area of memory to be populated by the database API, or the database API provides a pointer to volatile memory from which the application can copy data. The technique chosen tends to permeate the application design.

• How does an application program put data into the database? It may be necessary to supply a pointer to program memory, or to copy data into a buffer supplied by the database API. Perhaps data is automatically converted to the native database types, perhaps not.

In each of these cases, the mechanism chosen to represent or to deliver data has a substantial effect on the nature of your application. Your design problems are compounded if you use multiple databases.