DominoArea.org [Archive]

Bonjour,
j'ai des documents avec plusieurs fois le même champs et des valeurs différentes.
Les documents ont fait l'objet d'un traitement pour une migration vers une nouvelle structure de masque suivi d'un @Command([ToolsRefreshSelectedDocs])
Seuls quelques documents semblent avoir le PB.
Mon problème est de les identifier parmi les 16000 documents que contient la base pour corriger.
J'ai remarqué une info intéressante sur le champs :
Nom du champ : DesCap
Type de données : Texte
Longueur des données : 32 octets
Numéro d'ordre : 126
ID d'élément en double : 1
Indicateurs de champ : SUMMARY
mais je ne sais pas comment y accéder en ls ou en formule pour faire une collection ou une vue .
Merci de votre aide

Quelques compléments :
Si je relance un ToolsRefreshSelectedDocs sur un doc ayant le PB cela supprime le champs ayant Id d'élément en double =0
Les modifications suivante se passent bien sur le champs aussi bien à la main que par des agents.
Lorsque je fais un export XML du doc je ne récupère pas de propriété pouvant correspondre sur l'ITEM ( je n'ai d'ailleurs pas grand chose ... )

la seul facon que je connaisse pour avoir accé au deuxieme item en scripte est de faire un remove sur le premier

Merci LSong. J'en étais arrivé à la même conclusion pour la correction . Cependant il me reste toujours le PB de départ: trouver les documents ayant les champs en double car pas question de supprimer les champs des docs n'ayant pas de problèmes.
l'opération serait possible par le biais d'un ls testant si les champs incriminés sont en double dans le doc ( notesform.fields) et de faire les remove item adéquats, cependant je suis un peu refroidit sur le lancement d'un agent sur les 16000 docs car il semblerait que l'apparition du PB soit lié au volume de traitement lors de la migration ( j'ai migré 11 autres bases ayant 10 fois moins de doc sans avoir le PB)
Le mieux serait d'arriver à les sélectionner dans une vue ..

salut

la solution "Made In Bourrin"

tu boucle sur tout les champs de ton doc pour détecter les doublons et les traiter.

Bon la methode bourrin fonctionne sur une sélection de document et testant si mon champs se trouve pls fois sur le doc je fais le remove du champs incriminé ( pour éviter de virer les $ file et autre champs dépassant leur capacité, je donne une liste de champs à tester)
Reste à voir ce que ça va donner sur 16000 docs ...
Merci de votre aide

16 000 doc t'es un petit joueur
je m'inquiette quand j'arrive vers les 500 mille a 1 millions, mais juste pour le temps de traitement

il se peut qu'un champ soit dédoublé par Domino
par exemple, le champ Body d'un mail venant d'internet avec plusieurs parties MIME
Domino sait le gérer
et en LS tu y accède par un GetFirstItem
et pas besoin de correction

Mais si tu dis que le pb vient d'un code maison de reprise de donnée, il se peut aussi que dans ton traitement tu ai fais un new Item alors qu'il existait déjà
dans ce cas il faut remttre ca d'aplomb

LSong a écrit:16 000 doc t'es un petit joueur
je m'inquiette quand j'arrive vers les 500 mille a 1 millions, mais juste pour le temps de traitement

Personnellement je m'inquieterai bien avant d'arriver à 500mille docs car je me demandrai bien qui peut lire / entretenir/ valider un tel volume de documents

salut

une grosse structure gérant un gros volume de document.

j'ai monté un workflow pour un client qui devait gérer/générer au minimum 1 million de document par an.

sur une seule base et sans archivage ?
comment on fait pour les index dans de tels cas ? je suis vraiment intéressé de savoir comment optimiser ce genre de bases.
Le seul cas que j'ai eu dans le genre générait 600 000 docs par mois et était épuré automatiquement tous les mois , c'était en attendant le pendant en BDD relationnel. Mais il s'agissait de formulaires non pas de documents ( sans pieces jointes, textes ou mises en formes variées et pas de réplication... )

et bien

tu optimise le Lotus script à mort et tu joue avec les index de vue. (par contre après on a plus du tout la même notion de Lotus Script optimiser que le commun des mortels)

et tu prend une GROSSE MACHINE comme serveur, avec une politique d'archivage de la "mort qui tue".

et tu hurle bien fort partout que le premier qui te met le bazar la dedans tu l'écorche vif à la petite cuillère.

Michael DELIQUE a écrit:et tu hurle bien fort partout que le premier qui te met le bazar la dedans tu l'écorche vif à la petite cuillère.

LOL je pense que c'est ce qu'il y a de plus efficace.
ou peut on trouver les fonctions gourmandes en LS? ou l'inverse?

les 2 fonctions gourmande du LS sont

- computewithform à utilisé à dose homéopathique (en d'autre termes quand tu n'a pas d'autre choix)

- getnthdocument (à bannir a tout jamais de tes codes) car la consommation est exponentielle au nombre de document.