> Hi Rick;
>
> I have been looking for a few years at a similar situation with my CRM
> software and soon (once I have the SOAP interfaces done, I will start on a
> stand-alone client. I have eventually decided on a very different
structure
> than you have, though the result is more or less the same.
>
> Rather than using PostgreSQL as an embedded database manager, I have
decided
> that it makes more sense for my app to "cache objects" in XML documents
and
> then use those on trips to customers' sites. The XML documents can then
be
> checked and the objects re-sync'd when the app goes online again. The
> cacheing would be automatic and cached objects would expire unless
> explicitly saved.
>
> Why not use XML for this sort of problem? Or berkeley DB? Is there any
> reason that PostgreSQL would be better? I am not aware of any functional
> replication systems which would work in this way, so I am guessing your
app
> will have to handle all the logic for the syncronization anyway.
Well since the desktop and server app are using almost exactly the same code
it is nice to not have to recode everything that accesses the database.
While data syncronization code will have to be written either way I want the
existing code to "just work" once taken off line.