forum Ancestrologie

Ancestrologie - Développement => Développement => Discussion démarrée par: DDdeBerdeux le 11 Janvier 2006 à 22:29:14

Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 11 Janvier 2006 à 22:29:14
Pour ceux qui veulent essayer cette nouvelle version, j'ai mis en ligne  maj_b357_b4013.exe  (http://andre.langlet.free.fr/ancestro/maj_b357_b4013.exe)un exécutable qui modifie la base en version b4.012 et quelques états, ainsi que FAMILLEVIDE4013.zip  (http://andre.langlet.free.fr/ancestro/FAMILLEVIDE4013.zip) la base vide accompagnée du fichier décrivant toutes las modifications depuis la base b3.57.

Les modifications depuis la b4.010 sont les suivantes:
Citer
Etat statistique des Naissances et décès par pays et départements: ajout cumul sur état, alignement des nombres à droite. PROC_STATISTIQUES regroupement des enregistrements sans département ou pays (chaîne vide ou nulle) et remplacement par libellé "Département inconnu" ou "Pays inconnu". Idem pour PROC_COMPTE_VILLES (informations sur dossier).

Etat de dénombrement d'ascendance ajouté trait de séparation entre consanguinité et implexe.

Modifications pour gestion des implexes dans l'ascendance:

Ajout champ IMPLEXE dans table temporaire TQ_ARBREREDUIT

Modification PROC_ARBRE pour ne pas élimiler l'implexe et mettre dans le champ implexe le sosa de l'ancêtre commun

Idem pour PROC_ARBRE_ECRAN et PROC_ARBRE_EXPORT avec correction dernier métier (était le dernier saisi au lieu du dernier en date).

Modification¨PROC_ARBREREDUIT ajout champ IMPLEXE.

Modifications PROC_ETAT_ASCENDANCE et états d'ascendance compléte pour y faire figurer les implexes.

Correction erreur de calcul de la PROC_CONSANG.

Création d'une procédure PROC_ANC_COMMUNS listant les ancêtres communs à 2 individus, leurs enfants à l'origine des branches distinctes et le nombre de générations permettant d'atteindre les individus dont on cherche les ancêtres communs.

Modifications PROC_DESCENDANCE: suppression du calcul de l'ordre, le code d'Aboville contenu dans la variable SOSA pouvant le remplacer. Utilisation du champ ORDRE pour identifier les enfants implexes avec le même N° d'Aboville que le premier découvert.

Correction dernier métier.

Modifications des états de descendance complète pour y faire figurer les implexes.

Modification PROC_ASCEND_DESCEND pour supprimer les enregistrements implexes générés dans les PROC_ARBRE et PROC_DESCENDANCE.

Correction PROC_TROUVE_UNIONS pour rapidité (éliminer requête sur CLE_FICHE NULL).
Les principales modifications concernent la gestion des implexes.

Mais ATTENTION çà ne marche pas correctement avec la version officielle actuelle v420 du logiciel, ni le plugin les Arbres ni WebExport.

Philippe CM a fait une version béta v433 (en ligne) qui pour le moment ne fait que supprimer les inconvénients de ces individus supplémentaires (implexes) dans les tables, sans encore en profiter dans les arbres standards (ils sont comme avant).

Par contre les implexes apparaissent dans les états d'ascendance et descendance complets.

Le plugin Les Arbres actuel n'est pas perturbé dans les arbres ascendants, mais les individus supplémentaires (enfants implexes parce que leurs 2 parents sont des descendants de l'individu origine), sont mal placés. Une première étape à laquelle PCM travaille sera de les supprimer, avant de les placer correctement dans un second temps.

Pour WebExport, pas de problème pour l'exportation du dossier complet, mais des erreurs lors des exportations limitées à l'ascendance ou la descendance. Yves travaille actuellement pour proposer une version acceptant ces mises à jour, et peut-être en profitant?

Les essais les plus intéressants devraient porter sur des bases ayant un grand nombre de générations et plus de 9 enfants dans certaines familles.

La procédure PROC_ANC_COMMUNS donne parfois des résultats surprenants, mais qui semblent pourtant justes.

N'oubliez pas les sauvegardes avant de modifier. Pour ceux qui ont déjà fait la Maj_Tag_Eve (en 2ième partie de la mise à jour), il n'est pas indispensable de la recommencer.

Bons tests.

André

PS: réédition du 12/01. Yves Bruant vient de faire une version béta 2.2.1.0 de sa dll CrétionWeb, adaptée à cette base modifiée, téléchargeable http://www.ybruant.magic.fr/ess/installe_dllcreationweb.exe

Il serait bon de la tester avec cette base, mais également avec des bases de version précédentes, car Yves essaie de garder une compatibilité avec les anciennes versions.
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: garnierfrancoise le 11 Janvier 2006 à 22:43:12
J'ai téléchargé l'exe de migration

J'ai fait migrer ma base



1) Dans la barre supérieure j'ai toujours b 4.010

2) Si je clique sur Documents dans le panneau latéral gauche j'ai le message

QAscendance : Champ'IMPLEXE' non trouvé
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 11 Janvier 2006 à 22:50:18
Bonsoir,

Citation de: "garnierfrancoise"
J'ai fait migrer ma base



1) Dans la barre supérieure j'ai toujours b 4.010

2) Si je clique sur Documents dans le panneau latéral gauche j'ai le message

QAscendance : Champ'IMPLEXE' non trouvé
C'est que ta base n'a pas "migré". Es-tu sûr d'avoir exécuté maj_b357_b4012.exe, ancestrologie fermé?

tu devrais avoir b4.012 dans le bandeau.

A+

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: garnierfrancoise le 11 Janvier 2006 à 23:10:54
1) J'ai bien exécuté l'outil de migration vers 4.012, Ancestrologie fermé

Le bandeau indique toujours 4.010

2) J'ai rechargé l'outil de migration. Même processus, même résultat dans le bandeau toujours 4.010

En outre quand je lance Ancestrologie j'ai le message bloquant:

internal gds software consistency check (can't continue after bugcheck)



J'ai réinstallé Ancestrologie avec ma base 4.010 et tout va. Suite des essais demain, Morphée m'appelle.



PS: Dernière vérification. Bizarre et qui me laisse perplexe et m'inquiète.

J'ai Ancestrologie 433 avec une base 4.010 (qui avait été sauvegardée et qui n'a donc jamais rencontré l'outil de migration vers 4.012). Et bien j'ai encore le message QAscendance : Champ'IMPLEXE' non trouvé

Ancestrologie fait comme si je devais avoir une base 4.012? La migration agit sur Ancestrologie, pourtant j'ai remis un Ancestrologie.exe que j'avais sauvegarder. Je n'y comprend plus rien.!!!

Si je mets la version d'Ancestrologie 430 Pas de problème

La version 433 attendrai la base 4.012? Mais pas la version 430?
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Ancestrologie le 11 Janvier 2006 à 23:33:59
es tu sur de pointer sur la bonne base ???
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 11 Janvier 2006 à 23:36:07
Il est possible que PCM ait modifié son programme pour aller dans la BDR vérifier une variable VersionBase dans HKCU/Software/Ancestrologie/Settings/

Si çà ne revient pas correctement au 2ième démarrage, il faudra la modifier dans la BDR. Mais çà devrait revenir tout seul.

Je viens de télécharger le fichier de maj sur mon site; c'est bien le même à l'octet près que celui qui fonctionne chez moi. PB de Firebird?

A+

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: garnierfrancoise le 11 Janvier 2006 à 23:43:12
Citation de: "cazaux-moutou philippe"
es tu sur de pointer sur la bonne base ???




Normalement oui car je les ai toutes testées

A demain
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Ancestrologie le 11 Janvier 2006 à 23:50:16
Citer
l est possible que PCM ait modifié son programme pour aller dans la BDR vérifier une variable VersionBase dans




Que nenni, j ai rien modifié
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: garnierfrancoise le 12 Janvier 2006 à 00:32:33
Citation de: "garnierfrancoise"


La version 433 attendrai la base 4.012? Mais pas la version 430?




Cela se confirme

depuis que j'ai lancé une fois la migration vers la base 4.012

(mais ma base apparaissant toujours en 4.010!)

Si j'utilise Ancestrologie version 430 pas de problème

Si j'utilise Ancestrologie version 433 J'ai le message

QAscendance : Champ....



 :roll:



bien qu'étant toujours en base 4.010 je ne peux ouvrir la fenêtre documents avec la 433 alors que je le pouvais avant la tentative de migration. La migration me donne des migraines
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Claude Baudin le 12 Janvier 2006 à 08:35:59
André

Dis nous pourquoi tu laisses noter version b 3.57 alors que tu dis que qu'il faut utiliser la version 4.30 voir 4.33

????  :wink:
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Facon le 12 Janvier 2006 à 09:55:56
Bonjour,



De mon côté j'étais en v420 b4.010.



Ancestrologie arrêté:

1-j'ai mis en place Ancestrologie v433 + la clef,

2-j'ai mis l'outil de migration d'André (màj_b357_b4012) dans le répertoire Ancestrologie,

3-j'ai lancé la màj: premier stade màj de base, second stade màj des tags (ce qui était déjà fait sur la base existante),

4-J'ai lancé Ancestrologie sans problème et le bandeau supérieur indique bien v433 b4.012.



Il me reste plus qu'à examiner la suite.



Il paraît évident que si l'utilisateur utilise plusieurs bases chaque base doit faire l'objet d'une migration.
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 12 Janvier 2006 à 10:33:06
Citation de: "Claude Baudin"
André

Dis nous pourquoi tu laisses noter version b 3.57 alors que tu dis que qu'il faut utiliser la version 4.30 voir 4.33

????  :wink:
Faudrait voir à pas mélanger les versions de la base avec celles du logiciel.

C'est pour celà que je m'applique à toujours mettre le "b" devant quand je parle de la base et "v" pour le logiciel.

Le fichier de mise à jour de la base, je l'appelle maj_b357_b4012.exe, parce qu'il est capable de remonter le niveau de la base de b3.57, (ou plus) , jusqu'au niveau b4.012.

J'aurai peut-être dû modifier le texte qui apparaît lors de la maj pour préciser qu'elle ne fonctionne correctement qu'à partir de v433.

A+

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 12 Janvier 2006 à 10:42:48
Citation de: "garnierfrancoise"
Citation de: "garnierfrancoise"
La migration me donne des migraines
Et des insomnies, j'en suis désolé.

C'est vrai que PCM a fait cette v433 spécialement pour la b4.012, mais j'ignore si elle pose des pb avec les versions précédentes de la base. Cà peut devenir complexe de gérer plusieures versions de la base avec le même logiciel.

A+

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 12 Janvier 2006 à 14:20:23
Yves Bruant vient de faire une version béta 2.2.1.0 de la dll Création Web, dont je donne le lien pour téléchargement dans le premier message de ce fil.

Ce serait bien de lui confirmer le bon fonctionnement (et éventuellement les anomalies) avec cette version de la base et les précédentes.

Chez moi c'est bon, mais qu'en est-il sur des grosses bases et les familles nombreuses?

A+

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: garnierfrancoise le 12 Janvier 2006 à 16:04:18
Pour André, Philippe ...  les autres.

Après une nuit de repos et une journée de travail. Mon problème est résolu et je pense en connaitre la raison.

Lors de la migration; par impatience?, j'avais fermé la fenêtre en noir (de type DOS des années 80) avant qu'elle ne se ferme d'elle-même; j'avais dù interrompre le processus de migration :oops:
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 12 Janvier 2006 à 16:12:26
Sûrement

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: garnierfrancoise le 12 Janvier 2006 à 16:23:24
Merci;  que mon erreur serve aux impatients.



Et merci encore à André (rigoureux et perfectioniste, qualités qui se perdent) qui sans faire de bruit travaille à la base, ce qui améliore les statistiques; que se soit dans la "Fenêtre Informations", dans les "Documents" ou encore dans le module statistique.
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Tophe3860 le 12 Janvier 2006 à 19:11:18
Citation de: "garnierfrancoise"
Et merci encore à André (rigoureux et perfectioniste, qualités qui se perdent) qui sans faire de bruit travaille à la base
Je m'associe bien sincèrement aux lauriers que tu as tressés à destination d'André...  :wink:
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 12 Janvier 2006 à 20:51:59
Arrêtez, j'ai les chevilles qui gonflent...

J'ai remodifié les PROC_ETAT_ASCENDANCE, PROC_ETAT_DESCENDANCE et PROC_ETAT_DESCENDANCE_PATRONYME (non celui-là je n'y avais pas encore touché), suite au bug que Joël Auguste a contribué à découvrir avec ses individus sans prénoms. Pour les programmeurs il faudra se souvenir que  chaîne||NULL = NULL.

Les fichiers en téléchargement sont mis à jour.

A+

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 15 Janvier 2006 à 18:48:25
Probablement dernières modifications donc passage en b4.013 avant officialisation sur le site.

Les états de fiche individuelle et fiche familiale, souffraient du même bug qui faisait disparaître le nom si le prénom était NULL. C'est réparé par la maj des PRO_ETAT_FICHE et PROC_ETAT_FICHE_FAMILIALE.

Suite au problème de retard de la mise à jour des détails du dossier signalé par Gvx, PCM modifie son exécutable pour transmettre le N° de dossier à la PRO_COMPTE_VILLES qui est donc modifiée en conséquence.

Donc ce point ne fonctionnera correctement qu'avec un exe v411 ou plus. PS: lire v441

Comme dans la procédure de mise à jour de la base, certains impatients avaient tendance à fermer la fenêtre en mode commande qui s'ouvrait temporairement, on a décidé de la cacher. J'espère que ce ne sera pas plus perturbant pour les utilisateurs.

Les liens du premier message de ce fil ont été mis à jour.

Dites nous assez rapidement si quelque chose ne va pas, avant que PCM n'officialise. Merci.

Bons tests.

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: garnierfrancoise le 15 Janvier 2006 à 19:08:19
Citation de: "DDdeberdeux"


Comme dans la procédure de mise à jour de la base, certains impatients avaient tendance à fermer la fenêtre en mode commande qui s'ouvrait temporairement, on a décidé de la cacher. J'espère que ce ne sera pas plus perturbant pour les utilisateurs.





Merci pour les impatients; j'avais envisagé de te demander de supprimer son affichage mais comme je suis timide je n'ai pas osé.



Test: pas de Pb à signaler



Cordialement
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Joël AUGUSTE le 15 Janvier 2006 à 19:55:13
Citation de: "DDdeberdeux"
Probablement dernières modifications donc passage en b4.013 avant officialisation sur le site.

...........

Dites nous assez rapidement si quelque chose ne va pas, avant que PCM n'officialise. Merci.
Bonsoir



Je viens de passer en b4.013 (je suis en v440). Lorsque je fais Mes généalogies / Informations / Villes Détail, j'ai une erreur qui s'inscrit sur un pavé : "Dynamic SQL Error Parameter mistmatch for procedure PRO_COMPTE_VILLES" après validation sur OK, le tableau s'affiche, mais il est vierge et dans le cadre du haut (où il y  a normalement la liste des pays), il y a inscrit : <Aucune information à afficher>.

Cette erreur persiste même après optimalisation, fermeture et réouverture d'Ancestrologie. Je n'avais pas cette erreur en v440 b4.012



A+

Joël
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 15 Janvier 2006 à 20:05:03
J'ai fait une petite erreur dans mon message précédent. Il faut la version v441 (et non v411) pour que ce nouveau paramètre soit pris en charge par le logiciel.

A+

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: jdelettrez le 15 Janvier 2006 à 22:31:32
Passage en b4013 et v441



2388 individus



Test documents ascendants et descendants OK

Stat  dénombrements ok

export web ok

consanguinité ok

optimisation Ok

arbre Ok sans approfondir



bonsoir



Merci pour les évolutions => base plus rapide
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Joël AUGUSTE le 16 Janvier 2006 à 10:32:55
Bonjour,



Je suis passé en v441 b4.013

Aucun problème d'affichage constaté (sauf la remarque que j'avais faite sur l'élargissement de la fenêtre conjoints/enfants de l'onglet Identité, mais le rappel posté hier soir a sûrement eu lieu après la mise en ligne par PCM).

Dans  Mes généalogies / Informations / Villes Détail, l'affichage est désormais correct.

Pour le calcul de consanguinité, dans mon dossier de généalogie familiale, l'affichage pour le calcul sur un Sosa s'effectue en 1 seconde, pour tout le dossier en 7 secondes (j'ai 2324 individus).

Pas d'amélioration avec les dynasties européennes. Il doit certainement y avoir d'autres boucles...

Tout ça c'est vraiment du beau travail et c'est réellement plaisant de voir un logiciel évoluer en permanence.



Cordialement



Joël
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Facon le 16 Janvier 2006 à 13:18:30
Bonjour,

J'arrive un peu après la bataille et j'ai implémenté progressivement les diverses modifications apportées à Ancestrologie.



Je n'ai rencontré aucune difficulté dans les mises à jour successives et je pense que c'est un bon choix de ne plus laisser apparaître la fenêtre de mise à jour de la base et des tags.



Via la version v433, etc et finalement la v441 Ancestrologie a retrouvé toute sa vélocité et il n'y a pratiquement plus d'attente pour le passage d'une fiche à l'autre y compris au travers du répertoire.



Le réglage des fenêtres est aussi une bonne chose et permet une adaptation facile pour chacun.



J'ai essayé les diverses fonctionnalités (pas toutes) et je n'ai pas rencontré de loup. Le seul point qui a été signalé par ailleurs est l'accès aux individus dans la liste des lieux favoris. Le seul accès possible semble être celui par le bandeau du haut: Lieux/Liste des lieux favoris. Les autres chemins par le haut: Lieux/Liste des lieux/Liste des Lieux favoris ou par le menu de gauche: Divers/Liste des Lieux/Liste des Lieux favoris ne donnent pas accès aux individus.

J'ai cru comprendre que Philippe avait apporté le remède mais j'ignore si la nouvelle version est accessible.



Autre constation que je considère comme sans importance et non liée à v441, c'est la Liste des villes en doublons dans la base (Bandeau du haut: Lieux/ Listes des villes....). La requète montre une grande quantité de villes en doublons alors que la recherche est effectuée sur code Insee, cp et pays. Les doublons ont en fait un cp différent, j'en déduis que ce ne sont pas de réels doublons. La liste devrait pratiquement être vide.



Pour le coup c'est une bonne màj, merci Philippe.



Il faudra se pencher un jour sur la sauvegarde automatique du type Money comme indiqué il y a quelques temps. De cette manière, au premier lancement l'utilisateur serait interrogé sur la nécessité de faire une sauvegarde, avec quelle fréquence et sous quel nom. Ce dernier point est important car je pense que de nombreux utilisateurs conservent le nom de Ancestrologie.bdd. Cette base est écrasée à l'occasion d'une nouvelle installation et alors si les sauvegardes n'existent pas.......
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: DDdeBerdeux le 16 Janvier 2006 à 14:55:54
Je m'étais fait la même remarque que Joël concernant, l'affichage des noms tronqués, qui ne s'améliore pas quand on élargie la zone d'affichage. Mais j'ai peur qu'il ne soit pas si simple de résoudre ce problème. Dans les champs où ce système fonctionne, on voit apparaître l'extrémité de la chaîne qui était cachée, non une partie centrale... Ou il faudrait que PCM affiche 2 champs au lieu d'un seul, le MonPrenom et les Dates, l'élargissement de la zone profitant à NomPrenom.

Pour les boucles, la procédure PROC_REF_CIRC dont le script figure dans un autre fil fonctionne correctement sur les petites bases que j'ai essayées, mais pas sur la grosse base de Joël. Elle plante également sur cette base. C'est la raison pour laquelle je ne l'ai pas incorporée dans b4.013. Pourtant les différents incidents signalés, tous sur des grosses bases, lors du calcul de consanguinité, sont symptomatiques de boucles dans les bases. Il serait intéressant que Joël nous dise les raisons et la forme de ces boucles quand il les aura trouvées, pour qu'on puisse mettre au point une procédure permettant de les détecter rapidement.

En attendant, il est préférable de faire une sauvegarde avant de lancer un calcul de consanguinité. Pour la sauvegarde automatique, je crois avoir déjà répondu que je n'en étais pas un chaud partisan. Cà marche très bien sur les serveurs pendant une période d'inactivité relative, mais sur une base de données en utilisation (ce qui peut arriver si la sauvegarde est automatique), elle doit se faire par l'intermédiaire des utilitaires de la base (gback) et je pense nécessite FireBird en version serveur. La sauvegarde "backup" qui est faite au lancement d'Ancestrologie si "Sauvegarde automatique" est coché, et la sauvegarde "copie" faîte depuis le menu sont exécutées lorsque la base n'est pas active, aucune transaction n'est en cours.

Je préfèrerai un accès plus rapide et plus pratique à la sauvegarde simple amélioration de la sauvegarde actuelle, où il n'yaurait pas besoin de respécifier que l'on veut inclure la date dans le nom (ce devrait l'être par défaut), ni l'emplacement (il est déjà défini dans les préférences).

Quand à la sauvegarde "backup" de début, elle n'aurait un intérêt que si on pouvait spécifier un emplacement différent (par les préférences) si possible sur une partition ou un disque différent de celui de la base, et si son nom s'incrémentait à chaque sauvegarde. Son format .gbk qui comprime légèrement la base, n' a que peu d'intérêt pour nos bases relativement petites, son seul intérêt étant l'optimisation lors de la restauration (ce que fait la fonction "Optimisation de la base").

Pour le fichier "ancestrologie.bdd" écrasé lors de l'installation complète, il faudrait voir si ce problème ne pourrait pas être simplement résolu par cette procédure, en demandant à l'utilisateur de donner un autre nom par exemple si ce fichier existe.

A+

André
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: guillaume simonnet le 16 Janvier 2006 à 15:12:34
Citation de: "DDdeberdeux"
Pour le fichier "ancestrologie.bdd" écrasé lors de l'installation complète, il faudrait voir si ce problème ne pourrait pas être simplement résolu par cette procédure, en demandant à l'utilisateur de donner un autre nom par exemple si ce fichier existe.


excellent idee, cela permettrait d'eviter un certain nombre de catastrophes pour des utilisateurs non habitues a ancestro et/ou pas tres doues en informatique  8)
Titre: Base (b4.012)=>b4.013 à tester.[terminé]
Posté par: Facon le 16 Janvier 2006 à 15:30:55
Bonjour, bonjour André,

Je me suis mal fait comprendre. Je ne parle pas de sauvegarde à chaud durant l'utilisation du logiciel mais uniquement en fin d'utilisation avant de quitter l'application.

L'action de vouloir quitter Ancestro passerait par un message qui serait du type: "Vous n'avez pas fait de sauvegarde depuis x jours, souhaitez-vous faire une sauvegarde maintenant" avec option oui/non. Oui déclenche la sauvegarde suivie de l'arrêt de l'application, non déclenche l'arrêt immédiat.



A la première installation ou à la création d'une nouvelle base, le message serait du type: Souhaitez-vous faire une sauvegarde lorsque vous quittez l'application oui/non, si oui: nom de la base, localisation, périodicité. Une partie existe déjà dans le menu préférences. La description plus détaillée doit pouvoir être reprise directement sur l'exemple cité.



Autre remarque, la troisième ligne du menu Configuration/Préférences g.../Divers semble être plutôt un back-up automatique, il peut y avoir confusion avec la définition du répertoire pour la sauvegarde dans l'onglet Répertoires. Le candidat lambda se sent tranquille s'il a coché l'option Sauvegarde automatique de la base de données, il a en réalité un backup dans Ancestrologie/database/Backup. Si la base de travail se nomme toujours Ancestrologie il en sera de même pour le backup et même problème à la réinstallation d'où la bonne précaution de renommer la base personnelle sous un autre nom qu'Ancestrologie.



Enfin, le module Répertoire pour la sauvegarde souffre de quelques petites anomalies mentionnées par tes soins.