bonjour, merci pour le diagnostique. Je vais regarder d'où ça peut venir (on n'a pas le doublon dans le système central, mais il a peut être existé et été corrigé, il faut que je regénère la base locale). On pourrait effectivement faire des tests et des corrections dans Tutti, mais on en a déjà parlé et ça ne serait pas la bonne manière de fonctionner pour plusieurs raisons : * il faudrait faire ces tests sur chaque outil * il faudrait ensuite les maintenir * on ne saurait pas forcément quelle info retenir en cas de doublon * il ne faudrait pas uniquement corriger les données en local, mais remonter l'information pour les corriger en central * ... Donc il est préférable de ne pas implémenter ces tests / corrections dans les outils. Ces cas d'erreur sur les référentiels sont relativement isolés et on est organisé en exploitation pour faire face à ces situations mais ça nécessite juste que les outils fournissent suffisamment d'informations pour pouvoir diagnostiquer l'origine du problème. Il n'est pas gênant que l'utilisateur ait un message Java à l'écran (même si ça peut ne pas paraitre "propre"). Par contre, il faut ensuite que le guichet d'exploitation puisse diagnostiquer l'erreur et la corriger. Ca permet aussi d'enrichir des procédures de contrôle au niveau du système central (plutôt que de les mettre dans chaque outil). Si on doit réfléchir à quelque chose à mettre en place, c'est plus d'avoir une trace pour obtenir la requête qui pose problème sans qu'on soit obligé d'avoir l'environnement de développement et de lancer un debuggage de l'outil. En occurrence, ce qui me gêne ici c'est de ne pas avoir la requête qui pose problème sur vessel_features dans les logs. On aurait pu s'en sortir avec les logs car on y voit le code du navire qui pose problème, mais cette fois pas de chance le code était '******' donc j'ai pensé qu'on n'avait pas l'information. Christian Le 24/01/2016 19:44, Tony Chemit a écrit :
On Fri, 22 Jan 2016 14:47:26 +0100 Tony Chemit <chemit@codelutin.com> wrote:
On Fri, 22 Jan 2016 12:32:02 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
bonjour, Bonjour,
après vérification j'ai trouvé un doublon dans la table VESSEL_FEATURES pour le navire de code '******' avec une date de fin non renseignée.
SELECT t.* FROM PUBLIC.VESSEL_FEATURES t WHERE VESSEL_FK='******'
donc dans la requête cela remonte deux fois le navire, ce qui provoque ensuite une erreur lorsque que l'on veut produire un dictionnaire indexé par le code du navire.
Il faut il me semble produire une nouvelle version du référentiel qui corrige le problème.
Je vais compléter le ticket.
Je vous ai déjà proposer de faire des vérifications sur les bases de référentiel; je comprends bien que vous ne voulez pas que cela soit fait dans Tutti car ce n'est pas forcement le bon endroit, mais il faudrait AMHA quand même faire ses vérifications. On peut en rediscuter si vous le voulez conjointement avec Benoît.
Cordialement, Tony
je viens de soumettre une anomalie car on obtient une erreur en allant dans la configuration suite à une mise à jour des référentiels. J'ai essayé de voir le problème au niveau des référentiels (à priori navire), mais je ne comprends pas car d'après les requêtes effectuées je n'obtient pas de doublon contrairement à ce que l'erreur indique. A moins qu'il y ait une autre requête que celle en SQL qui est ensuite exécutée et que je ne peux pas analyser. Ok on regarde de quoi il retourne.
tony.
-- Site Ifremer <http://www.ifremer.fr> Christian BONNET Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Informatique et Données Marines Ingénierie des Systèmes d'Information christian.bonnet@ifremer.fr <mailto:christian.bonnet@ifremer.fr> www.ifremer.fr <http://www.ifremer.fr> Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44
