|
Titulo:
CONDUIT DELPHI + HB++
|
Acessos:
0
|
Enviado:
25/3/2008
Atualizado:25/3/2008
|
Linguagem: HB++ |
Summary
This articles describes the way the different fields of a table are packed into database records. This information may prove useful if you need to access an HB++ created database with external tools, as well as on the device device side using Palm OS API functions, or on the desktop computer side when dealing with pdb files.
Note that this article only describes the internal of a database record, not the whole database or pdb file format. These are not specific to HB++, and can be found in many third party documentations, such as those available at PalmSource, Inc.
More information
Each record of a Recordset object is stored into a single Palm OS database record: there is a one to one correspondence between the HB++ and the Palm OS notion of a record. This limits the size of a record to slighty less than 64 kb and the total number of record in a recordset to 65534, but greatly simplifies interfacing HB++ with external tools.
In a record, fields are not stored in the order they were declared when creating the table in the IDE. For performance reasons, HB++ reorders the different fields according to their data type. The following table lists the different type of fields in the order they are stored:
* Byte
* Boolean
* Integer
* Long
* Single
* Double
* Date
* String
* Bitmap
* StreamMemory
If two fields share the same type, they are sorted accordingly to their name, ascending, case insensitive. For alignement reason, a null padding byte may be added between the last Boolean field and the first Integer field, so that it starts at an even address in memory. You will notice that this order ensures that all fixed size fields are stored first, at a fixed offset from the beginning of the record, allowing them to be very quickly accessed.
The predefined fields (UniqueID, Dirty, Secret and Category) are not stored in the record itseld, but in the record header which is located in the database header.
As an example, the following shows a table as it is defined in the IDE, and the way its fields are stored:
Field Name Field Type
-------------------------
UniqueID Long
Category Integer
Dirty Boolean
Secret Boolean
FirstName String
LastName String
Gender Byte
Birthday Date
Weight Single
Height Single
Signature Bitmap
VoiceSample StreamMemory
Offset Size Field Name
------------------------
0 1 Gender
1 1 [null padding byte]
2 4 Birthday
6 4 Height
10 4 Weight
14 ? FirstName
? ? LastName
? ? Signature
? ? VoiceSample
The following describes the format of each field type, and notably the format of the variable length fields.
Byte, Integer, Long
These values are stored as 1, 2 or 4 bytes binary integers. You can refer to the "Data Format" section in the online documentation for more information.
Boolean
These values are stored as 1 byte integers, 0 corresponding to False, and 255 corresponding to True. Any other value is illegal and can lead to unpredictable results.
Date
These values are stored as unsigned 4 bytes integers, representing the number of seconds elapsed since the 1/1/1904 at midnight. You can refer to the "Data Format" section in the online documentation for more information.
Single, Double
These values are stored as 4 or 8 bytes floating point values, according to the IEEE-754 specification. You can refer to the "Data Format" section in the online documentation for more information.
String
The strings are stored "as is", their end being signaled by a null character. The first string is always stored at a fixed offset, just after all the fixed size fields. If your table contains multiple strings, you can find the beginning of the next field by browsing the record until you encounter a null byte.
Bitmap
Bitmap fields always start at an even offset from the beginning of the record. Then if the previous field (usually a string) ends at an odd address, a null padding byte is first encountered. Then the following values are found:
Offset Size Description
-------------------------
0 2 The 'bm' value
2 2 Width of the image
4 2 Height of the image
6 2 Number of bytes per line
8 1 Number of bit per pixel (1, 2, 4, 8 or 16)
9 1 Header version
10 2 Density (72, 108, 144, 216 or 288)
12 4 Transparency color
16 ? Actual bitmap data
The image itself is stored immediately after the header, line by line, from left to right and top to bottom. The start of a line is always aligned on an even address, each line being completed if necessary by a null byte.
To know the offset of the next field in the record, simply add to the current offset the size of this header (16 bytes) and the size of the bitmap which depends on the size, depth, and density of the image.
StreamMemory
StreamMemory fields always start at an even offset from the beginning of the record. Then if the previous field (usually a string or a bitmap) ends at an odd address, a null padding byte is first encountered. Then the following values are found:
Offset Size Description
-------------------------
0 2 The 'sm' value
2 4 Number of bytes in the StreamMemory (possibly zero)
6 ? Actual StreamMemory data
To know the offset of the next field in the record, simply add to the current offset the size of this header (6 bytes) and the number of bytes in the StreamMemory.
Note: you will notice that the HB++ table format is not self-documented. It is therefore not possible to extract data from a Palm OS database without knowledge of the field definition of the table it contains.
|
|
|
|
|
|
Referências/References/Referencias |
Conduit, HB++,
|
|
|
|
|
|
|
|
|
|
Envie dicas você também, para isso basta envier um e-mail para
softpalm@softpalm.com.br |
|
|
|
|
|
|
|
|
|
contador
|