forum Ancestrologie

Ancestrologie - Développement => Développement => Discussion démarrée par: Gvx le 14 Septembre 2005 à 22:49:03

Titre: Corrections et améliorations des procedures stockées
Posté par: Gvx le 14 Septembre 2005 à 22:49:03
Bonsoir,



J'ouvre ce fil, afin de pouvoir regrouper les diffrentes propositions d'améliorations consernant les procedures stockées dans la base.



Ceci devrait facilité le travail de PCM lors d'une prochaine mise a jour.



Car  actuellement on trouve des propositions dans divers fils
Titre: Corrections et améliorations des procedures stockées
Posté par: Gvx le 14 Septembre 2005 à 22:58:04
Voici ma premiere proposition d'amélioration



Procedure: PROC_ORPHELINS



Correction: Dans la version actuelle les individus uniquements associés a des evenements (n'étant ni dans l'ascendance, ni dans la descendance) sont reconnus comme orphelin. Ceci risque d'amener a supprimer l'individu par erreur. Je propose donc de corriger cette anomalie



Il faut modifier la clause Where de la façon suivante: (ajout de la dernière ligne)

   WHERE KLE_DOSSIER = :IDOSSIER and

          CLE_PERE IS NULL and

          CLE_MERE IS NULL And

          CLE_FICHE not in (select cle_pere from individu) and

          CLE_FICHE not in (select cle_mere from individu) and

          CLE_FICHE not in (select union_mari from T_UNION) and

          CLE_FICHE not in (select union_femme from T_UNION) and

          CLE_FICHE not in (select assoc_kle_associe from  t_associations)

Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 14 Septembre 2005 à 23:16:29
Bonne idée.

Message modifié, voir le 17/9
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 14 Septembre 2005 à 23:21:31
Dans http://www.ancestrologie.org/forum/index.php?topic=4630.0 une proposition pour supprimer l'erreur "multiple rows in singleton select" lors de l'exportation de toutes les images.

A+

André
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 17 Septembre 2005 à 10:27:37
Dans http://www.ybruant.magic.fr/phpBB2a/viewtopic.php?p=30983#30983 je signale que le double affichage des unions dans la fiche individus doit être dû à la procédure PROC_TROUVE_UNION, qui renvoie un enregistrement par evènement "MARR" de l'union. Dans cette utilisation, l'année du mariage n'est utile que pour ordonner les conjoints dans un ordre chronologique. Je propose que l'ordre ne soit pas défini par l'année du mariage, mais par la date du premier évènement familial, ce qui assure un seul enregistrement retourné par union. Si cette procédure n'est pas utilisée ailleurs où les modifications pourraient gêner (mes essais n'ont pas révélés de problèmes), la nouvelle version pourrait être:



DECLARE VARIABLE DATE_UNION DATE;

BEGIN

    FOR

    SELECT  i.CLE_FICHE,

            i.NOM,

            i.PRENOM,

            i.DATE_NAISSANCE,

            i.ANNEE_NAISSANCE,

            i.DATE_DECES,

            i.ANNEE_DECES,

            i.SEXE,

            i.CLE_PERE,

            i.CLE_MERE,

            i.NUM_SOSA ,

            u.union_type,

            u.union_clef ,

            MIN(ef.EV_FAM_DATE_YEAR),

            MIN(ef.EV_FAM_DATE)

      FROM  t_union u

            INNER JOIN individu i

               ON  (u.union_mari = :I_CLEF and i.cle_fiche = u.union_femme) OR

                   (u.union_femme = :I_CLEF and i.cle_fiche = u.union_mari)

            LEFT join evenements_fam ef

               on (ef.ev_fam_kle_famille = u.union_clef)

      GROUP BY  i.CLE_FICHE,

            i.NOM,

            i.PRENOM,

            i.DATE_NAISSANCE,

            i.ANNEE_NAISSANCE,

            i.DATE_DECES,

            i.ANNEE_DECES,

            i.SEXE,

            i.CLE_PERE,

            i.CLE_MERE,

            i.NUM_SOSA ,

            u.union_type,

            u.union_clef

      ORDER BY MIN(ef.EV_FAM_DATE_YEAR),MIN(ef.EV_FAM_DATE)

    INTO :CLE_FICHE,

         :NOM,

         :PRENOM,

         :DATE_NAISSANCE,

         :ANNEE_NAISSANCE,

         :DATE_DECES,

         :ANNEE_DECES,

         :SEXE,

         :CLE_PERE,

         :CLE_MERE,

         :NUM_SOSA,

         :TYPE_UNION,

         :UNION_CLEF,

         :ANNEE_MARIAGE,

         :DATE_UNION

    DO

       SUSPEND;

END


en attendant de trouver mieux (ordre chronologique défini par le premier évènement familial ou la première naissance d'un enfant du couple).

Les conjoints apparaissent dans l'ordre chronologique, le premier en tête. S'il n'y a pas d'évènement familial enregistré, le conjoint apparaît en dernier.

André

PS: réédition le 23/09/2005 pour prendre en compte la date exacte si elle existe au lieu de l'année seule, dans la définition de l'ordre chronologique.
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 20 Septembre 2005 à 23:02:48
Dans l'onglet "Actes" de la fiche individu, les actes pour évènements familiaux apparaissent dans la fiche du mari, mais pas dans celle de la femme. Pour corriger celà, 3 procédures stockées sont à modifier pour que la jointure avec la table T_UNION fonctionne avec les 2 conjoints.

La procédure PROC_ACTES_A_TROUVER_FAMILLESBEGIN

  FOR

        select  Fam.ev_fam_clef,

                Fam.ev_fam_type,

                Ref.ref_eve_lib_long,

                Fam.ev_fam_date_writen,

                Fam.ev_fam_cp,

                Fam.ev_fam_ville,

                Fam.ev_fam_acte,

                'F'

        FROM    ref_evenements Ref,

                evenements_fam Fam,

                T_UNION Marriage,

                individu indi

        WHERE   indi.CLE_FICHE = :I_INDI AND

                Marriage.UNION_CLEF = Fam.EV_FAM_KLE_FAMILLE AND

                (Marriage.UNION_MARI = indi.CLE_FICHE OR

                 Marriage.UNION_FEMME = indi.CLE_FICHE) AND

                Fam.ev_fam_type = Ref.ref_eve_lib_court and

                Ref.ref_eve_visible = 1 AND

                (Fam.ev_fam_acte = 0 OR Fam.ev_fam_acte is null)

    INTO

      :EVE_CLEF,

      :EVE_TYPE,

      :EVE_LIB_LONG,

      :EVE_DATE_WRITEN,

      :EVE_CP,

      :EVE_VILLE,

      :EVE_ACTE,

      :EVE_TABLE

  DO

  BEGIN

    SUSPEND;

  END

END
La procédure PROC_ACTES_DEJA_TROUVESBEGIN

  FOR

        select  Media.MP_MEDIA,

                Fam.ev_fam_clef,

                Fam.ev_fam_type,

                Ref.ref_eve_lib_long,

                Fam.ev_fam_date_writen,

                Fam.ev_fam_cp,

                Fam.ev_fam_ville,

                Fam.ev_fam_acte,

                'F'

        FROM    ref_evenements Ref,

                evenements_fam Fam

                LEFT JOIN MEDIA_POINTEURS Media

                    ON (Media.MP_POINTE_SUR = fam.ev_fam_clef AND

                        Media.MP_TABLE =  'F' AND Media.MP_TYPE_IMAGE='A'),

                T_UNION Marriage,

                individu indi

        WHERE   indi.CLE_FICHE = :I_INDI AND

                Marriage.UNION_CLEF = Fam.EV_FAM_KLE_FAMILLE AND

                (Marriage.UNION_MARI = indi.CLE_FICHE OR

                 Marriage.UNION_FEMME = indi.CLE_FICHE) AND

                Fam.ev_fam_type = Ref.ref_eve_lib_court AND

                Ref.ref_eve_visible = 1 AND

                Fam.ev_fam_acte = 1

        UNION

        select  Media.MP_MEDIA,

                eve.ev_ind_clef,

                eve.ev_ind_type,

                ref_eve_lib_long,

                eve.ev_ind_date_writen,

                eve.ev_ind_cp,

                eve.ev_ind_ville,

                eve.ev_ind_acte,

                'I'

        from    evenements_ind eve

                LEFT JOIN MEDIA_POINTEURS Media

                    ON (Media.MP_POINTE_SUR = eve.ev_ind_clef AND

                        Media.MP_TABLE = 'I' AND Media.MP_TYPE_IMAGE='A'),

                ref_evenements ref

        where   eve.ev_ind_kle_fiche = :I_INDI AND

                eve.ev_ind_type = ref_eve_lib_court AND

                ref_eve_visible = 1  AND

                eve.ev_ind_acte = 1

    INTO

      :EVE_IMAGE,

      :EVE_CLEF,

      :EVE_TYPE,

      :EVE_LIB_LONG,

      :EVE_DATE_WRITEN,

      :EVE_CP,

      :EVE_VILLE,

      :EVE_ACTE,

      :EVE_TABLE

       /*   if (:EVE_IMAGE > 0) then EVE_IMAGE = 1;*/

  DO

  BEGIN

    SUSPEND;

  END

END
La procédure PROC_ACTES_RAZ doit être rectifiée pour remettre à 0 le champ EV_FAM_ACTE quelque soit le conjoint:declare variable I_CLEF INTEGER;

BEGIN

    DELETE FROM media_pointeurs

       WHERE MP_CLE_INDIVIDU = :INDI AND

             MP_TYPE_IMAGE = 'A';

    UPDATE  multimedia

    SET     MULTI_NUM_ACTE = NULL,

            MULTI_TYPE_ACTE = NULL

    WHERE   MULTI_INDIVIDU = :INDI;

    UPDATE EVENEMENTS_IND

         SET EV_IND_ACTE = 0

    WHERE EV_IND_KLE_FICHE = :INDI;

    FOR

     SELECT EV_FAM_CLEF

        FROM    evenements_fam Fam,

                T_UNION Marriage,

                individu indi

        WHERE   indi.CLE_FICHE = :INDI AND

                Marriage.UNION_CLEF = Fam.EV_FAM_KLE_FAMILLE AND

                (Marriage.UNION_MARI = indi.CLE_FICHE OR

                 Marriage.UNION_FEMME = indi.CLE_FICHE) AND

                Fam.ev_fam_acte > 0

        INTO :I_CLEF

    DO BEGIN

       UPDATE evenements_fam SET EV_FAM_ACTE = 0

       WHERE EV_FAM_CLEF = :I_CLEF;

    END

  SUSPEND;

END


Il reste une anomalie. Si un média est lié à l'acte, une icône apparaît en début de ligne de l'acte trouvé, mais le média n'est visible dans l'onglet "Médias", que dans la fiche du conjoint depuis lequel on a créé le lien acte familial-média. La solution reste à trouver.

Autre anomalie, le point vert ne s'affiche pas sur l'onglet (sauf si des médias sont liés à l'individu depuis l'onglet "Medias").

André



Réédition du 22/05 pour modifications à la procédure PROC_ACTES_DEJA_TROUVES, ajout de  AND Media.MP_TYPE_IMAGE='A' dans la jointure avec la table MEDIA_POINTEUR pour corriger une erreur qui pouvait faire apparaître l'icône "image jointe" en début de ligne alors qu'aucune image n'est jointe, ou la ligne de l'acte trouvé en double.
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 02 Octobre 2005 à 00:44:11
N'ayant pas eu de réponse à mon message http://www.ancestrologie.org/forum/index.php?topic=4704.0 sur le forum anomalies, j'ai continué à chercher comment rendre plus utilisables les médias dans Ancestrologie. Je pense avoir trouvé une solution qui demande la création de 6 triggers dans des tables de la base. Ils améliorent les points suivants:

Bon enregistrement des medias depuis les sources des évènements individuels et familiaux;

Visibilité des médias enregistrés par les sources et par les actes depuis l'onglet Médias de la fiche pour les femmes comme pour les hommes;

Suppression du rattachement des médias liés par les sources ou l'acte d'un évènement, lors de la suppression de cet évènement (individuel ou familial).

Il reste des problèmes qui ne peuvent être règlés que par le code du programme ancestrologie.exe,

non récupération des liens des médias avec les actes ou les sources, perte des "mémos" des médias lors d'un transfert par gedcom (si la norme le permet),

pas d'apparition du point vert sur l'onglet Médias s'il n'y a que des médias liés par les actes ou les sources...

J'ai intégré toutes les modifications vues dans ce fil dans une base vide (avec quelques autres). Si quelques uns sont intéressés pour l'essayer (et en attendant que ces modifications ou d'autres soient intégrées dans une version officielle), ils peuvent me passer leurs coordonnées par MP; je leur enverrai le lien pour la télécharger ainsi que la liste des modifications.



Voici le code permettant de créer les 6 nouveaux triggers:

SET TERM ^ ;





CREATE TRIGGER "TAI_EVENEMENTS_FAM" FOR "EVENEMENTS_FAM"

ACTIVE AFTER INSERT POSITION 0

as

/* Création par André pour fonctionnement média (01/10/05)

   Le doublement de l'enregistrement dans MEDIA_POINTEURS

   pour le conjoint ne fonctionne pas si l'enregistrement

   de l'évènement familial dans SOURCES_RECORD n'existe pas.

   Ne sera plus nécessaire le jour où le programme créera

   l'enregistrement dans SOURCES_RECORD avant celui dans

   MEDIA_POINTEURS*/

DECLARE VARIABLE COMPTE INTEGER;

BEGIN

  SELECT COUNT(ID)

    FROM SOURCES_RECORD

    WHERE TYPE_TABLE = 'F' AND

          DATA_ID = NEW.EV_FAM_CLEF

    INTO :COMPTE;

  IF (COMPTE = 0) then

    BEGIN

      INSERT INTO SOURCES_RECORD (ID,

                                  DATA_ID,

                                  CHANGE_DATE,

                                  KLE_DOSSIER,

                                  TYPE_TABLE)

                          VALUES (GEN_ID(SOURCES_RECORD_ID_GEN, 1),

                                  NEW.EV_FAM_CLEF,

                                  'NOW',

                                  NEW.EV_FAM_KLE_DOSSIER,

                                  'F');

    END

END

 ^



CREATE TRIGGER "TBD_EVENEMENTS_FAM" FOR "EVENEMENTS_FAM"

ACTIVE BEFORE DELETE POSITION 0

as

/* Création par André pour fonctionnement média (01/10/05)

   Suppression des enregistrements dans SOURCES_RECORD et

   dans MEDIA_POINTEURS si l'enregistrement disparaît.

   24/10/05 ajout maj table T_ASSOCIATIONS  */

BEGIN

  DELETE FROM SOURCES_RECORD

    WHERE DATA_ID = OLD.EV_FAM_CLEF AND

          TYPE_TABLE = 'F' ;

  DELETE FROM MEDIA_POINTEURS

    WHERE MP_POINTE_SUR = OLD.EV_FAM_CLEF AND

          MP_TYPE_IMAGE = 'A' AND

          MP_TABLE = 'F' ;

  DELETE FROM T_ASSOCIATIONS

    WHERE ASSOC_EVENEMENT = OLD.EV_FAM_CLEF AND

          ASSOC_TABLE = 'U' ;

END

 ^



CREATE TRIGGER "TBD_EVENEMENTS_IND" FOR "EVENEMENTS_IND"

ACTIVE BEFORE DELETE POSITION 0

as

/* Création par André pour fonctionnement média (01/10/05)

   Suppression des enregistrements dans SOURCES_RECORD et

   dans MEDIA_POINTEURS si l'enregistrement disparaît.

   24/10/05 ajout maj table T_ASSOCIATIONS */

BEGIN

  DELETE FROM SOURCES_RECORD

    WHERE DATA_ID = OLD.EV_IND_CLEF AND

          TYPE_TABLE = 'I' ;

  DELETE FROM MEDIA_POINTEURS

    WHERE MP_POINTE_SUR = OLD.EV_IND_CLEF AND

          MP_TYPE_IMAGE = 'A' AND

          MP_TABLE = 'I' ;

  DELETE FROM T_ASSOCIATIONS

    WHERE ASSOC_EVENEMENT = OLD.EV_IND_CLEF AND

          ASSOC_TABLE = 'I' ;

END

 ^



CREATE TRIGGER "TAI_MEDIA_POINTEURS" FOR "MEDIA_POINTEURS"

ACTIVE AFTER INSERT POSITION 0

as

/* Création par André pour fonctionnement média(01/10/05)

   Double l'enregistrement pour le conjoint

   s'il est lié à un évènement familial */

DECLARE VARIABLE TTABLE char(1);

DECLARE VARIABLE DID INTEGER;

DECLARE VARIABLE MARI INTEGER;

DECLARE VARIABLE FEMME INTEGER;

DECLARE VARIABLE CONJOINT INTEGER;

DECLARE VARIABLE COMPTE INTEGER;

BEGIN

 TTABLE='I';

 IF (NEW.MP_TYPE_IMAGE = 'F') THEN  /* Déclaration par les sources */

   BEGIN                            /* Nécessite l'existence dans  */

     SELECT TYPE_TABLE,             /* SOURCES_RECORD              */

            DATA_ID

     FROM SOURCES_RECORD

     WHERE SOURCES_RECORD.ID = NEW.MP_POINTE_SUR

     INTO :TTABLE,

          :DID ;

   END

 ELSE

   IF ((NEW.MP_TYPE_IMAGE = 'A') AND (NEW.MP_TABLE = 'F')) THEN

     BEGIN

       TTABLE = 'F';

       DID = NEW.MP_POINTE_SUR;

     END

 IF (TTABLE = 'F') THEN

   BEGIN

     DELETE FROM MEDIA_POINTEURS  /* Supprime les doublons qui pourraient être

     créés par les 2 conjoints lors de la récupération d'un gedcom, on ne

     garde que les derniers*/

       WHERE MP_CLEF <> NEW.MP_CLEF AND

             MP_MEDIA = NEW.MP_MEDIA AND

             MP_CLE_INDIVIDU = NEW.MP_CLE_INDIVIDU AND

             MP_POINTE_SUR = NEW.MP_POINTE_SUR AND

             MP_TABLE = NEW.MP_TABLE AND

             MP_IDENTITE = NEW.MP_IDENTITE AND

             MP_KLE_DOSSIER = NEW.MP_KLE_DOSSIER AND

             MP_TYPE_IMAGE = NEW.MP_TYPE_IMAGE ;

     SELECT COUNT(MP_CLEF)

     FROM MEDIA_POINTEURS

     WHERE MP_MEDIA = NEW.MP_MEDIA AND

           MP_POINTE_SUR = NEW.MP_POINTE_SUR AND

           MP_TABLE = NEW.MP_TABLE AND

           MP_KLE_DOSSIER = NEW.MP_KLE_DOSSIER AND

           MP_TYPE_IMAGE = NEW.MP_TYPE_IMAGE

     INTO  :COMPTE;

     IF (COMPTE > 1) THEN EXIT; /* enregistrement déjà créé pour conjoint*/

     SELECT U.UNION_MARI,

            U.UNION_FEMME

     FROM EVENEMENTS_FAM EV, T_UNION U

     WHERE EV.EV_FAM_CLEF = :DID

           AND U.UNION_CLEF = EV.EV_FAM_KLE_FAMILLE

     INTO :MARI,

          :FEMME;

     IF (NEW.MP_CLE_INDIVIDU = MARI)

       THEN CONJOINT = FEMME;

       ELSE IF (NEW.MP_CLE_INDIVIDU = FEMME)

              THEN CONJOINT = MARI;

              ELSE EXIT;  /* Union "orpheline" */

     INSERT INTO MEDIA_POINTEURS (MP_CLEF,

                                  MP_MEDIA,

                                  MP_CLE_INDIVIDU,

                                  MP_POINTE_SUR,

                                  MP_TABLE,

                                  MP_IDENTITE,

                                  MP_KLE_DOSSIER,

                                  MP_TYPE_IMAGE)

                           VALUES(GEN_ID(BIBLIO_POINTEURS_ID_GEN, 1),

                                  NEW.MP_MEDIA,

                                  :CONJOINT,

                                  NEW.MP_POINTE_SUR,

                                  NEW.MP_TABLE,

                                  0,

                                  NEW.MP_KLE_DOSSIER,

                                  NEW.MP_TYPE_IMAGE);

   END

END

 ^



CREATE TRIGGER "TAD_MEDIA_POINTEURS" FOR "MEDIA_POINTEURS"

ACTIVE AFTER DELETE POSITION 0

as

/* Création par André pour fonctionnement média (01/10/05)

   Suppression de l'enregistrement pour le conjoint

   s'il est lié à un évènement familial */

DECLARE VARIABLE TTABLE char(1);

BEGIN

 TTABLE='I';

 IF (OLD.MP_TYPE_IMAGE = 'F') THEN

     SELECT TYPE_TABLE

     FROM SOURCES_RECORD

     WHERE SOURCES_RECORD.ID = OLD.MP_POINTE_SUR

     INTO :TTABLE;

 ELSE

   IF ((OLD.MP_TYPE_IMAGE = 'A') AND (OLD.MP_TABLE = 'F')) THEN

       TTABLE = 'F';

 IF (TTABLE = 'F') THEN

     DELETE FROM MEDIA_POINTEURS

       WHERE MP_MEDIA = OLD.MP_MEDIA AND

             MP_POINTE_SUR = OLD.MP_POINTE_SUR AND

             MP_TABLE = OLD.MP_TABLE AND

             MP_KLE_DOSSIER = OLD.MP_KLE_DOSSIER AND

             MP_TYPE_IMAGE = OLD.MP_TYPE_IMAGE ;

END

 ^



CREATE TRIGGER "TBD_SOURCES_RECORD" FOR "SOURCES_RECORD"

ACTIVE BEFORE DELETE POSITION 0

as

/* Création par André pour fonctionnement média (01/10/05)

   Suppression des enregistrements de MEDIA_POINTEURS

   liés à cet enregistrement */

BEGIN

  DELETE FROM MEDIA_POINTEURS

    WHERE MP_TYPE_IMAGE = 'F' AND

          MP_POINTE_SUR = OLD.ID ;

END

 ^



COMMIT WORK ^

SET TERM ;^



A+

André



Réédition le 24/10/2005 pour modifier TBD_EVENEMENTS_IND et TBD_EVENEMENTS_FAM, afin que la suppression d'un évènement mette à jour la table des associations T_ASSOCIATIONS, supprimant ainsi des incoérences de la base.
Titre: Corrections et améliorations des procedures stockées
Posté par: Gvx le 19 Octobre 2005 à 10:18:57
Citation de: "DDdeberdeux"
Si quelques uns sont intéressés pour l'essayer (et en attendant que ces modifications ou d'autres soient intégrées dans une version officielle), ils peuvent me passer leurs coordonnées par MP; je leur enverrai le lien pour la télécharger ainsi que la liste des modifications.




Je viens de faire la demande a André pour pouvoir tester sa base.

Aprés les premiers essais, la base fonctionne sans problème, y compris avec dllarbtre :wink:



Merci a André d'avoir ajouté ma proposition consernant les individus orphelins :wink:



Un trés beau travail de la part d'André.



Je pense que PCM devrai en tenir compte pour les prochaines versions d'ancestrologie.
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 19 Octobre 2005 à 11:31:42
Citer
Je pense que PCM devrai en tenir compte pour les prochaines versions d'ancestrologie




des que les arbres seront finis, je regarderais ca
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 19 Octobre 2005 à 15:46:07
Faites bien les tets et si c est ok, je ferai une MAJ rapidement des ces procs
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 19 Octobre 2005 à 17:15:53
Faites aussi des tests sur des grosses bases, voir si les perfs sont toujours la
Titre: Modifications PROC_DELETE_UNION
Posté par: DDdeBerdeux le 24 Octobre 2005 à 18:46:38
La procédure PROC_DELETE_UNION appelée par Ancestrologie pour supprimer une union, devrait supprimer les évènements familiaux liés à cette union. Une erreur fait qu'elle supprime les évènements d'une autre union.J'en propose donc la version suivante:COMMIT WORK;

SET AUTODDL OFF;

SET TERM ^ ;



ALTER PROCEDURE "PROC_DELETE_UNION"

(

  "I_CLEF" INTEGER

)

RETURNS

(

  "COMBIEN" INTEGER

)

AS

BEGIN

   /*---------------------------------------------------------------------------

   Copyright Philippe Cazaux-Moutou. Tout droits réservés.

   Créé le : 31/07/2001

   à : 18:12:56

   Modifiée le : 24/10/2005 par André, simplification, suppression erreur

   provoquant la suppression d'évènements familiaux d'une autre union.

   à : :

   par :

   Description : Supprime une union s'il n'y a pas d'enfants

   Usage       :

   ---------------------------------------------------------------------------*/

   select count(ind.CLE_FICHE) from individu ind , T_UNION u

        where u.UNION_CLEF = :I_CLEF

              AND ind.CLE_PERE = u.UNION_MARI and ind.CLE_MERE = u.UNION_FEMME

        into :COMBIEN     ;



    if (:COMBIEN = 0 ) then

      DELETE FROM T_UNION

         WHERE UNION_CLEF = :I_CLEF;

    suspend;

END

 ^



SET TERM ; ^

COMMIT WORK;

SET AUTODDL ON;
Avec le trigger TBD_T_UNION suivant permettant de supprimer les évènements familiaux liés à l'unionSET TERM ^ ;

CREATE TRIGGER "TBD_T_UNION" FOR "T_UNION"

ACTIVE BEFORE DELETE POSITION 0

as

/* Créé par André le 25/10/2005 pour assurer intégrité*/

BEGIN

  DELETE FROM EVENEMENTS_FAM

  WHERE EV_FAM_KLE_FAMILLE = OLD.UNION_CLEF ;

END

 ^

COMMIT WORK ^

SET TERM ;^
J'ai également mis à jour des triggers de mon message précédent, car j'ai constaté que lors de l'élagage de la base par le BOA, la procédure PROC_DEL_CASCADE_INDIVIDU (appelée par PROC_LR_ELAGAGE_DOSSIER), créait des incohérences en ne supprimant pas des enregistrements de la tables des associations (liés aux évènements familiaux).

Je me demande pourquoi ces triggers n'ont pas été utilisés, ils permettent d'assurer la cohérence de la base, tout en évitant au programmeur de répéter plusieurs fois le même programme (ce qu'il oublie de temps en temps). Le seul inconvénient que je leur connais, c'est qu'ils n'existent pas sur tous les SGBDR et ne facilitent donc pas la portabilité du programme sur une autre base. Mais ici on ne compte pas porter Ancestrologie sur une autre base que Firebird (ou Interbase)?

J'ai mis à jour la base vide contenant toutes ces modifications. Ceux qui la  testent actuellement, peuvent la télécharger au même endroit.

A+

André

Edition du 25/10/2005, pour mise à jour des évènements familiaux par le trigger TBD_T_UNION
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 28 Octobre 2005 à 09:43:25
Créations des triggers T_BI_INDIVIDU_2 et T_BU_INDIVIDU_2 pour vérifier l'unicité de la CLE_FIXE si non essayer de lui attribuer une clé égale au NIP et si çà ne marche toujours pas, chercher une clé libre à partir de 1.SET TERM ^ ;



ALTER TRIGGER "T_BI_INDIVIDU"

ACTIVE BEFORE INSERT POSITION 0

as

begin

   /*---------------------------------------------------------------------------

   Copyright Philippe Cazaux-Moutou. Tout droits réservés.

   Créé le : 01/08/2001

   à : 05:37:37

   Modifiée le :

   à :

   par :

   Description :

   Usage       :

   ---------------------------------------------------------------------------*/

  NEW.DATE_CREATION = 'NOW';

end

 ^



CREATE TRIGGER "T_BI_INDIVIDU_2" FOR "INDIVIDU"

ACTIVE BEFORE INSERT POSITION 1

as

DECLARE VARIABLE CMPT_CFX INTEGER;

begin

   /*---------------------------------------------------------------------------

   Créé le : 28/10/2005 par André pour vérifier que la CLE_FIXE est unique

   si non en chercher une nouvelle

   ---------------------------------------------------------------------------*/

  IF (NEW.CLE_FIXE IS NULL) then EXIT;

  SELECT MIN(CLE_FIXE) FROM INDIVIDU

        WHERE CLE_FIXE = NEW.CLE_FIXE

        PLAN (INDIVIDU INDEX (INDIVIDU_IDX1_CLE_FIXE))

        INTO :CMPT_CFX;

  IF (CMPT_CFX IS NOT NULL AND NEW.CLE_FIXE <> NEW.CLE_FICHE) then

    begin

      NEW.CLE_FIXE = NEW.CLE_FICHE;

      SELECT MIN(CLE_FIXE) FROM INDIVIDU

        WHERE CLE_FIXE = NEW.CLE_FIXE

        PLAN (INDIVIDU INDEX (INDIVIDU_IDX1_CLE_FIXE))

        INTO :CMPT_CFX;

    end

  IF (CMPT_CFX IS NOT NULL) then

    begin

      NEW.CLE_FIXE = 0;

      while (CMPT_CFX IS NOT NULL) do

        begin

          NEW.CLE_FIXE = NEW.CLE_FIXE + 1;

          SELECT MIN(CLE_FIXE) FROM INDIVIDU

            WHERE CLE_FIXE = NEW.CLE_FIXE

            PLAN (INDIVIDU INDEX (INDIVIDU_IDX1_CLE_FIXE))

            INTO :CMPT_CFX;

        end

    end

end

 ^



ALTER TRIGGER "T_BU_INDIVIDU"

ACTIVE BEFORE UPDATE POSITION 0

as

begin

   /*---------------------------------------------------------------------------

   Copyright Philippe Cazaux-Moutou. Tout droits réservés.

   Créé le : 01/08/2001

   à : 05:38:03

   Modifiée le :

   à : :

   par :

   Description :

   Usage       :

   ---------------------------------------------------------------------------*/

  NEW.DATE_MODIF = 'NOW';

  if ((OLD.annee_deces > 0) AND (OLD.annee_naissance > 0)) then

   NEW.age_au_deces = (OLD.annee_deces - OLD.annee_naissance);

end

 ^



CREATE TRIGGER "T_BU_INDIVIDU_2" FOR "INDIVIDU"

ACTIVE BEFORE UPDATE POSITION 1

as

DECLARE VARIABLE CMPT_CFX INTEGER;

begin

   /*---------------------------------------------------------------------------

   Créé le : 28/10/2005 par André pour vérifier que la CLE_FIXE est unique

   si non en chercher une nouvelle

   ---------------------------------------------------------------------------*/

  if (NEW.CLE_FIXE = OLD.CLE_FIXE OR NEW.CLE_FIXE IS NULL) then exit;

  SELECT MIN(CLE_FIXE) FROM INDIVIDU

     WHERE CLE_FIXE = NEW.CLE_FIXE

     PLAN (INDIVIDU INDEX (INDIVIDU_IDX1_CLE_FIXE))

     INTO :CMPT_CFX;

  IF (CMPT_CFX IS NOT NULL AND NEW.CLE_FIXE <> NEW.CLE_FICHE) then

    begin

      NEW.CLE_FIXE = NEW.CLE_FICHE;

      SELECT MIN(CLE_FIXE) FROM INDIVIDU

        WHERE CLE_FIXE = NEW.CLE_FIXE

        PLAN (INDIVIDU INDEX (INDIVIDU_IDX1_CLE_FIXE))

        INTO :CMPT_CFX;

    end

   IF (CMPT_CFX IS NOT NULL) then

     begin

       NEW.CLE_FIXE = 0;

       while (CMPT_CFX IS NOT NULL) do

         begin

           NEW.CLE_FIXE = NEW.CLE_FIXE + 1;

           SELECT MIN(CLE_FIXE) FROM INDIVIDU

             WHERE CLE_FIXE = NEW.CLE_FIXE

             PLAN (INDIVIDU INDEX (INDIVIDU_IDX1_CLE_FIXE))

             INTO :CMPT_CFX;

         end

     end

end

 ^



COMMIT WORK ^

SET TERM ;^

La base vide a été mise à jour.

A+

André

Réédition du 31/10/2005: Les 2 "ALTER TRIGGER" sont là pour remettre ces 2 triggers dans leur forme initiale (pour ceux qui auraient appliqué les modifications précédentes). Les 2 autres triggers créés qui se chargent de la vérification et de la création de la CLE_FIXE, sont séparés pour pouvoir proposer le choix de leur désactivation lors d'une importation.
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 28 Octobre 2005 à 11:47:22
André



1 - Ppourrais tu me faire un recap par mail de toutes tes modifs de la base et surtout dans l ordre. Peux tu me mettre toutes les requetes sql.



2 - ATTENTION, la modif des triggers, c est bien, mais as tu tester sur un tres gros import gedcom ? car ces triggers sont exécutés a chaque création ou modification de fiche, or lors de l import il y a creation, donc autant de fois l executions du trigger, donc si tu as 15000 indi va faire 15000 requete select count



Donc faut essayer avec un gros gedcom voir si le temps d import n est pas trop allongé



a++
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 28 Octobre 2005 à 14:13:46
1- Cà doit être possible en éditant les métadatas de la base modifiée, et en sélectionnant les éléments récapitulés dans le fichier modificationsBDD.txt joint. Par contre pour les modifs de déclaration des fonctions UDF concernant les chaînes de caractères, c'est moins évident. On ne peut pas modifier cette déclaration si elle est utilisée. Pour chacune j'ai d'abord créé une fonct2 équivalente (en 255c), puis dans chaque procédure utilisatrice j'ai remplacé fonc par fonc2. Fonc n'étant alors plus utilisée, j'ai pu la modifier, avant de refaire la manip inverse (remplacement de fonc2 par fonc, suppression de fonc2). Mettre çà en SQL serait "monumental"? C'est un peu pour celà que je proposais une nouvelle base complète.

2- D'accord avec toi, çà ne peut qu'allonger le temps d'importation. Mais comme le champ CLE_FIXE est déjà indexé, çà ne devrait pas prendre trop de temps. Faute de grosse base (2250 individus) si quelqu'un a 15 000 individus... ou bien il faudra que j'en fasse une en réimportant plusieures fois.

Et le temps perdu ici, ne sera-t-il pas largement compensé par celui passé à corriger manuellement les doublons? En proposant l'option "Garder les CLE_FIXE" lors de l'importation, comme je le propose sur le forum BOA, ne laisse-t-on pas le choix à l'utilisateur?

3- Une simple question, lors de l'importation gedcom la CLE_FIXE est-elle systématiquement attribuée si elle est manquante? Si non je pourrai la rajouter dans le trigger before insert.

A+

André
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 28 Octobre 2005 à 14:22:48
Je veux bien inclure tes modifs, mais il faudrait que tu me passe le SQl de tes procs modifiees pour que je les mette dans le code



Citer
Par contre pour les modifs de déclaration des fonctions UDF concernant les chaînes de caractères, c'est moins évident.




Je ne pourrais y incule cette modif la pour les raisons que tu as expliquées



Mettre a dispo une nouvelle base vierge avec tes modifs ?

C est possible mais dans ces conditions



1 - Dans le module d installe complete d ancestrologie

2 - en download libre sur mon site



Car ca poserait trop de pb au gens si on imposait cette base



Mais avant de faire ca, je voudrais qu il y ait plus de gens qui ont testé et qu ils donnent leur avis



Merci pour ton travail



Dans un autre post, t ai demandé de me renvoyer ton adresse email

a++
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 28 Octobre 2005 à 14:32:35
Citation de: "Cazaux-Moutou Philippe"
Mettre a dispo une nouvelle base vierge avec tes modifs ?

C est possible mais dans ces conditions

1 - Dans le module d installe complete d ancestrologie

2 - en download libre sur mon site

Car ca poserait trop de pb au gens si on imposait cette base

OK çà ne me dérange pas une fois que ce sera validé.

Pour l'email c'est fait.

Pour tout le code SQL, laisse moi un peu de temps  pour le récupérer dans les métadatas (et puis il y a du bois à rentrer, une voiture à réparer... :wink: )

A+

André
Titre: Corrections et améliorations des procedures stockées
Posté par: Ransac le 28 Octobre 2005 à 14:37:22
Citation de: "DDdeberdeux"
et puis il y a du bois à rentrer
laisse faire ta femme !

Citation de: "DDdeberdeux"
une voiture à réparer
donne la clé à molette à tes fils !



Rien n'est plus important que la généalogie !  :wink:   :oops:
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 28 Octobre 2005 à 14:40:50
Citer
et puis il y a du bois à rentrer




pour quoi faire  ???

est ce que je fais ca moi ici ??



et puis penses que pour chaque buche que tu rentres c est un arbre qui abattu



DESTRUCTEUR DE FORETS  :D
Titre: Corrections et améliorations des procedures stockées
Posté par: Roger 1 le 28 Octobre 2005 à 15:04:41
DESTRUCTEUR DE FORETS,

Certes non,la forêt c'est comme la généalogie.

C'est sur les anciennes pousses, que nait l'avenir.
Titre: Corrections et améliorations des procedures stockées
Posté par: Charlet le 28 Octobre 2005 à 15:19:40
Citation de: "André"
laisse moi un peu de temps  pour le récupérer dans les métadatas (et puis il y a du bois à rentrer, une voiture à réparer... :wink: )


Et je l'espère les archives départementales à consulter... :wink:
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 28 Octobre 2005 à 23:33:50
C'est çà, vous vous absentez quelques heures, le temps d'abattre une forêt, et vous retrouvez une tonne de messages à lire. On voit bien que certains ignorent le prix du fuel. D'autre part, mamy garde les petits enfants et mes fils aînés, à bientôt 35 ans, çà fait longtemps qu'ils ne sont plus là. Et si j'ai choisi Ancestrologie, entre autres qualités, c'est parce qu'il me permettait d'allier 2 de mes hobbies, l'informatique et la généalogie. Donc je n'oublie pas la généalogie et je ne manquerai pas de "taper" Charlet quand je voudrai confirmer ma généalogie nordiste (mon père était schtimi et sa famille originaire de Neuvilly).

Très content aussi de vous voir sur ce forum, je commençais à m'y sentir bien seul. :wink:

Et puis j'ai pris le temps de faire des tests pour "charger la mule".

Mule utilisée: Athlon 64 3500+, 1Go de RAM. Antivirus et pare-feu activés sans exclure les fichiers .BDD de l'analyse, aucune optimisation de Firebird (paramètres d'allocation mémoire de l'installation par défaut).

Ma base de départ: 2238 individus dont 882 ont déjà une cle fixe unique (doublons précédemment éliminés), 223 images intégrées. Je l'ai exportée en gedcom, puis j'ai réimportée 6 fois de suite pour avoir une base 7 fois plus importante soit 15666 individus dont 6174 avec clé fixe uniques (j'ai appliqué à ma base toutes les solutions proposées) et 1561 images. J'en ai exporté le nouveau gedcom (que j'ai évidemment appelé 7FAMILLES.ged).

J'ai repris ma base vide et j'ai importé cette base vide (avec les images). Durée de l'opération, près de 11mn 57s.

A partir de la base standard récupérée sur le site ancestrologie.org, mise à niveau de version par ancestrologie et vidée. Durée de l'opération: 5mn 8s. Par contre, j'ai retrouvé un doublon de cle_fixe dans cette base, ce qui me laisse perplexe. J'ai vérifié qu'il n'y en a pas dans le gedcom. J'ai recommencé l'opération; même doublon! Il y a une cle_fixe de plus (6175), attribuée à un individu qui n'en avait pas. Particularité: le NIP attribué à cet individu est égal à la cle_fixe. N'y aurait-il pas une autre "coucouille" comme dit Philippe que j'aurai corrigée par hasard? Mystère :?:

Les 6mn 50s de plus sont donc uniquement le temps mis pour vérifier que dans les 6174 cle_fixe importées, il n'y a pas de doublons.

Un raisonnement mathématique que je ne vais pas développer ici, démontre qu'avec la méthode de calcul de la clé proposée, le temps croit proportionnellement au carré du nombre de clés déjà attribuées. Lors des imports successifs du même gedcom que j'ai du effectuer pour obtenir le gedcom de 15666 individus, je réimportais à chaque fois 882 doublons que la base devait recalculer. Lors de la dernière importation, lorsqu'il y avait donc déjà environ 6000 clés affectées, le temps de calcul d'une nouvelle clé prenait environ 0,4s.

C'est à mon avis beaucoup moins que le temps mis à retrouver ces doublons et à les corriger. Qu'en pensez-vous :?:

Par contre si quelqu'un avait une idée d'un test plus rapide que par le COUNT(CLE_FIXE)? qui donnerait un résultat sans avoir besoin de balayer toute la table.

Comme j'ai constaté que lors de l'import gedcom, ancestrologie n'attribuait pas (sauf erreur :wink: ) la CLE_FIXE, n'y aurait-il pas un intérêt à ce que je le fasse automatiquement dans le trigger before insert?

Espérant ne pas vous avoir assommés,

Bonsoir, A+

André

PS: pour les métadatas, on verra demain, il fait nuit depuis longtemps ici.
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 28 Octobre 2005 à 23:42:21
Citer
pour les métadatas, on verra demain




prends ton temps,



Bien pour les tests
Titre: Corrections et améliorations des procedures stockées
Posté par: Bruno T. le 28 Octobre 2005 à 23:49:13
Je n'ai pas vérifier, mais j'ai ces 2 Proc qui trainent, si vous les avez déja recenser tres bien, sinon faudra pas les oubliées



http://msbt.free.fr/ancestro/autres/PROC_TROUVE_UNIONS.sp

http://msbt.free.fr/ancestro/autres/PROC_ACTES_A_TROUVER_FAMILLES.sp



qui concernent: http://msbt.free.fr/ancestro/autres/memo_modif_encours_base%203.57



Merci  :wink:
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 28 Octobre 2005 à 23:53:29
André



as tu recu mes mails ?
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 29 Octobre 2005 à 00:21:48
Citation de: "macpc"
Je n'ai pas vérifier, mais j'ai ces 2 Proc qui trainent, si vous les avez déja recenser tres bien, sinon faudra pas les oubliées

http://msbt.free.fr/ancestro/autres/PROC_TROUVE_UNIONS.sp

http://msbt.free.fr/ancestro/autres/PROC_ACTES_A_TROUVER_FAMILLES.sp

Il me semble qu'elles sont prises en compte avec des solutions presque identiques (sans le savoir), par des messages dans ce fil.

le 17 septembre: PROC_TROUVE_UNIONS, en plus la procédure est "bisexuée" et prend en compte la première date d'un évènement familial (date exacte si elle existe, sinon année).

le 20 septembre: PROC_ACTES_A_TROUVER, DEJA_TROUVES et RAZ pour retrouver une complète symétrie entre homme et femme.



Bonne nuit

André

PS pour Philippe: je n'ai reçu qu'un email. Merci

Réédition: 2ième reçu le lendemain
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 31 Octobre 2005 à 15:53:06
Cà y est, je pense avoir trouvé une solution qui vérifie les CLE_FIXE et les modifient si nécessaire lors de l'importation d'un gedcom, sans perdre trop de temps. J'ai mis à jour en conséquence mon message du 28 octobre 9:43 (ancienne heure). L'importation d'un gedcom de 15666 individus dont 6174 avec CLE_FIXE et pas mal de médias prend 5mn08 avec la base originale et 5mn28 avec la base modifiée. 20s pour être sûr qu'il n'y a pas de doublons, çà n'est pas cher payé, comparé au temps passé pour les éliminer!

En fin de compte j'ai mis le contrôle dans 2 nouveaux triggers. Cà permettra à Philippe de proposer de les désactiver par une option "Garder les anciens liens externes" lors de l'importation.

J'ai renoncé à numéroter systématiquement les CLE_FIXE à NULL, car en les renumérotant, j'augmente considérablement les risques de rejet et modification des clé suivantes. D'ailleurs je me demande encore s'il ne serait pas préférable de simplement supprimer les clés en double? Leur attribuer un N° risque également de faire renuméroter une clé suivante. Dans ce cas, il vaudra mieux cocher l'option "Garder les anciens liens externes", et rechercher les doublons avec la requête déjà vu sur ce forum.

Et pour ceux qui voudront créer à priori tous les liens externes, il leur suffira d'exécuter après importation la requêteUPDATE INDIVIDU SET CLE_FIXE = CLE_FICHE WHERE CLE_FIXE IS NULLles triggers se chargeront de rectifier les clés en double.

Ceux qui veulent tester la base intégrant toutes les modifications peuvent la télécharger ici (http://andre.langlet.free.fr/fichiers/FAMILLEVIDE.zip) Le fichier compacté contient un fichier texte avec la liste des modifications et un fichier FAMILLEVIDE.BDD. Ce dernier fichier est à renommer et placer où vous voulez, du moment que vous le sélectionniez par "Emplacement de la base de données". Après la sélection, Ancestrologie propose de le remplir directement par un gedcom ou une fiche.

Si çà marche, YAPUKA éditer les modif pour que PCM les intègre aux prochaines versions.

A+

André
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 31 Octobre 2005 à 15:57:32
Citer
Si çà marche, YAPUKA éditer les modif pour que PCM les intègre aux prochaines versions.




pas de pb pour les integrer



Mais j attends le SQL pour faire ca et surtout dans l ordre de creation



Bon travail que tu fais la
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 01 Novembre 2005 à 00:01:36
C'est fait, je t'ai envoyé 3 scripts sur ta messagerie. Je les ai aussi ajoutés au fichier zip dont le lien est dans mon message précédent.

Il n'y a pas d'ordre particulier pour passer les scripts. Mais le script blr2txt doit être passé tout d'un bloc.

A+

André
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 06 Novembre 2005 à 21:03:19
J'ai remodifié la procédure PROC_EXPORT_IMAGES pour que le fichier exporté ait pour nom "NON AFFECTEE" si le média n'est pas affecté à un individu, et "SANS NOM" si l'individu n'a pas de nom.

Le fichier en téléchargement a été mis à jour.

André
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 08 Novembre 2005 à 15:29:25
André , tai envoyé mail, as tu recu ?
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 08 Novembre 2005 à 15:51:20
Citation de: "Cazaux-Moutou Philippe"
André , tai envoyé mail, as tu recu ?
OK, bien reçu. Je mets à jour la base vide en v4.00, je mets le tout sur mon site avec la procédure de maj et passe un appel à volontaires pour les tests avant officialisation dans un nouveau sujet sous Développement.

A bientôt

André
Titre: Corrections et améliorations des procedures stockées
Posté par: Ancestrologie le 08 Novembre 2005 à 15:55:45
Je penses que si tu met la 4.0, ok, mais faut arreter d y faire des modifs

pour que deja ils testent

et qu apres ce que je te propose c est si tu fait des modifs garde les et on les proposera 1 fois par mois et on les fera integrer par ancestro



dans ta proc peux tu sortir un fichier log de ce que fais isql ?



a+
Titre: Corrections et améliorations des procedures stockées
Posté par: DDdeBerdeux le 08 Novembre 2005 à 18:44:03
OK, pour regrouper, en espérant que comme il s'agit pour la plupart de réparation de bugs, la source sera tarie :wink:

Isql peut générer un fichier d'erreurs. Je t'ai envoyé tout çà par email.

A+

André