Hi!

> How could I know there are changes on the records? Do you meant I need to have a extra field that will store the date/datetime of last updated for every records in every tables?

Yep, you need an extra field or extra work ;) SQL Server automatically adds extra global unique ID for each table in replication (sometimes this causes changes in application).

In case with VFP databases and custom replication program, youc an use different approaches. the most quick approah from the performance point of view is to use datetime field for each table and update date/time to current each time record changed or added. Than simple scan for all records that have this field later than last replication successful running date/time will give you all changes requires for replication. This approach, however, have a significant disadvantage - it requires a lot of programming or/and maintenance for client application to keep this datetime field in synch to do not have any changes out of track.

Another approach is to use comparison. this way is easy and does not require any changes in the client application, that is the significant advantage in case when your application already running on sites and is large anough to throw out previous approach at all.
Make a backup copy of client (branch) database each time after successful replication. When next time replication routine runs, compare backup database with working database and take all differences as changes.

Anothe note I have is about conflicts. This is very big problem in replication that gonna not to be an issue in your case. the conflict is when two different sites (branchs) changed the same record thus causing conflict on the main server - which change should be used? In your case you marked each record of each (I hope) table by branch number, that makes al records unique through all sites. This should prevent conflicts problem, unless you will allow branches to edit records of other branches or records of main server data.

HTH.