>Hi!
>
>>>If you want, I can spend my free time and write a simple replicator for VFP database, but tell on which basis it should work: timestamp or full match. Timestamp is the best approach, when each table have a timestamp field and application updates this field each time changes are made (this coul be done by default value for new records and update triggers in VFP database). Second approach is more generic and complex and have less performance, because it searches changed records using exact field to field match.
>>>
>>
>>I'll take you up on that offer. Thanks! I think I would prefer the second option: full match.
>>
>
>Ok, will try to make it at this weekend. Full match will be by record only, in other words, if any field is in collision, the entire record is claimed as in collision and collision rules wll apply to antire record. I will not do field by field collisions resolution.
>
>>Here is my question: I now understand about the problems of data collisions regarding memo fields. But, I'm not understanding the problem with other types of fields. The problem still doesn't seem intrinisic to the design. In other words, in a "normal" design User B could still overwrite the changes made by User A (character, numeric, date, etc). So, I would be interested in what you will write and hope that your solution helps me to understand the problem.
>>
>
>As I said, you can define the rules for collisions on the level of each field or record. Popular frameworks have such thing as data dictionary. There is a separate toolkit for that (Stonefield data toolkit). All fields are stored in separate database there. You can define additional property for each feld that describe the rules for collision. For example, functio to run in case of collision found for that field or record. In most cases when collision is found, the priorities are used, in other words, which database is most important, that database record data become live. For example, when user A is programmer and user B is manager, B has more priority, so his data, in case of collision, will overwrite server data (when user B replicates data to server) or will be kept unchanged on the server (when user A replicates data to server). Quite obvious.
>
>Another popular approach is to store all records that have collisions into the separate table with the same structure as the main table for further review by administrator or user that makes replication. This could be also just leaving the new data record at the user's database after replication (the collisions database is just the user's databae). This, of course, requires additional software for manual collisions resolving.
>
>Next approach is to store both records in he table but mark second and further versions of the same record as revisions. Than in the user interface on the form provide tools to see revisions of the record. Used usually for office documents tracking system.
>
>So, what method you prefer? Each has advantages and disadvantages.
>
>>>> 3. I recently found an article/zip by Doug Hennig at the Stonefield site about how to implement a system similiar to what I wanted using CREATEOFFLINE. I've completely overhauled that class to make it more robust and generic.
>>>>
>>>
>>>Can you give ma a link?
>>>
>>
>>Do you mean a link to Doug's code, or to what I've written? If you refer to mine, send me your email address and I'll send you a zip file.
>>
>
>My EMail is in each my message. In addition, in the UT you can click on the envelope to right from the First/Last name of the UT member in the header of each message.

Very interesting thread, which I came up accidentally (I missed it today).

I believe, we use the "Another popular approach", but I doubt, we have written a special form for resolving collisions...

I'd like to follow this discussion...