(I'm trying to get this back onto gpe_at_handhelds.org rather than with
individual addresses.)
Owen Cliffe <occ_at_cs.bath.ac.uk> writes:
> There is a problem with having the standard/user-defined contact types
> both in the database in that the typeIDs of the user types will start
> from where the pre-defined types left off, which will cause a future
> compatibility should we add more user defined types, so we want a way of
> all the new user-defined types starting with a typeID > some constant
> which is about (0x0000ffff) but this means that to add a user-defined
> type you would:
Maybe you can elaborate a bit, since I'm not quite following why it would
matter what's pre-defined and what's not. If the list of possible contact
types were presented to the user ("SELECT contact_type_name FROM
contact_types;" -- no WHERE clause) he'll see all of them. If new types,
whether "pre-defined" or otherwise, are added later, they would get the next
available ids. I missing what you're trying to get at, as I don't see why
this is a problem.
This does, however, bring up the issue of synchronization. Synchronization
with other than a GPE app should provide the contact_type_NAME rather than the
contact_type_ID. (The name may or may not map to the other app.). When
syncing with another host running GPE, then the databases can be merged, and
the appropriate new id from the host being synced would be inserted for each
of the contacts being inserted from the other host.
Derrell
Received on Thu Feb 14 2002 - 10:18:45 EST
This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:18:59 EDT