Patent Publication Number: US-2003229655-A1

Title: ClientSync - a synching method between a client computer or computers and server computer supporting one-to-many and many-to-one database synchronization when the network connection between the two is not always available or is a low-speed connection.

Description:
BACKGROUND OF INVENTION  
       [0001] In a typical centralized database system, a client computer connects over a network to a server, which stores the database. The client makes a request of the server, then the server handles all of the database operations (querying, adding or updating records, etc.). However, when a network link is slow or when the link is down, a client computer cannot connect effectively to the central database. This causes a delay in data manipulation as well as productivity losses since the computer operator cannot perform his or her duties without access to the server.  
       [0002] This situation can be avoided by storing a subset of the central database locally on the client computer. Any manipulations made by the operator are stored locally, until such time as a good network connection is available.  
       [0003] When the connection is available, the user can either execute the Sync program or let the ClientSync scheduler execute the program. The newly added records are copied to a corresponding table in the central database, then a set of basic instructions is performed which writes the data into the actual data table or tables. The data is then copied back from the central database to the user&#39;s local database, thus ensuring that each user who performs the sync function has an up-to-date database.  
       SUMMARY OF INVENTION  
       [0004] It is the object of this invention to allow a primary database, stored on a host computer (laptop device or desktop device) to be updated with information stored in a database on a handheld computer (PDA). The data on the handheld can be updated as well. 
     
    
    
     DETAILED DESCRIPTION  
     [0005] The solution is based on having a local copy or a subset of the central database. The subset copy can be accessed by the operator when the link is down. All operations on this subset database are saved in a log file or a table. When the link is up a small program kicks in and synchs the central database with the client subset (local) database. The synchronization process works as follows:  
     [0006] 1. The synch program runs through the log file (or table) and reads the operations performed on the local data base.  
     [0007] 2. The synch program re-runs these operations (from the log file) in the central database and performs the changes  
     [0008] 3. The central database maintains its own log file, so when (1) the sync program at the client performs the change it is always looking to see if that record or field was changed by another client or server and if so, it sets this record aside for the server to handle (4).  
     [0009] 4. After the sync process the server will end up with a collision list (records which were changed by more than one client). If the administrator configuration allows for auto-handling then the server will sort the collision by date/time and perform the operation(s) on the central database (earliest first). All of these operations will be kept in a log file so an undo can be performed by the operator.  
     [0010] The outcome of the above is that a record is not changed as in a traditional synch process, but, rather, the operation (from the log file) is driving the sync. That way the sync process is synchronizing the operation itself, but not the record. The result is a record change and/or field change.  
     [0011] After the Sync is completed, the local database will contain not just the data generated by that user, but data from all other users as well.