The physical storage of your device determines whether or not the database is saved as a file, and what naming conventions you must follow when identifying your database with one of the supported connection parameters (that is, DBF, CE_FILE, NT_FILE, PALM_FILE, or SYMBIAN_FILE).
The DBF parameter is most appropriate when targeting a single deployment platform or when using UltraLite desktop administration tools. For example, utility usage examples in this book will most often use the DBF parameter:
ulload -c DBF=sample.udb sample.xml
Windows CE Tip
You can use the UltraLite administration tools to administer databases already deployed to an attached device. See Windows CE.
Otherwise, if you are writing a cross-platform application, you should use the platform-specific (CE_FILE, NT_FILE, PALM_FILE, or SYMBIAN_FILE) file parameters to construct a universal connection string. For example, if you are developing an AppForge component for Windows CE and Palm OS, your connection string might look as follows:
Connection = DatabaseMgr.OpenConnection("UID=JDoe;PWD=ULdb; CE_FILE=\database\MyCEDB.udb;PALM_FILE=MyPalmDB")
Windows desktops do not have much in the way of file name restrictions. Desktops allow either absolute or relative paths.
Windows CE devices require that all paths be absolute.
You can administer a Windows CE database on either the desktop or on the attached device. To administer a database on a Windows CE device, ensure you prefix the absolute path with wce:\. For example, using the unload utility:
ulunload -c DBF=wce:\UltraLite\myULdb.udb c:\out\ce.xml
In this example, UltraLite unloads the database from the CE device to the ce.xml file in the Windows desktop folder of c:\out.
Windows CE and backups
It should be noted that if you are using the Unload Database and Upgrade Database wizards to administer a database on the attached CE device, UltraLite cannot back up the database before the unload or action occurs. You must perform this action manually before running these wizards.
Palm OS does not necessarily use the concept of file paths. Therefore, how you define it depends on the store type (that is, record-based, or VFS).
File-based stores (VFS) For databases on a VFS volume, define the file with the following syntax:
vfs: [ volume-label: | volume-ordinal: ] filename
You can set the volume-label as INTERNAL for the built-in drive, or CARD for either an expansion card or the label name of the volume. There is no default string for the volume-label.
Alternatively, you can set the volume-ordinal to identify the volume. Since the enumeration of mounted volumes can vary, ensure you set the correct ordinal volume for your chosen internal or external volume. The default value is 0 (which is the first volume enumerated by the platform).
For the filename, always specify the absolute file path, following the file and path naming convention of Palm OS. If directories specified in the path do not already exist, they are created.
Record-based data stores For record-based data stores, database names must follow all conventions for Palm OS database names (for example, database names cannot exceed the 32 character limit and cannot contain a path).
Also ensure you use the appropriate value for DBF or PALM_FILE according to the database's location.
Use the .PDB extension with DBF when you store a Palm OS database anywhere other than on the device itself (for example, with ulload).
Once you move the file to the device, the .PDB extension is dropped by the HotSync conduit. For example, if the database you created on the desktop is named CustDB.pdb, then when you deploy it to the device, the filename changes to CustDB.
On Symbian, paths must be absolute. Otherwise, Symbian OS assumes the file is in the device's root directory.
The database is stored in the file system, similar to that used by Windows desktop and Windows CE devices. For example Symbian phones may use the C:\ drive for phone memory, and perhaps the D:\ or E:\ drive for flash cards. Phone RAM may use the Z:\ drive. Letter designations can vary among the models used.