PC SOFT

ONLINE HELP
FOR WINDEV, WEBDEV AND WINDEV MOBILE

Home | Sign in | English US
  • Overview
  • Implementing the replication of HFSQL servers
  • Prerequisite
  • FAQ about the replication between HFSQL servers
  • When implementing a replication between HFSQL servers, why are the automatic identifiers coded on 8 bytes?
  • Why are the values of automatic identifiers added once the server replication was implemented so high?
  • The structure of files was modified in the analysis (addition, modification or deletion of items). How to apply the modifications to the files found on HFSQL servers with a server replication?
  • Replication of servers: Are the transactions managed on the HFSQL servers?
  • Replication of servers: Which security for the replication of servers?
  • Replication of servers : How are the server triggers run?
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaReports and QueriesUser code (UMC)
WEBDEV
WindowsLinuxPHPWEBDEV - Browser code
WINDEV Mobile
AndroidAndroid Widget iPhone/iPadApple WatchUniversal Windows 10 AppWindows Mobile
Others
Stored procedures
Overview
The replication between HFSQL servers consists in automatically replicating the data from server to server, in an asynchronous way.
A simple example: a company can have several HFSQL servers in different locations, a server in each branch for example. The replication between servers is used to replicate the data of each server.
Several replication methods can be implemented:
  • the linear replication: Two or more servers are linked two by two.
  • the replication in star: For example, the headquarters and the agencies use HFSQL servers. The agencies can synchronize their data with the headquarters at regular time interval.
  • the replication in tree structure: For example, a multinational can synchronize its agencies by continent, then by country.
In all these configurations, the replication is defined by couple of servers. The replication can be:
  • unidirectional or bi-directional.
    In a unidirectional replication, the data flows in a single direction. The updates are performed from a master server to a subscriber server.
    In a bi-directional replication, the data is synchronized in both directions. The updates are performed on each one of the servers.
  • periodic or continuous.
    A periodic replication is performed at preset time interval: every evening at 20:00, ...
    A continuous replication is performed whenever the database is modified (a time-out can exist between the initial modification and the update performed on the other servers).
Note: From version 19, HFSQL is the new name of HyperFileSQL.
Implementing the replication of HFSQL servers
The replication of HFSQL servers can be implemented:
Caution: Implementing the replication between several HFSQL servers requires some adaptations in the application (see the next paragraph).
If these adaptations are not performed, the application may not operate properly and data may be lost.
Prerequisite
Implementing the replication between several HFSQL servers requires some adaptations in the application.
1. Regarding the application analysis
In the analysis, the data files involved in the replication of HFSQL servers must have:
  • an automatic identifier on 8 bytes. If the automatic identifier is coded on 4 bytes, it must be modified.
    Caution: This modification can trigger modifications in the code of the application. For example, when handling file identifiers with integer variables.
    • Find "n is int = fic.autoif" in your application to replace the integer by an 8-byte integer.
    • Check whether your file identifiers are passed to procedures that expect an integer. In this case, you must either remove the type from the declaration of the procedure, or use an 8-byte integer .
  • a primary key (which means a unique simple or composite key that does not accept a null value and whose components do not accept a null value).
2. Regarding the application
  • HCross must not be used.
  • A file cannot be copied if it is replicated: HCopyFile must not be used.
    Note: For a unidirectional replication:
    • the copy to the master server is not allowed.
    • the copy from the master server is allowed.
  • You cannot restore a replicated file: HRestoreBackup cannot be used.
  • The HFSQL clusters must not be used on the replicated data.
3. Select the information to replicate: Implementing the replication of servers reduces the performances of HFSQL servers. We advise you to implement the replication between servers only for the data files really affected by the replication. Do no hesitate to exclude some files from the replication.
Caution: The bi-directional replication between several HFSQL servers requires to use of fixed IP addresses or "reverse-DNS": the name of server on which the replication was created must be found.
FAQ about the replication between HFSQL servers

When implementing a replication between HFSQL servers, why are the automatic identifiers coded on 8 bytes?

When the primary key is an automatic identifier, the server must check the uniqueness of the identifiers on all the servers taking part in the replication.
To do so, each replication server uses a range of different values for the automatic identifiers of the created records. In order for the range of automatic identifiers used by each server to be wide enough, the automatic identifiers must be coded on 8 bytes.

Why are the values of automatic identifiers added once the server replication was implemented so high?

Each server taking part in the replication is using a different range of automatic identifiers based on the identifier of replication server.
The first range of automatic identifiers (the one that starts from 0) will not be used by any server taking part in the replication: this range of identifiers is reserved to the existing data when implementing the first replication. Therefore, as soon as a new record is created in a server replication, if an automatic identifier is assigned to the file, the value of this identifier will be a high value.

The structure of files was modified in the analysis (addition, modification or deletion of items). How to apply the modifications to the files found on HFSQL servers with a server replication?

All you have to do is apply the modification of structure (automatic data modification) to the master replication server. This automatic data modification can be run:
  • from the data model editor,
  • when installing the application
  • by programming.
During the next data synchronization between servers, the modification of the file structure will be automatically applied to the subscriber HFSQL servers. The stored procedures and the server triggers will also be updated during this synchronization.

Replication of servers: Are the transactions managed on the HFSQL servers?

When records are modified, added or deleted in transaction on a HFSQL server in replication mode, the records are replicated on the subscriber servers only when the transaction is validated.
If the transaction is canceled (rollback), no replication will be performed for the relevant records.
If the transaction is validated, all the operations in transaction will be transmitted to the replicated servers.

Replication of servers: Which security for the replication of servers?

The communication between servers is authenticated. It is not encrypted. We recommend that you use a VPN connection between servers. The communication between servers is authenticated. It is also encrypted.

Replication of servers : How are the server triggers run?

A server trigger associated with a file update is run on the HFSQL server for which the function that activates the trigger is called.
All the modified records are synchronized by server replication.
Therefore, if a server trigger makes modifications in the data, these modifications will be automatically applied to the replicated servers without having to run the triggers on the replicated servers.
Minimum required version
  • Version 18
This page is also available for…
Comments
Click [Add] to post a comment