Database Id Constant
| Database Id
| Description
DBID_COMMONSEARCHHISTORY | 120
| DBID_SHELLADDIN | 150 | Addin headers - descriptions & icon
| DBID_SETUPINFO | 160
| DBID_DEVICEID | 170
| UNNAMED | 201 | Used by Graham Cobbs Dylink code - now obsolete but DB
will exist for those "early adopters" who used Grahams code.
| DBID_ADDRESS | 1000 | Contact main table
| | 1001 | Contact sync status
| | 1002 | Contact categories
| | 1003 | Contact category associations
| | 1004 | Contact meta data
| DBID_CALENDAR | 2000 | Calendar main table
| | 2001 | Calendar sync status
| | 2002 | Calendar ??
| | 2004 | Calendar meta data
| DBID_TODO | 3000 | Task main table
| | 3001 | Task sync status
| | 3004 | Task meta data
| DBID_MEMO | 4000 | Memo main table
| | 4001 | Memo sync status
| | 4002 | Memo categories
| | 4003 | Memo category associations
| | 4004 | Memo meta data
| | 4005 | Memo unknown
| DBID_MAIL | 5000 | Not used in Rex?
| DBID_DICTIONARY | 7000 | Used in DS2, not in Rex6000
| DBID_CLOCK | 8000 | World clock city table
| DBID_PICTURE | 10000 | Picture data
| | 10001 | Addin sync status
| DBID_WEB | 20000
|
|
Q: What are the fields in each database?
Table 150 : Addin shell
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the addin
| 2 | DB_INT16 | counter for number of addins?
| 3 | DB_INT16 | 1
| 4 | DB_INT16 | addin size field??
| 5 | DB_VARSTR | addin title
| 6 | DB_VARSTR | addin description
| 7 | DB_VARDAT | addin icon
| |
Table 1000 : Contact main table
|
Field no
| Field Type
| Description
1 | DB_RECID | contact DB_RECID
| 2 | DB_INT8 | Index to first two letters from Last Name
| 3 | DB_INT8 | Index to first two letters from First Name
| 4 | DB_INT8 | Index to first two letters from Company
| 5 | DB_VARSTR | last name,first name work phone work email
| 6 | DB_VARSTR | first name last name work phone work email
| 7 | DB_VARSTR | company-last name work phone work email
| 8 | DB_VARSTR | first name
| 9 | DB_VARSTR | last name
| 10 | DB_VARSTR | company
| 11 | DB_VARSTR | work country
| 12 | DB_VARSTR | work zip
| 13 | DB_VARSTR | work state
| 14 | DB_VARSTR | work city
| 15 | DB_VARSTR | work street
| 16 | DB_VARSTR | home country
| 17 | DB_VARSTR | home zip
| 18 | DB_VARSTR | home state
| 19 | DB_VARSTR | home city
| 20 | DB_VARSTR | home street
| 21 | DB_VARSTR | work phone
| 22 | DB_VARSTR | work other
| 23 | DB_VARSTR | work fax
| 24 | DB_VARSTR | home phone
| 25 | DB_VARSTR | home other
| 26 | DB_VARSTR | home fax
| 27 | DB_VARSTR | work mobile
| 28 | DB_VARSTR | home mobile
| 29 | DB_VARSTR | work email
| 30 | DB_VARSTR | home email
| 31 | DB_VARSTR | title
| 32 | DB_VARSTR | notes
| |
Table 1001 : Contact sync status
|
Field no
| Field Type
| Description
1 | DB_RECID | contact DB_RECID
| 2 | DB_INT8 | 1=addition done in Rex, 2=modified, 3=deletion
(not thoroughly checked, assumed to be similar to MEMO)
| |
Table 1002 : Contact categories
|
Field no
| Field Type
| Description
1 | DB_RECID | category DB_RECID
| 2 | DB_VARSTR | category name
| 3 | DB_INT32 | number of contacts in category
| |
Comment: If you have contact which belongs to more than one category,
then you have multiple entries with the same number in field 1, field 2
contains 0,1 and count up with any new category to witch contact belongs,
field 3 have category id.
Table 1003 : Contact Category Associations table
|
Field no
| Field Type
| Description
1 | DB_RECID | contact DB_RECID
| 2 | DB_INT8 | Order number?
| 3 | DB_INT32 | category DB_RECID
| 4 | DB_VARSTR | first name
| 5 | DB_VARSTR | last name
| 6 | DB_VARSTR | company
| |
Each connected contact-category combination is one record in this database
i.e. you have multiple records for one contact if it is in multiple categories
Table 2000 : Calendar main table
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the event
| 2 | DB_INT32 | replicates recid?
| 3 | DB_INT8 | repeat type (6=annual)
| 4 | DB_INT8 | 1
| 5 | DB_INT16 | 1
| 6 | DB_INT16 | 1
| 7 | DB_INT8 | day of repeated events
| 8 | DB_INT8 | month of repeated events
| 9 | DB_INT8 | 0
| 10 | DB_INT8 | 0
| 11 | DB_INT32 | Start Date
| 12 | DB_INT32 | Date of the day before the first date not repeated
| 13 | DB_INT8 | 8 or 127?
| 14 | DB_INT8 | 1 or 2?
| 15 | DB_INT32 | Date&time?
| 16 | DB_INT8 | Alarm before in minutes
| 17 | DB_INT8 | Alarm 0=no, 1=yes
| 18 | DB_INT16 | Start time
| 19 | DB_INT16 | End time
| 20 | DB_INT8 | 4 or 2 (2=all day)?
| 21 | DB_VARDAT | ?
| 22 | DB_VARSTR | Title
| 23 | DB_VARSTR | Place
| 24 | DB_VARSTR | Note
| |
Table 3000 : Task main table
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the task
| 2 | DB_VARST | Subject
| 3 | DB_VARST | Notes
| 4 | DB_INT32 | Start date
| 5 | DB_INT32 | Due date
| |
Table 4000 : Memos main table
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the memo
| 2 | DB_VARSTR | title of the memo
| 3 | DB_INT8 | locked (2) / unlocked (255) status
| 4 | DB_INT16 | number of lines
| 5 | DB_INT32 | ? always 0
| 6 | DB_VARSTR | memo text
| |
Table 4001 : Memo sync status
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the memo
| 2 | DB_INT8 | 1=addition done in Rex, 2=modified, 3=deletion
| |
Table 4002 : Memo categories
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the memo
| 2 | DB_VARSTR | name of category
| 3 | DB_INT32 | number of memos in catagory
| 4 | DB_INT32 | ? always 0
| |
Table 4003 : Category associations
|
Field no
| Field Type
| Description
1 | DB_RECID? | record id of the memo
| 2 | DB_INT8 | number of each category memo is in
| 3 | DB_INT32 | record id of the category
| 4 | DB_VARSTR | memo title
| 5 | DB_VARSTR | first four letters of category name
| |
Table 4005 : Always empty?
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the memo
| 2 | DB_INT16 | ?
| 3 | DB_INT16 | ?
| 4 | DB_VARDAT | ?
| |
Table 8000 : World clock city table
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the city
| 2 | DB_VARSTR | City
| 3 | DB_VARSTR | Country
| 4 | DB_INT8 | Daylight Savings (1=ON, 0=OFF)
| 5 | DB_INT16 | Time difference related to GMT in minutes
| 6 | DB_INT16 | Longitude (degrees)
| 7 | DB_INT16 | Latitude (degrees)
| |
Table 10000 : Picture data
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the picture
| 2 | DB_? | name of picture
| 3 | DB_? | data
| 4 | DB_? | datasize
| |
From the inkmemo source code:
DbInsertRecord( handle, (unsigned long)0, (char *)"", (unsigned char *)"", (short)0 ) )
It does not allow pictures to be larger than 3906 bytes (screensize b/w bmp!)
Table xxx4 meta data (1004,2004,3004,4004...)
If any database contains 'notes' then has a table which stores this.
This table keeps information on how many lines memo/note has, where are EOLs
and how many bytes there are.
Table xxx4 : Database meta data
|
Field no
| Field Type
| Description
1 | DB_RECID | record id of the item (eg memo, contact etc)
| 2 | DB_INT16 | number of lines
| 3 | DB_INT16 | number of characters
| 4 | DB_VARDAT | charactor position of each end of line, stored as a series of two-byte words
| |
Example of table 4004:
example (all in hex, in memory order):
memo:
-----
blablabla
bubububu
-----
DB_RECID : 01 00 00 00
DB_INT16 : 02 00
DB_INT16 : 12 00
DB_VARDAT : 0A 00 12 00
The table also indicates the end-of-line amidst the text (AKA word-wrap
position) so it still displays properly (if you use the line-length
info, of course!). If such a line is displayed on the Rex as-is
(i.e., without wrap to 2nd line) it will be truncated at the right
edge of the screen.
However, the line-length table is only for the medium font (0x10) of
the Rex. If you use the tiny font or bold font, the lines are
too short and too long respectively. Furthermore, these are
proportional fonts, so you can't just assume, say, 50-
character lines. The 'i' is much narrower than the 'w'.
Also, the line-length table specifically takes into account
the Rex memo-display dialog. That is, given the medium
font, the line lengths are marked shorter to allow for the
scroll bar along the right edge of the screen.
Q: How is the database implemented?
The Fujitsu "SoFFS" (Sophisticated Flash File System) seems to be the basis of
Rex's database filesystem, just look at the database.h:
#define DB_ERR_SOFFS -13
It seems that Citizen added a complete database layer on top of SOFFS, in order
to encapsulate and hide SOFFS functionality.
SoFFS is apparently provided only to OEMs who buy the chips, but there is
a catalog
|