|
|
|
|
|
|
|
|
|
version 6.0
bk_Debut mise a jour miroir 
Entier
| Paramètre | Type | Description | ||||
| Cette commande ne requiert pas de paramètre | ||||||
| Résultat | Entier |  | 0 si l'opération s'est déroulée correctement, sinon | |||
| Code d'erreur | ||||||
Description
Toutes les commandes et fonctions de 4D Backup doivent être encadrées par les routines bk_Debut mise a jour miroir (ou bk_Debut sauvegarde integrale) et bk_FIN SAUVEGARDE — seules quatre routines "autonomes" font exception à ce mode de fonctionnement (reportez-vous à la section Structure des instructions).
La commande bk_Debut mise a jour miroir déclenche le process de mise à jour du miroir.
L'appel de cette fonction déclenche la fermeture du fichier d'historique courant, qui reçoit l'extension ".4L2" sous Windows et le suffixe ".2" sous MacOS. Un nouveau fichier d'historique est créé.
Si vous utilisez 4D Server, le nouvel historique commence à enregistrer les opérations apportées à la base. L'envoi du fichier d'historique au miroir peut alors avoir lieu sans interférer sur le fonctionnement de la base, puisque le fichier d'historique ".4L2" ou ".2" n'est plus en activité. Cet envoi sera réalisé à l'aide de la fonction bk_Lancer copie.
Une fois l'envoi exécuté et l'historique intégré, les données de la base miroir seront sauvegardées sur le poste miroir, en fonction du nombre de jeux défini dans le projet de sauvegarde.
Note : Pour plus d'informations sur le mécanisme de mise à jour du miroir, reportez-vous au chapitre "Exploitation d'un miroir logique" dans le Guide d'utilisation de 4D Backup.
bk_Debut mise a jour miroir retourne 0 lorsque son exécution est correcte. Dans le cas contraire, un numéro d'erreur est renvoyé (reportez-vous à la liste fournie à l'Annexe A, Codes d'erreurs de 4D Backup).
Nous vous recommandons de tester systématiquement la valeur retournée. En effet, si bk_Debut mise a jour miroir retourne une valeur autre que 0, les instructions suivantes seront toutes ignorées.
Accès à la base durant la mise à jour
Le process de mise à jour d'un miroir logique a pour principale caractéristique de ne pas verrouiller la base de données en mode multiposte : tous les postes clients connectés à 4D Server peuvent travailler en lecture et écriture.
Avec 4e Dimension monoposte, tous les process autres que celui qui a déclenché la mise à jour sont endormis, comme pour une sauvegarde intégrale.
Traitement des transactions
Comme pour la fonction bk_Debut sauvegarde integrale, bk_Debut mise a jour miroir ne s'exécute qu'une fois toutes les transactions en cours closes, et il faut, comme pour la sauvegarde intégrale, vérifier que l'on n'a pas débuté une transaction dans le même process avant d'appeler cette commande.
Si la commande bk_FIN SAUVEGARDE est appelée alors que la mise à jour du miroir n'a pas été réalisée ou qu'elle est en cours, les deux fichiers d'historique seront concaténés afin de revenir à l'état précédent.
Exemple
(1) Voici la méthode la plus simple permettant de déclencher une mise à jour du miroir :
C_ENTIER($vErreur) $vErreur:=bk_Mise a jour miroir
(2) Voici une méthode gérant elle-même le process de mise à jour d'une base miroir :
Si (bk_Debut mise a jour miroir=0) Si (bk_Lancer copie =0) Repeter Jusque (bk_Lire etat #4) Fin de si bk_FIN SAUVEGARDE Fin de si
(3) Vous pouvez affiner la méthode précédente en gérant les éventuelles erreurs :
C_ENTIER($vErreur;$vEtat)
$vErreur:=bk_Debut mise a jour miroir
Si ($vErreur#0)
ALERTE("Impossible de démarrer la mise à jour : erreur N° " +Chaine($vErreur))
Sinon
$vErreur:=bk_Lancer copie
Si ($vErreur#0)
ALERTE("Impossible d'envoyer le fichier d'historique : erreur N° " + Chaine($vErreur))
Sinon
Repeter
$vEtat:=bk_Lire etat
Jusque ($vEtat#4)
Si ($vEtat#5)
ALERTE("Problème durant la copie : erreur N° " + Chaine($vEtat))
Fin de si
Fin de si
bk_FIN SAUVEGARDE
Fin de si
Référence
bk_Debut sauvegarde integrale, bk_FIN SAUVEGARDE.
|
|
|
|
|
|
|
|
|