Hi!

I did not seems understood question well. However, I will describe some basics of replication procedure for VFP tables. Take a look to it and see if it can help.

In usual can table have the primary key as auto-generated integer number that guarantee that each record (include deleted) will have unique ID number.

When you use such PK, you will have following cases and resolutions of them for replcation. In case of other PK (for example, you deleted some record then created new record with such PK value), it will be extremely hard.

1. Changed client record that exists on the main server - just update main record by PK ID
2. Deleted client record that exists on the main server - just delete main record
3. Inserted record on client side - use main server PK generator to change the PK ID to be correct for main server, and adjust it after that in the client record. Usually this require also to fix ID value for all fields that use this ID in related tables for relationships in the client tables. This also require to update data on main server in the string order - parent table first, than child tables level 1, then level 2 etc.
4. Main server record change, client not changed - just update client
5. Main server record inserted - add record to client after steps 1-3 done completely for all records to avoid collisions between PK
6. Main server record deleted - delete record in client table.
7. Main server record changed and client table record changed - collision (resolve it by way you want).
8. Main server record recall - add record to client table if it is not already there.
9. Client table record recall - if exists on main server - recall, when not exists - add.

For item 3 special note: Because it is hard to track all relations in generic case, in many cases programmers search a way to avoid collisions between PK on the client side and mains erver. They use a generated global unique ID (GUID), or just use much more simple approach:
each client office have ID shift. For example, Main server ID values are from 1 to 999,999. Office 1 will have 1,000,000 to 1,999,999, Office 2 from 2,000,000 to 2,999,999 and so on. Just shift the PK value for each office to they will never cross. This, of course, require to know how much records could be in the table at all and configure range by appropriate way, however, sometimes it is not possible in bounds of integer type minand max values.

And no playing with SET DELETED or filtered indexes (I hate filtered indexes, specially in the PK, because such indexes are not used in optimization). I even do not see where this could be used in a replication proces...

HTH.

>Hi,
> I am writing a program that replicate changed data of branches and sent it to head office for batch processing and etc. After that, the updated data have to send back to branches.
> I am using comparing working table data with backup table data to obtain the changed record and write it to forward table.
> I have problem that:
>
>1. My application allow user to reuse the code for example, customer code. We are using delete and insert method in this situation. Therefore, the "same record" may appear more than one (just one is not deleted, the other are deleted). Once i try to compare them with backup table data, i always get the first matched record (BTW, I SET DELETED OFF in order to get deleted record also). To solve it, other delvepers recommend me to have "myprimary key and NOT DELETED()" in my search condition when locate for the record in backup table (Thank you for your suggestion!!). However, it will get all "changes transaction" of each records. For example, AW01 deleted, AW01 deleted, AW01 undeleted record. How to solve this problem? If I try to locate for myprimary key when update the "changes" to forward table, will it work? This will get the final result of each changed record.
>
>2. Should I place all the replicated data of branches in the working database located in head office or seperate these with head office's working database?
>
>Thank you .
>Pls don't hestitate to ask if your are not clear about my problem