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
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, Tonyje 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.
| |
||
|
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 www.ifremer.fr |
Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44 |
|