>>I have taken on a project in which satellite offices will
>>collect data, and at regular intervals send this data
>>to a main office. The satellite offices may also request
>>data from the main office.
>>
>>Both the main office and the satellite offices may send or
>>receive data from each other, or the sattelite offices may
>>send data back and forth at any time.
>>
>>Some offices will be using dial-up connections, some may use
>>more fixed connections like cable modem or DSL. There is no
>>network in place.
>>
>>Once the data is collected, the main office will process it
>>and the send this data to other organizations.
>>
>>My question is this: Whats the preferred method for sending
>>and receiving data? I am leaning towards having my application
>>ZIP up the required records and send it via modem upon user
>>request.
>>
>>Should I do this via email? Or is there some way to actually
>>transmit the data to another PC via IP address?
>>
>>Any input would be really helpfull.
>>
>>Thanks
>
>
>from my experience doing this, whatever details you settle on, i strongly
>recommend writing all the synchronization code yourself.
>
>i would start with a wholesale transfer of the tables.
>if you expect to accumulate a lot of data, you should consider from the
>beginning, to incorporate some fields to serve as version info so you
>can implement a transactional sync versus a wholesale transfer and replacement
>style sync. otherwise the transfer latency will eat you alive.
>keep the whole-table transfer method available, which is handy to
>update table structures. you could implement a table structure update
>procedure too, but of course, the more elaborate you get, the longer
>it takes to write and the more complicated to maintain.
>
>if you are using dial up networking, you can map to a share on your
>server and transfer files. to invoke a program on the server you can
>use RPC to incorporate your transactions into the warehouse and/or
>extract your transactions for transfer to a remote machine.
>this arrangement affords you very good security (if that is an issue).
>
>the problem with transferring to a mapped share, is the requirement to
>log in to the 'host' server. if your remote computers participate in a
>network, i've found it necessary to create and boot into a non-network
>hardware profile to be able to log into an NT server. this is not a
>big deal if your clients are part of your company, but to have to do
>this for non-employee clients, it's a pain. ftp transfer of
>the files would avoid this problem. wish this had occured to me before
>i started.
>
>right now, i have the luxury of opening server files exclusively for
>update. if you can't do that, you will resort to table-level or record-level
>locking to do updates. someday i may upscale to oracle backend to avoid this
>issue entirely.



and yes, setting up a user interface to sync on demand is a good feature.