De : Montel Olivier [mailto:xxx@yyy.zzz]
Envoyé : lundi 6 mars 2006 18:44
À : 'Eptica Peaucelle (E-mail)'
Cc : 'xxx@yyy.zzz'
Objet : RE: Insee/Réponse [de nouveau] Problème modifications / nouveau champ Requête en formulaire Eptica TelSIC
Laurent bonsoir,
Je reviens vers toi au sujet de ce mel en date du 22-02, sauf erreur toujours en suspens.
Je pense notamment au point - 1 - qui est bloquant pour toute évolution de formulaire Eptica Server.
================================================================
Par ailleurs, j'ai une question relative au contenu de la BDD sous Oracle.
Que ce soit en 8i en Prod ou en 9 en Intégration, un champ non renseigné n'est pas vide mais alimenté par deux
caractères spéciaux « [] [] » que je ne comprends pas et que je ne suis pas en mesure de réutiliser. Autrement dit les
"NULL" ou "NOT NULL" standard en SQL sont inopérants dans le cas des BDD Eptica. Tout ce que je peux dire, c'est que:
- le code décimal du caractère ASCII "[]" en question est apparemment .
- la tentative de réutilisation (via copier-coller) de cette modalité bizarre pour filtrer sur "renseigné" ou "non
renseigné" ne mène à rien: dans un éditeur/requêteur SQL (Toad, SQL*Plus, etc.) l'instruction select count(*) from
CUSTOMER where FIRSTNAME=' [] [] '; donne ==> « 0 ».
Or pour de l'exploration de l'exploration en base (tests de nouveaux champs, simulations d'exports, etc) on peut
évidemment avoir besoin de test si un champ est ou non renseigné...
Que sont ces caractères spéciaux, d'où viennent-ils et surtout comment filtrer en SQL les champs non renseignés dans E.S
?
Merci pour avis.
Olivier Montel
----------------
INSEE / Centre National Informatique Paris
Tél. 0141177654
-----Message d'origine-----
De : Montel Olivier
Envoyé : mercredi 22 février 2006 15:29
À : Eptica Peaucelle (E-mail)
Cc : 'xxx@yyy.zzz'
Objet : Insee/Réponse [de nouveau] Problème modifications / nouveau champ Requête en formulaire Eptica TelSIC
Importance : Haute
Laurent bonsoir,
Je reviens vers toi, d'abord pour le point n° 1.
- 1 - Je suis à nouveau dans l'impossibilité d'implémenter de nouveaux champs de type REQUETE dans un formulaire
EPTICA.
Ici pour le formulaire TelSIC, once again... le nouveau champ inséré est bien créé en BDD (voir deux captures jointes)
mais il n'est pas alimenté quand on utilise le formulaire résultant.
Dans l'exemple de TelSIC ci-joint, le champ s'appelle "Orientel", il est de type radio-boutton et sa mention dans le
source html via "req__Orientel" pose donc à nouveau problème. Ça s'était déjà produit en janvier... puis le problème
avait été levé. A vrai dire sans que je comprenne bien moi-même pourquoi, d'ailleurs...
A présent le problème se pose quelque soit le typage dans le formulaire du nouveau champ souhaité.
Par exemple champ "input ou saisie simple via la syntaxe standard" : .
Test complémentaire : je génère un nouveau Modèles : Formulaires de connexion (par défaut standard via l'interface,
avec coché simple champ BDD nouvellement créé; je copie-colle le source généré par Eptica Server dans mon formulaire
TelSIC... Le squellette standard en question s'ouvre donc bien à la place de mon TelSIC habituel... mais là non plus son
utilisation ne conduit à aucune mise à jour en BDD...
Pourtant le champ est bien alimenté en BDD... quand on passe par la zone de saisie générée par défaut dans l'interface
d'EPTICA (champ "VA") !!
A n'y rien comprendre.
Seul élément nouveau: à présent, chaque tentative, je vois apparaître dans le journal d'évènement : "Request field
orientel is marked as shown in the form:TelSIC but does not exists in DB field list " [voir capture jointe]. Bref: selon
l'interface ET sous outil SQL le champ BDD est bien créé, mais dans la Log tout se passe comme si ça n'était pas le cas
(...)
Je ne comprends par ce qui bloque un fonctionnement pourtant déjà observé antérieurement...
Aurais-tu une idée ? Y aurait-il une manoeuvre complémentaire ou palliative à entreprendre et que j'oublierais ?
---------------------------------------
- 2 - Concernant l'upgrade en V6.5 prévu: nous sommes obliger de repousser. En effet le SPST du CNIP n'est pas
disponible tout prochainement et n'a actuellement pas une bonne visibilité de ses disponibilités courant mars. Donc on
repousse un peu le tout. Désolé, quiand j'en saurais plus moi-même je reviendrais vers toi pour convenir d'un RV avec
toi.
- 3 - J'ai lors de ma dernière tentative de mise à jour des filtres anti-spam un problème en mode Admin: la pose de
nouveaux filtres n'est pas prise en compte par le système. A ma connaissance c'est la première fois que ce problème
survient.
cela se traduit par un warning (rouge) : "Impossible de compiler la valeur du filtre. Voir l'aide pour plus de détails.
ValeurRe[".
Encore plus fort: se produit aussi sur le serveur d'Intégration...
- 4 - enfin ce détail concernant les échanges que tu as pu avoir début février avec certains de nos utilisateurs
concernant un fichier d'export.csv rendu inexploitable sous Excel. J'ai regardé le fichier résultant du filtrage que tu
suggérais. Certes je suis OK qu'il faut éradiquer tant que faire se peut les "poubellisés pour cause de SPAM" avant
export. Mais là, selon moi ça ne résoud pas le problème. Pour ma part, j'avais précédemment tâtonné pour finalement
éliminer la demande référencée 208380... et apparemment ça levait le problème (fichier résultant ouvrable dans Excel).
Merci pour tes avis.
Olivier Montel
----------------
INSEE / Centre National Informatique Paris
Tél. 0141177654
P.J en Captures_Formulaires_220206.zip: 2 capture d'écran relatives à création du champ BDD, capture d'écran du Journal
d'évènement, formulaire HTML TelSIC "incriminé" et formulaire Test3 généré par défaut via > Modèles : Formulaires de
connexion...