If you are using Delphi you can use the tclientdataset which has a
Briefcase type system built in.
Or you can use one of the many middleware systems that are available for
Delphi, all of which will do what you want.
www.remobjects.com
www.astatech.com
etc etc
Most of them work by creating a XML local dataset then applying that XML
dataset when the client logs back in, it handles the conflict resolution
etc.
Delphi really is one of THE best ways to develop database apps.
Tony
Scott Marlowe wrote:
>On Tue, 2005-03-29 at 16:06, Caleb Simonyi-Gindele wrote:
>
>
>>John Burger wrote:
>>
>>
>>
>>>>>If it were me, and someone proposed a model where two-way replication
>>>>>was needed, I would tell them to rethink their model. It's broken.
>>>>>
>>>>>
>>>>I would respectfully disagree that the requirement for two-way
>>>>replication
>>>>indicates a broken design.
>>>>
>>>>
>>>I agree with your disagreement. This design is present in lots of
>>>non-RDB systems - CVS, IMAP, PDA syncing, etc. It's clearly more
>>>complicated, but can be made to work, and has been many times. I
>>>don't see anything about databases in general, or Postgres
>>>specifically, that indicates it's a bad idea.
>>>
>>>- John D. Burger
>>> MITRE
>>>
>>>
>>>
>>Yes, we use it successfully with the SQL Server edition of our product.
>>Does anyone know if this is available with Postgre?
>>
>>
>
>It's important to understand that what you're asking for is MORE than
>simple replication, it is replication with ((semi)automatic) conflict
>resolution. If you use a simple replication system to try and do this,
>you are likely to wind up with inconsistent data.
>
>Just because SQL Server does it doesn't mean it does it right. And the
>general philosophy of the PostgreSQL team seems to be do it right or
>don't bother.
>
>So, what are the chances that you'll have records on your sales folks
>machines that have also been updated back at the home office? What
>rules should be applied when conflicts arise? These are the kinds of
>questions you need to answer before jumping feet first into the fire and
>getting burnt.
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>
>
>