If you use email, be sure to employ some technique to have a confirmation on the server side that it have received and processed the data OK. FTP is more suitable as you hav an instant confirmation that the file got to its destination. Even so, you should need a confirmation that the data was appended to the server (some error could happen in the procedure, and you should resend the data).

>Thanks Ronald;
>
>This is the approach I am following; What I currently do is;
>
>1. User chooses data to be sent and exports;
>2. While exporting application creates XML files from respective cursors, compresses them and sends it as email.
>3. Other side imports the data from the email;
>4. Application depcomresses and converts XML to VFP cursors and imports into tables.
>
>This is working fine. But I think there must be some better way of synchronizing remote tables/dbcs, since both the site has dedicated connection to Internet.
>
>Please share with me in case you find some solution!!
>
>Thanks again;
>
>Cheers
>Shaishav
>
>>Shaishav;
>>
>>I am no expert on synchronizing databases, but we are faced with a similar problem. Our application is being required to maintain a central DBC where 4 remote sites are constantly online and updating. We have been testing the feasibility of our visiting nurses entering data on a per visit basis by means of tabletPC's that they are using in the field. Our task was to be able to maintain the DBC's on each tabletPC with current information as well as being able to download any new information or updated information to the central DBC. Since we are in a remote area we are limited on ability to connect to the networks other than periodically (hopefully minimum of 1 per day). Our solution was to create an audit system were we are recording each table's modification for Insert, Update and Delete thru triggers which record changes for each DBC to a central Master DBC. To accomplish this, all tables have a pk field which is unique global. With this in place, each day, what I refer to as
>>XML packets are created for each DBC or Table (Presently we are using it on DBC basis, but may find we need to go to some tables to reduce the number of lines in each packet) on the central DBC. Each visiting nurse connects to the network at one of the remote offices, downloads the Packets of information that they have on their personal tabletPC and then uploads all packets from the central DBC which contains not only the changes from those who are directly updating the central DBC,but also all of the other visiting Nurses that downloaded their packets. Along with this process, each tabletPC also reserves a block of PK's for its use. Hence we are finding that this has been working rather well as long as the packets are of smaller size. One issue that we have is, for example, visiting nurse A syncronizing in the morning, then later nurse B. Well Nurse A does not get those modification from Nurse B until the next day. It has not been a real big problem, but does create some
>>concern.
>>
>>To accomplish this, we developed a MasterDBC that contains a log record of each modification from the triggers in each table. Then a syncronization routine that collects these changes and stores the XML packet in a syncronization record that can be either directly uploaded for those that have the means to get on the network, or we can sent by means of e-mail to the remote TabletPC or even by means of a UBC Drive. Presently we have been testing with about 150 concurrent users on the central DBC and 10 remote TabletPC's. We have found that for our situration, the packets can contain about 1000 records of modifications per packet before the process bogs down. So if we start with a syncronization to a tabletPC that requires lets say 25,000 records, this is broken down to 25 packets and time to syncronize is approximately 45 to 75 seconds which has been very acceptable. Compared to our first process by comparing record by record each table in the DBC's which was taking up to 25
>minutes
>> to complete the process. Our applications include 12 different DBC, but at this point we are only finding that 7 DBC's need to be syncronized to the remote TabletPC's. Our timetable is to have from 150 to 180 tabletPC's in the field by this falll and will be able to report back how successful we are at that point.
>>
>>I know I have rambled on, but earlier I had requested suggestions on syncronizations of tables and did not really find a good solution until coming up with the above (good or bad, time will tell). Would appreciate any comments as to possible problems that could occur that I am not thinking about at this time.
>>
>>Good Luck in your process.
>>
>>>Hi no-one is coming up with any suggestion??
>>>
>>>This is most unlikely that I have not received any reply on question I posted!!!
>>>
>>>Please reply someone!!
>>>
>>>TIA
>>>Shaishav
>>>
>>>>Hi Everyone,
>>>>
>>>>I have applications running on two locations. I would like to post some data from one side to another side.
>>>>
>>>>One application is developed using VFP6 and other is VFP7!
>>>>
>>>>Both the servers are connected to dedicated broadband connection!
>>>>
>>>>Please guide what is the best way of transfering data from VFP6 application to VFP7 application running remotely.
>>>>
>>>>Currently; I am compressing the datafiles and sending it via email; and they are downloading and importing the updates.
>>>>
>>>>I am sure there must be a better way!