|
|
|
|
|
|
|
|
|
|
- Overview
- Log-based replication by network
- What is it?
- The possible actions
- How to replicate by network and programmatically
- Constraints and tips
- Log-based replication via portable media
- What is it?
- The possible actions
- Constraints and tips
- Programmatically
- WLanguage functions for managing log-based replication
- Functions for managing log-based replication
Journalized replication: Programming journalized replication in WLanguage
 Available only with this kind of connection
Several WLanguage functions allow you to include log-based replication in your application and to customize it. In this case, no external tools are required: you program the data replication between your databases yourself. Two modes of log-based replication can be implemented through programming: - log-based replication by network (case of a laptop that connects to the company network on a regular basis).
- log-based replication via portable media (case of remote sites that do not connect via a network).
Log-based replication by network What is it? Log-based replication by network corresponds to the operation performed to synchronize two databases accessible on the same network. The most common example is a salesman who regularly connects to the company network via his laptop computer. The replication allows him to update the company database with the new orders entered during the week. During this operation, the company database and the laptop database are accessible via network. The replication can be performed via network. The possible actions Log-based replication by network is used to perform: - a unidirectional replication:
- from the master computer to the subscriber computers.
- from the subscriber computers to the master computer.
- a bidirectional replication, which means from the master computer to the subscriber computer and vice versa.
How to replicate by network and programmatically The following operations must be performed: - Creating the master replica on the master computer (HCreateMasterReplica).
- Creating the subscriber replica on the subscriber computer (HCreateSubscriberReplica). The subscriber computer must have read/write access to the disk where the master application is installed (directory of data files).
- Using the master and subscriber applications.
- Synchronization (HSynchronizeReplica):
- from the subscriber station to the master station (constant rplVersMaître): the subscriber station must have read and write rights on the disk where the master application is installed.
- from the master station to the subscriber station (constant rplVersAbonné): the master station must have read and write rights on the disk where the subscriber application is installed.
- or bi-directional (constant rplbidirectional): the master station must have read and write rights on the disk where the subscriber application is installed, and the subscriber station must have read and write rights on the disk where the master application is installed.
Warning This paragraph assumes that the necessary operations have been carried out in the application analysis before installing the application on the various workstations. For more details, see Log replication: Analysis modification. Constraints and tips - When creating the subscriber replica, the computer where the subscriber replica is installed must have read/write access onto the directory where the master replica is installed.
- To perform the log-based replication, the path of the data files to replicate can be identified by:
- a drive letter. In this case, the two computers involved in the replication must use the same drive letter. For example, if the replication is started from the subscriber computer:
- on the master computer, the directory of the data files is found on X,
- on the subscriber computer, the letter X must be associated with the drive containing the data files of the master computer.
- UNC paths
- relative paths.
- To manage the logged replication in an application, the table of the log operations (JournalOperation.fic file) must be identical for all the data files in replication in the same analysis.
- It is advisable to save the data files required for log replication ( *.rpm and *.rpl files) in an RPL subdirectory of the application data files.
- If the log process is used for the replication only, the log files can be located in the directory of application (or in a subdirectory).
- If logging is used to keep a backup of data files, it is advisable to place these files on a different disk from the data files (for greater security).
Log-based replication via portable media What is it? Log-based replication via portable media corresponds to the operation performed to synchronize two databases not connected to each other. The most common example involves two geographically distant sites: one in Montpellier and one in Paris, for example. Regular database updates are carried out using a variety of media: FTP transfer, CD ROM, etc. The possible actions Log-based replication via portable media allows you to perform a unidirectional replication: - from the master computer to the subscriber computers.
- from the subscriber computers to the master computer.
Constraints and tips - To manage log replication in an application, the log of operations table (JournalOperation.fic file) must be identical for all replicated data files in the same analysis.
- The files required by the log-based replication (*.rpm and *.rpl files) should be saved in an RPL subdirectory of the application data files.
- If the log process is used for the replication only, the log files can be located in the directory of application (or in a subdirectory).
- If logging is used to keep a backup of data files, it is advisable to place these files on a different disk from the data files (for greater security).
Programmatically The following operations must be performed in order to synchronize the master computer with the subscriber computer: - Creating:
- the master replica on the master computer (HCreateMasterReplica).
- the subscriber replica on the subscriber computer (HCreateSubscriberReplica). Each subscriber computer must be associated with a specific identifier. This identifier will be used during the synchronization.
These two replicas can be created in the same directory (not recommended).
- Installing the file of subscriber replica on the subscriber computer. This file can be installed:
- in the replication directory specified in the analysis (\RPL subdirectory of data files by default).
- in another directory. In this case, the subscriber application must use HChangeRplDir to specify where to search for the file of the subscriber replica. When the subscriber data file is opened, the RPL file is read to define the range of automation identifiers used by the data file.
- Using the master and subscriber applications.
- On the subscriber computer, creating the movable replica (HCreateMovableReplica). A file with a WDZ extension is created by default. This file must be transmitted to the master computer.
- Synchronization on the master computer (HSynchronizeReplica). To perform this synchronization, you must specify:
- the name and path of the movable replica on the master computer
- the identifier of the subscriber replica (specified when creating the subscriber replica).
Warning This paragraph assumes that the necessary operations have been carried out in the application analysis before installing the application on the various workstations. For more details, see Replication with WINDEV. WLanguage functions for managing log-based replication Functions for managing log-based replication The following WLanguage functions are used to manage log-based replication:
| | | HChangeRplDir | Changes the location of the subscriber replica description ("*.rpl" file). | | HCreateMasterReplica | Creates the description file of a Master Replica (logged replication or universal replication). | | HCreateMovableReplica | Creates a movable replication. | | HCreateSubscriberReplica | Creates the description file of a subscriber replica. | | HInitSubscriber | Initializes the range of automatic identifiers for the description file of subscriber replica (".rpl" extension). | | HSetReplication | Temporarily disables (or re-enables) the replication. | | HSynchronizeReplica | Synchronizes master and subscriber replicas: operations performed on one replica are transferred to the other. |
This page is also available for…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|