Auteur Sujet: Base (b4.033) b4.035 en test.  (Lu 8671 fois)

plus minus reset

0 Membres et 1 Invité sur ce sujet

Hors ligne DDdeBerdeux

Base (b4.033) b4.035 en test.
« le: 02 Juin 2006 à 15:21:30 »
Si certains veulent bien essayer cette version (sur une copie de leur base par sécurité), le fichier de mise à jour est à télécharger ICI et la base vide accompagnée de la liste complète des modifications LA .

Pour éviter quelques erreurs, la version V524 du logiciel est nécessaire, Philippe ne devrait pas tarder à la mettre en ligne.

Depuis la version b4.031 les modifications sont les suivantes:PROC_VILLES_FAVORIS suppression CAST inutiles (accélération).

Ajout dans la procédure de maj, du champ CLE_FIXE et des triggers qui vont avec dans la table INDIVIDU, de NCHI et NMR pour réparer certaines bases dont la migration aurait été faîte alors qu'elles n'étaient pas en b3.57.

Suppression du TRIGGER INDIVIDU_AU inutile et qui provoque une erreur sous FB2.0.

Corrections de la PROC_COMPTE_ONGLETS pour erreurs d'apparition du point vert sur l'onglet "Médias".

Création de la table T_GROUPES et des PROC_LR_SEL_GROUPE et PROC_LR_MIX_GROUPES qui semblent "oubliées" dans certaines bases qui ont été mises en ligne.

Modification de PROC_LR_SEL_GROUPE pour erreur sur la sélection des ascendants et descendants (I_MODE=2), vu avec Laurent Robbe.

Modification des champs BLOB sub_type 2 (BLR) en sub_type 0 mieux adapté au stockage des images et reconnu par les autres logiciels lorsqu'ils contiennent des images.

Création procédure PROC_DATE_WRITEN_UN et modification PROC_DATE_WRITEN pour identifier des dates de fin d'un évènement lorsque la date est saisie sous la forme "entre le XX/XX/XXXX et le XX/XX/XXXX". PROC_DATE_WRITEN peut "normaliser" les dates sous une forme littéraire ou numérique, suivant la valeur d'un nouveau TOKEN_DATE de TYPE_TOKEN=23, TOKEN="LIT' ou 'NUM' ou 'NON'.

Ajout aux tables ADRESSES_IND, EVENEMENTS_IND et EVENEMENTS_FAM des champs MOIS, MOIS_FIN, AN_FIN et DATE_FIN et modification des triggers pour documenter ces champs. Mise à jour de ces champs par la procédure de mise à jour.

Création de la PROC_MAJ_FORME_DATE pour changer le TYPE_TOKEN 23 en LIT, NUM ou NON en mettant à jour les dates calculées et saisies selon la valeur du token.

Création d'une fiche familiale "Fiche_familiale_inv.rtm" où la vie du couple est avant les enfants, sans saut de page.
Quelques commentaires:

La principale nouveauté de cette version, a pour origine un message de Christophe http://www.ancestrologie.org/forum/index.php?topic=5721.0

Il m'a permis de constater que s'il est possible dans les évènement de saisir des dates sous la forme "entre le 19/11/1945 et décembre 1946", il n'y avait que la première date et son année qui étaient mémorisées et exploitables dans des requêtes. J'ai donc ajouté la mémorisation de la deuxième date et année, ainsi que les mois des 2 dates dans les tables évènements. Il faut comprendre cette 2ième date comme une date limite supérieure avant laquelle l'évènement est intervenu. Elle peut donc être documenté même s'il n'y a qu'une seule date saisie, si cette date est précédée d'un mot clé (token_date) du type "avant". Les 2 dates peuvent même être inversées si on a saisi par exemple "entre date1 et date2" et que date1>date2. Les noms des champs concernés se terminent par "_FIN".

Pour répondre à la demande de certains (P.Horemans, Lya) qui souhaitent pouvoir saisir rapidement des dates sous la forme "numérique" (19/11/1945) mais que celle-ci s'affiche sous la forme "littéraire" (19 novembre 1945), cette possibilité a été intégrée à la procédure PROC_DATE_WRITEN qui met à jour les champs dates.

Afin de ne pas "imposer" à tout le monde ce type de fonctionnement (d'autres peuvent préférer le forme numérique, ou que leur saisie ne soit pas modifiée), un nouveau type (24) de TOKEN a été ajouté à la table REF_TOKEN_DATE.

Il peut prendre les valeurs 'LIT', 'NUM' ou 'NON'.

'LIT' met la date sous forme littéraire

'NUM' sous forme numérique

'NON' la laisse comme saisie.

A la première utilisation cette variable est initialisée à 'LIT'.

Pour que celà fonctionne, il ne faut pas utiliser dans le champ de saisie de la date, des mots qui n'appartiennent pas à la "Liste des mots clés utilisés dans les dates" (menu configuration). Si cette condition n'est pas respectée, la date saisie n'est pas modifiée, et les champs date, mois, année pas documentés.

Dans la forme litéraire, le mois est remplacé par le premier nom du mois figurant dans la liste des mots clés. Donc si certains préfèrent normaliser leurs dates en "janv" au lieu de "janvier", ils doivent changer l'ordre dans cette liste.

La procédure PROC_MAJ_FORME_DATE a été ajoutée pour définir ce mode de fonctionnement et mettre à jour les champs dans la base. Elle doit être exécutée dans le BOA par l'instruction:EXECUTE PROCEDURE PROC_MAJ_FORME_DATE(FORME,MODE_MAJ) FORME doit prendre l'une des 3 valeurs 'LIT', 'NUM' ou 'NON' pour définir le mode de fonctionnement comme expliqué ci-dessus.

MODE_MAJ peut prendre les valeurs 0, 1 ou 2.

0 ne change que le mode de fonctionnement.

1 recalcule en plus les champs date, mois et année

2 effectue en plus la "normalisation" des champs dates saises selon la forme définie, dans toute la base.

Pourquoi la V524? Afin de pouvoir ajouter des champs aux différentes tables, Philippe a dû modifier son exécutable qui sans celà provoquait des erreurs lors de certaines fonctions (import gedcom par exemple). Comme dans cette version il a également réparé certaines actions à l'origine des erreurs de répertoire, que j'avais bloquées par les triggers, j'ai remis les triggers dans leur forme normale. Donc ils ne bloquent plus les erreurs des anciennes versions.

Le WE s'annonce froid et pluvieux. Donc bons tests. :wink:

André

PS: la V524 est en bêta http://www.ancestrologie.org/france/majbeta/Ancestrologie.exe

Réédition; voir message du 07/06/2006 pour passage à b4.034
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Pierrot

  • AncestrArbres -Test
  • AncestroSenior
  • *****
  • Messages: 1 044
  • Remercié: 1 fois
  • Programme: V.1360
  • Base: 5.130
Base (b4.033) b4.035 en test.
« Réponse #1 le: 04 Juin 2006 à 23:29:35 »
Bonsoir,



Je viens d'encoder une grosse quantitée de données avec la version béta et n'ai rencontré aucun problème ni aucun plantage

Pierrot


Windows XP Pro SP 3 - 2048 Mo - Affichage 1024x768
 

Hors ligne DDdeBerdeux

Base (b4.033) b4.035 en test.
« Réponse #2 le: 05 Juin 2006 à 11:38:17 »
Ouf, tout le monde n'est pas à Roland Garros :?

Petites questions sur la présentation normalisée de la date:

Sous la forme littéraire comme sous la numérique, le jour est présentée par 2 chiffres (en ajoutant le 0 devant si nécessaire), et l'année sur 4 chiffres. Celà me semble indispensable dans la forme numérique (XX/XX/XXXX).

Est-ce que celà vous gêne dans la forme littéraire? J'aurai la possibilité de laisser ces nombres sans les 0 par le code, mais çà ne peut pas être laissé au choix de l'utilisateur.

Dans la forme numérique, le séparateur est le "/". Je pourrai le laisser au choix de l'utilisateur (premier des séparateurs dans la liste des mots clés utilisés dans les dates).

Est-ce que çà vous intéresse?

Vous avez peut-être remarqué que la "normalisation" ne concerne que la présentation de la date et non les mots clés (token date). Je ne l'ai pas fait dans cette version parce que celà faisait trop de problèmes à résoudre à la fois et qu'il faudrait modifier la table de référence et la fiche qui donne accès aux mots clés. Un même type_token peut en effet être traduit sous différentes formes littéraires selon la forme de la date.

A BEF par exemple correspond "avant", "avant le", "avant l'année" et autres variantes avec fautes d'orthographes mises en mots clés pour qu'ancestro puisse les interpréter.

Je pense avoir trouver une logique pour choisir le bon mot clé.

Cette normalisation peut-être intéressante car elle permettrait principalement d'améliorer la présentation après un import gedcom où actuellement le premier mot clé du token-date est systématiquement utilisé. ex "avant 19 janvier 1900" au lieu de "avant le 19 janvier 1900".

Est-ce que çà intéresse quelqu'un que je programme cette normalisation?

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Pierrot

  • AncestrArbres -Test
  • AncestroSenior
  • *****
  • Messages: 1 044
  • Remercié: 1 fois
  • Programme: V.1360
  • Base: 5.130
Base (b4.033) b4.035 en test.
« Réponse #3 le: 05 Juin 2006 à 12:09:14 »
Bonjour André,



Personellement, le zéro ne me gêne pas.



Pour le séparateur j'utilise toujours le / donc pas de problème. mais peut-être que d'autres utilisent un autre séparateur, donc il serait bon d'avoir le choix.



Cela serait un plus pour l'esthétique si effectivement il était écrit "Avant le 19 janvier 1900", pour autant que lorsque l'on encode uniquement l'année il ne soit pas écrit "Avant le 1900" par exemple.



Mais ceci n'est que mon point de vue  :D



Bonne journée.

Pierrot


Windows XP Pro SP 3 - 2048 Mo - Affichage 1024x768
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Base (b4.033) b4.035 en test.
« Réponse #4 le: 05 Juin 2006 à 12:56:12 »
D'accord avec Pierrot, je n'utilise que la forme xx/xx/xxxx dans MES saisies, mais les imports gedcom donnent un peu de tout.

Tout outil de normalisation est le bienvenu de même que tout ce qui améliore la présentation.

L'idéal serait donc d'avoir des formes minimum mais rigoureuses pour la saisie et des formes plus littéraires pour les documents de sortie.

Je n'apporte pas d'élément supplémentaire, mais j'approuve.  :)
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Base (b4.033) b4.035 en test.
« Réponse #5 le: 05 Juin 2006 à 13:27:10 »
Le 0 n'est pas gênant dans une forme littéraire. Si tu commences à mettre le doigt dans de telles modifs, il va falloir aussi mettre er derrière 1 (1er) etc...

Il y a des programmes de présentation qui permettent çà (Généalogica Graphica - Filiatus)



Penses-tu faire une normalisation générale des dates (et pas seulement la présentation) ?

Ce genre de modif pourrait être intégrée au BOA pour traiter les import gedcom issus d'autres programmes.
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne DDdeBerdeux

Base (b4.033) b4.035 en test.
« Réponse #6 le: 05 Juin 2006 à 13:46:56 »
Citation de: "Horemans"
D'accord avec Pierrot, je n'utilise que la forme xx/xx/xxxx dans MES saisies, mais les imports gedcom donnent un peu de tout.
Déjà tu dois voir que, si tu as laissé la forme LIT comme elle se met lors de la mise à jour en b4.033, la date saisie est transformée en littéraire, tout comme lors de l'importation d'un gedcom. Si celà ne se fait pas, c'est que sans doûte les mots clés utilisés ne sont pas corrects.

J'ai fait dans ma base perso la modif pour supprimer les zéros des jours et années en forme littéraire et le séparateur de la forme numérique. La présentation est meilleure. Je vous la communiquerai dans une version b4.034. Mais j'essaie la normalisation des mots clés avant de vous l'envoyer.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Lya

  • AncestroSenior
  • *****
  • Messages: 1 396
    • http://quidancestro.free.fr
Base (b4.033) b4.035 en test.
« Réponse #7 le: 05 Juin 2006 à 13:57:37 »
Hello André,



J'allais te demander si la suppression du 0 en forme littéraire était possible, mais je vois que tu y as déjà pensé !  :wink:

Le choix du séparateur est aussi intéressant, je souscris donc au "oui".



Par contre, j'ai un problème avec ta procédure : ça marche bien avec mode_maj = 0 mais j'obtiens un "Erreur lors de l'accès aux données" avec le choix 1 ou 2. Et mes colonnes mois sont toujours vides sauf pour ceux que je modifie après application du choix 0  :?:



En tout cas, superbe travail comme toujours !  Merci aux courageux qui travaillent le lundi de Pentecôte :!:  :lol:  :wink:
Un bon voyageur n'a pas d'itinéraire fixe, et n'a pas l'intention d'arriver...



 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Base (b4.033) b4.035 en test.
« Réponse #8 le: 05 Juin 2006 à 17:42:38 »
Citation de: "Lya"
j'obtiens un "Erreur lors de l'accès aux données" avec le choix 1 ou 2.


Même souci
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne DDdeBerdeux

Base (b4.033) b4.035 en test.
« Réponse #9 le: 05 Juin 2006 à 21:35:43 »
Bizarre, je n'ai pas cette erreur. Et suite à vos messages, j'ai même fait l'essai avec une ancienne base b3.57, et la maj s'est exécutée sans problème, tout comme les requêtes avec IBOConsole et le BOA.

Pourriez-vous regarder la fin du fichier modifbase.log qui se trouve dans le répertoire ancestrologie. Il contient tous les messages émis pendant la maj. Depuis les dernières versions, je met entre 2 lignes de commentaires qui l'indiquent, les instructions qui peuvent provoquer normalement des erreurs. Normalement le fichier doit se terminer par:unsuccessful metadata update

-Procedure PROC_LR_SEL_GROUPE already exists

COMMIT WORK^

/*Fin des erreurs normales*/

SET ECHO OFF^

/*Passage en version 4.033

L'utilisation de la base modifiée avec une version du logiciel inférieure à V524 peut entraîner des disfonctonnements.*/

SET ECHO OFF^



La mise à jour des champs MOIS intervient après la ligne /*Fin des erreurs normales*/, et est faîte par la PROC_MAJ_FORME_DATE en mode 1. S'il y a eu des erreurs, vous devriez les retrouver là.

Dans le BOA, l'exécution de l'instruction

EXECUTE PROCEDURE PROC_MAJ_FORME_DATE('LIT',2)

s'obtient en cliquant sur le bouton "Exécuter la procédure", et LIT doit être entouré de simples cotes.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Lya

  • AncestroSenior
  • *****
  • Messages: 1 396
    • http://quidancestro.free.fr
Base (b4.033) b4.035 en test.
« Réponse #10 le: 05 Juin 2006 à 22:30:24 »
Moi, j'ai ça :



unsuccessful metadata update

-Procedure PROC_LR_SEL_GROUPE already exists

COMMIT WORK^

/*Fin des erreurs normales*/

SET ECHO OFF^

Statement failed, SQLCODE = -413



conversion error from string "-"


/*Passage en version 4.033

L'utilisation de la base modifiée avec une version du logiciel inférieure à V524 peut entraîner des disfonctonnements.*/

SET ECHO OFF^
Un bon voyageur n'a pas d'itinéraire fixe, et n'a pas l'intention d'arriver...



 

Hors ligne Bruno T.

  • Administrateur
  • AncestroGrandMaitre
  • *****
  • Messages: 4 599
  • Remercié: 66 fois
    • Notre Généalogie
  • Programme: 1998.1.6 - dev: 2001.3.16
  • Base: 5.131 emb/serv
  • Système: w10x64
Base (b4.033) b4.035 en test.
« Réponse #11 le: 06 Juin 2006 à 00:22:15 »
et moi ça, depuis 4.028SET ECHO OFF^

Statement failed, SQLCODE = -802



arithmetic exception, numeric overflow, or string truncation

/*Passage en version 4.033
De plus j'arrive pas avec BOA il me dit erreur d'accés aux données,  il faut bien faire: EXECUTE PROCEDURE PROC_MAJ_FORME_DATE('LIT',1) et exécuter procédure ?

Bon, vais jeter un coup d'oeil dans IBexpert, mais vu l'heure vais pas trainer  :wink:



[EDIT:] Pour info dans IbExpert j'obtiens:

Arithmetic overflow or division by zero has occurred.

arithmetic exception, numeric overflow, or string truncation.


[EDIT 2:] :idea:  Une piste   :arrow:  j'ai pas de typetoken à 24, ils s'arrêtent a 23  :roll:

[EDIT 3:]  :oops:  aie! non j'ai rien dit, c'est que tu le crées le 24, he ben chez moi il se crée pas, puisque ça plante  :?

Sur ce ... Bonne nuit  8)
Téléchargez des images supplémentaires pour Ancestr'Arbres Images au choix enrichissez en ajoutant les votres
A+    Bruno
                                                                                               
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Base (b4.033) b4.035 en test.
« Réponse #12 le: 06 Juin 2006 à 09:55:34 »
J'ai rigoureusement la même chose que Bruno.
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne DDdeBerdeux

Base (b4.033) b4.035 en test.
« Réponse #13 le: 06 Juin 2006 à 10:56:32 »
Bonjour,

Le type_token 24 est créé la première fois que la PROC_DATE_WRITEN (procédure qui calcule les différentes valeurs) est exécutée. Elle est donc utilisée lors de l'exécution de PROC_MAJ_FORME_DATE('LIT',1) au cours de la maj de la base. S'exécutant donc dans la même transaction la création est annulée si une erreur intervient lors de l'exécution de PROC_MAJ_FORME_DATE.

Mais PROC_DATE_WRITEN s'exécute seule ensuite à chaque fois qu'on modifie la saisie d'une date. Pourriez-vous me dire si vous avez une erreur lors de cette saisie? Le champ MOIS correspondant est-il alors bien documenté et le type_token 24 ajouté?

Cà me permettrait de savoir dans quelle procédure il y a un problème.

Pour Lya, n'y aurait-il pas une date avec un signe moins? Que se passe-t-il si le signe moins est ajouté dans la liste des séparateurs?

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Lya

  • AncestroSenior
  • *****
  • Messages: 1 396
    • http://quidancestro.free.fr
Base (b4.033) b4.035 en test.
« Réponse #14 le: 06 Juin 2006 à 20:19:02 »
Bonsoir à tous :)

Citation de: "DDdeberdeux"
Pour Lya, n'y aurait-il pas une date avec un signe moins? Que se passe-t-il si le signe moins est ajouté dans la liste des séparateurs?


C'était bien ça. J'avais plusieurs dates-intervalles sous la forme "1845-1899". Après les avoir rectifiées en "entre 1845 et 1899" et relancé l'outil de migration de la base, tout est rentré dans l'ordre et je peux maintenant utiliser ta procédure.



Donc c'est Ok chez moi. Merci André.  :P  :wink:
Un bon voyageur n'a pas d'itinéraire fixe, et n'a pas l'intention d'arriver...



 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Base (b4.033) b4.035 en test.
« Réponse #15 le: 06 Juin 2006 à 20:39:01 »
Citation de: "DDdeberdeux"
Pourriez-vous me dire si vous avez une erreur lors de cette saisie? Le champ MOIS correspondant est-il alors bien documenté et le type_token 24 ajouté?


Peux-tu être plus explicite, j'arrive à mes limites :

Je saisie une date sur un événement sans problème, mais après ? :oops:

Et comme je ne veux pas mourir stupide...
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne Bruno T.

  • Administrateur
  • AncestroGrandMaitre
  • *****
  • Messages: 4 599
  • Remercié: 66 fois
    • Notre Généalogie
  • Programme: 1998.1.6 - dev: 2001.3.16
  • Base: 5.131 emb/serv
  • Système: w10x64
Base (b4.033) b4.035 en test.
« Réponse #16 le: 06 Juin 2006 à 22:23:32 »
Citation de: "DDdeberdeux"
Mais PROC_DATE_WRITEN s'exécute seule ensuite à chaque fois qu'on modifie la saisie d'une date. Pourriez-vous me dire si vous avez une erreur lors de cette saisie? Le champ MOIS correspondant est-il alors bien documenté et le type_token 24 ajouté?
Bonjour André, comme le dit Philippe H.  :roll:  :shock:    :?:  (à moins que tu n'entendes le mois est converti en littéral par 'documenté')



Je viens d'essayer :

1 - avec une saisie 'vers 14/12/1674' sans erreur, convertie dans l'evenement en 'vers 14 décembre 1674'

2 - vérification dans ibExpert, le token 24 a bien été créé ce coup là

3 - lancement de la procédure dans ibexpert = erreur idem hier

4 - lancement de la procédure dans boa = erreur idem hier ( et de plus la sortie du Boa suite à l'erreur ne me redonnes pas la main sur ancestro, ctrlaltsupr  :cry:   :evil:  mais ça c'est pour Lau et PCM  :wink: )

Espérant que celà t'aides un peu
Téléchargez des images supplémentaires pour Ancestr'Arbres Images au choix enrichissez en ajoutant les votres
A+    Bruno
                                                                                               
 

Hors ligne DDdeBerdeux

Base (b4.033) b4.035 en test.
« Réponse #17 le: 06 Juin 2006 à 23:31:20 »
Citation de: "Lya"
J'avais plusieurs dates-intervalles sous la forme "1845-1899". Après les avoir rectifiées en "entre 1845 et 1899" et relancé l'outil de migration de la base, tout est rentré dans l'ordre et je peux maintenant utiliser ta procédure
Bonsoir,

Enfin une chez qui çà marche, mais ce serait mieux si cette erreur pouvait ne pas planter le reste de la mise à jour. Je vais chercher une solution, car j'ai l'impression que Lya n'est pas la seule concernée.

Dans la table ADRESSES_IND, j'ai ajouté les champs, ADR_DATE_MOIS_1 et ADR_DATE_MOIS_2

Dans EVENEMENTS_FAM, EV_FAM_DATE_MOIS, EV_FAM_DATE_MOIS_FIN, EV_FAM_YEAR_MOIS et EV_FAM_DATE_FIN

Dans EVENEMENTS_IND, EV_IND_DATE_MOIS, EV_IND_DATE_MOIS_FIN, EV_IND_YEAR_MOIS et EV_IND_DATE_FIN

pour mémoriser le mois de la première date, le mois, l'année et la date exacte (si possible) de la date de fin.

Par "documenté", je voulais demander si les champs MOIS de la première date ci-dessus étaient remplis (par le n° du mois). Pour la date de FIN, il peut arriver que la date de fin soit remplie même s'il n'y a qu'une date saisie; dans le cas de "avant XX/XX/XXXX".

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Claude Baudin

  • AncestroSenior
  • *****
  • Messages: 1 709
Base (b4.033) b4.035 en test.
« Réponse #18 le: 07 Juin 2006 à 07:53:11 »
Je viens d'essayer d'entrer une date type vers 14/05/2006 en sortie j'ai bien 14 mai 2006 :wink:
Cordialement
A+
Ancestrologie V 1101 B 5122
PIV 3G° 2048 M°
Intel core 2 duo, 2048M° Ecran 19p et 17p
OS Vista  Windows7 et Xp
___________

Claude
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Base (b4.033) b4.035 en test.
« Réponse #19 le: 07 Juin 2006 à 09:15:14 »
J'obtiens bien la forme littéraire à la confirmation de la saisie d'un événement, mais la procédure de mise à jour dans le BOA affiche le message d'anomalie, chez moi après avoir mouliné plusieurs minutes. Je n'ai pas validé avant de quitter.
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe