>> I was just discussing this subject with Jim Duffy about using FoxAudit for replication. From what I gathered, I think FoxAudit would work great for data replication. The remote site would run your VFP app. w/FoxAudit logging the transactions. When you decided to replicate you grab just the transactions that have occurred since the last update and send them to the other site. The other site takes this information and "Rolls Forward" the transactions.
>>
>> In the next couple of months I'm going to be trying this out, so I'll see how it goes.
>>
>>-Paul
>
>It seems you're talking about uni-directional replication. Do you have an information about FoxAudit and bi-directional replication?
>
>Years ago I used a product called DB-Log that did just what you said FoxAudit does, log transactions that could be used for replication. I found it very combersome to do bidirectional replication with more than 2 sites over non-dedicated communications link (e.g. dial-up). I had to abandon the use after couple of months of hard labor.

I've done bi-directional replication in FPD2.6, but it's a kludge. I had to assign a unique ID to every record in every table, and have a Changed logical in each of them, take care it's set whenever a record is updated/deleted/added/recalled, and reset when received. It works, but I'm just lucky - 99% of the records are actually never updated anywhere else than the place they were created, so it practically never has to decide whether to update an already updated record. As it is, a received record always updates the present record, which is not the best of the worlds, IMO.

The worst hassle are the customer IDs. I had to allow for new customer records to be created independently on each site (they have trouble communicating with the central), just taking care they remain unique, and then had to create a routine for the central site to put those codes together, because same customers may appear at several sites. Now when a temp ID is replaced with a permanent ID, I have to scan for all the records with that customer's ID and replace it for the new one, plus mark these records for distribution, plus keep this temp ID in a separate field in the customer table, because by the moment the ID is updated in the central, there may be new records with this temp ID at outer sites, so they'd have to be updated later when they arrive.

Sounds as complicated as it is. I'd also wish there was some smarter way to do it automagically.