Visual Basic

The Windows CE database

The Windows CE database model provides storage for non-relational data. You can create any number of databases, each with a unique ID. Each database can contain any number of records (depending on memory). A database record can have any number of fields and these fields can be of type Integer, String, Date or Byte array (also known as Binary Large Objects, or BLOBs). Each database record has its own unique ID and this ID is unique across all databases. Database records can contain up to four index keys, which can be used for searching and sorting. In addition, a field can be indexed either in ascending or descending order.

The records held in a database need not be related; for example, you can store contact information in some records and product price details in another record within the same database. A number of API functions exist to manipulate databases-these are covered in more detail later in this chapter. Microsoft has recently released a beta version of ActiveX Data Objects, (ADO) which provides full connectivity to relational databases like Microsoft SQL Server and Microsoft Access. ADO makes it possible to manipulate data in a relational database using the standard SQL to which most Windows developers are accustomed.

Even though the standard database features might sound rather limited, you should remember the kind of application for which Windows CE is designed. If you think in terms of the OEM developing a household device, you'll see that the functionality is more than adequate.

File system

The Windows CE file system has a host of functions with which to access file-based data. The file functions that exist in the normal development environment are not supported by Windows CE; instead, new functions have been provided in the API. Most Windows CE devices presently use the FAT-based file systems. However, the operating system can support installable file systems. For most current Windows CE applications, file access will be to RAM rather than to a physical hard disk, although in terms of coding the difference is transparent.

The file system can be browsed and manipulated using the Mobile Devices application that is installed as part of the Windows CE Services. This application is rather like Windows Explorer and works in the same way. You can even copy, move, or paste files between Windows Explorer and mobile devices.


Windows CE, like Windows NT/9x, uses the Registry to store system and application configuration data. However, the Windows NT Registry consists of several files, or hives, that together form the entire Registry. Windows CE does not support hives-the entire Registry is stored as a single file. The Registry file is stored in ROM and is copied to RAM when the device is booted. You should bear in mind that a Windows CE device will probably boot only after the power supply has been connected. Normally, when the device is turned off, backup batteries retain RAM memory. This design allows a feature that Microsoft calls "Instant On"-that is, the device is immediately available when switched on. It is possible to write software that saves the Registry file to a non-volatile storage device. Given the nature of the power supply for many prospective Windows CE devices, however, user data can be lost in almost any situation. Losing the Registry should not cause too many problems for an application, because more than likely any user files will be lost as well. A good design principle to employ might be for an application to back up the Registry to non-volatile storage whenever the user chooses to backup his or her files.

The RAM copy of the Registry can be accessed using the Win32 API, or Visual Basic programmers can use the built-in Registry functions. Desktop applications written in Visual Basic often need to use the API in order to access different Registry keys; for example, global application data would probably need to be saved to HKEY_LOCAL_MACHINE, whereas user specific settings would be better located under HKEY_CURRENT_USER. For Visual Basic programmers, a COM DLL is required to access keys or paths other than the default one that Visual Basic accesses: HKEY_CURRENT_USER\Software\VB and VBA Program Settings.