Aside from the problem you have mentioned (which
should be able to be solved if you write your own
conduit instead of using the default) there is
a consideration you have not mentioned.
Scenario:
Admin creates entry in central db
User changes entry on their pilot
Admin changes entry in central db
What happens the next time the user
syncs:
A: Does the Admin's record overwrite
the user's (losing their changes)?
B: Do you create a new (essentially
duplicate) entry reflecting the Admin's
latest version?
C: Something else?
A central scheme works better if the user
does not have the ability to change things.
You may consider granting the user the ability
to >add< a note to the record while guaranteeing
that the Admin could never create a "user note"
that could wipe it out. (You may need to support
both "user note" and "admin note" attachments...)
With attached user notes, the user could never
actually change the record itself, and therefore
could never lose their changes due to an Admin
update.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
> -----Original Message-----
> From: [EMAIL PROTECTED]
>
> Okay, I'm asking for the impossable here but here we go. I'm trying to
> create an address book
> for my office but have come to a stand still. The address
> book must be able
> to be updated by
> an admin plus the user. Now this is the tricky part, the
> individual users's
> changes CAN NOT affect
> the main address book.
>
> ADMIN ENTRY >>>>>>>>>>>TWO WAY SYNC<<<<<<<<<<<< MAIN ADDRESS BOOK
> >>>>>>>>ONE WAY SYNC>>>>>>>> USER ENTRY
>
> The problem is the one way sync with the user. How do I have
> the admin make
> an update and have the user know about it,
> but not have the user's entries change the MAIN ADDRESS BOOK.
>
