Thanks very much!!! You've given me some interesting things to think about.
I've also heard of using MSDE on client machines and SQL Server as master database to handle replication. But I don't think that will work for us right now. So we'll have to do it the hard way.

We are not talking about a very busy website. At the most have 50 clients using the web. On average, each client has mayb 350 customers. Not all will access web. It involves payment plans, so usually you have monthly peak times when payments are made.

I noticed you had some interesting articles about COM interop. I guess that might be a way to handle asynch database operations. Also, if I'm correct, you offer some components that can handle connection issues with HTTPS. I'll probably implement .Net in some ways.

Below I have a scenario of how we were thinking of accomplishing the data replication (it's very long so if you (or anyone else) can't look at it, I will certainly understand)

**********************************************************************************
Summary

Server on our client's side (Master Database)
1. Build an external daemon app that runs in background (Master Replication Object)
a. Use timer to control update frequency
b. Send changes to web server
c. Accept changes from web server and apply to Master Database
2. Internally in client sofware call Master Replication Object ASYNCHRONOUS when opening a student record (.net COM interop?)
a. This allows administrator to immediately view record retrieved from master database and not be locked out while checking for client database update (unless record was created on web and doesn't exist yet in Master Database. Then check web for new record)
b. If no change is found on matching record in client database, nothing happens
c. If change on matching record is found, user notified and given option to sync data.
i. All changes are then imported from the web.

Web Server (Client Database)
1. Build a listener (Client Replication Object) that receives data updates from Master Database and provides data from Client Database for update requests from Master Replication Object
a. Client database update frequency is determined by the Master Replication Object.

***********************************************

Detail Outline

1. Updates table: key I, studKey I, updateType C(1), TimeStamp D, alterd L
2. TimeStamp table: key I, lastUpdate D

Send data to web server***
1. When a record is Added, Edited, or Deleted a record is appended to Updates table
a. Field UpdateType will receive values A, U, or D (Append, Update, Delete), studKey = customer ID

2. Based on timer intervals, Master Replication Object(MRO) checks Updates tables for records.
a. If found
i. Updates.TimeStamp = datetime()
ii. Timestamp.lastupdate = updates.timestamp
iii. MRO copies data from Master Database to temporary cursor where updates.TimesStamp = datetime().
iv. Converts temporary cursor to XML
v. Pass data to web server.
vi. Await notification of update success or failure
1) Success, Updates.Alterd = .T. where timestamp.lastupdate = updates.timestamp
a) Delete matching timestamp records in updates table
2) Failure, Updates.Alterd = .F. (default value)

Retrieve data from Web Server ***
3. Based on timer intervals, MRO requests updates from web server
a. Receive updates as XML
b. Convert xml to temporary cursor
c. Using Transaction, Update master database (use similar method as TierAdapter framework uses)
d. Return update success or failure to web server.

Doing asynch update***
a. Call .Net object running on separate thread which instantiates Master Replication Object
i. Pass in studkey value
ii. Pass data to web server
iii. Returns .T. or .F.
iv. If .T. give user option to update records
1) If yes, synch data as above.
2) If no, nothing happens.


Update on web side***
a. Have Updates and Timestamp table on web.
b. Listen for Client Table update Request.
i. Instantiate VFP com dll
ii. Accept XML, create temporary cursor, update records
iii. Return .T. or .F.
c. Listen for Master Table update Request
i. Same as MRO on client machine above
*****************************************************************************************

If you are still with me, I think I have the main issues covered, UNLESS I missed something big. To me, however, using the right tools like some of your utilities, it seems that this is a workable solution. The administrator will be able to view current data. The occasional user's data will be pretty current (depending on frequency of updates).

Any final thoughts?

Marcel