DominoArea.org [Archive]

Bonjour,

Je vous explique mon cas,

J'ai une vue view1 dans le quel je récupère des documents doc1.
J'ai une vue view2 dans le quel je récupère des documents doc2.

A un moment donné mon doc2 est le même document que mon doc1.
Lorsque je fais un set doc2 = view2.getnextdocument(doc2),
si ce document est le même que le doc1, à ce moment là le doc1 se modifie et prends les valeurs du doc2 (pourquoi? un bug?).
Le probleme c'est qu'il prend la valeur "view2" dans la propriété "parentview" est donc le doc1 = view1.getnextdocument(doc1) se plante.

Quelqu'un à t'il déjà eu ce bug (ce bug est très facile à reproduire).

Si quelqu'un peut m'aider à contourner ce problème (en plus ça fait planter mon designer...), je suis en 8.5.3 sous XP.


Merci d'avance.

Personnellement je n'ai jamais été confronté à ce "bug" mais il est envisageable qu'il puisse s'agir d'un problème de cache du document et que les doc1 et doc2 pointe dessus dans ce cache.
Je ne vois pas de solution comme ça pour le contourner, tout dépend de ce que tu veux réalisé dans ton algo; une idée pourrait être de mettre en cache dans une liste les données de ta view1 et de travailler ensuite avec les docs de ta view2, juste une idée.
L'autre idée que tu as du mettre en pratique et d'ouvrir un incident auprès d'IBM pour leur remonter le problème, ils ont peut-être une solution ou un fix en cours de dev.

salut,

que fais tu comme traitement sur tes documents ?

parceque si tu changes des champs qui servent aux select de ta vue il 'est normale que ton code parte en vrille

Bonjour,

Merci pour vos réponses.

En fait j'ai des contacts rattachés à des evenements (je n'ai pas géré de notions parent/enfant, juste l'unid de l'évenement dans le contact).
Il y a un évenement principal et des evenements secondaires et les contacts d'un évenement secondaire ne peuvent se trouver dans l'évenement principal.

L'utilisateur choisi l'évenement principal dans une piclist puis le(s) évenement(s) secondaire(s) dans une 2ème picklist, mon script doit nettoyer les doublons.

Dans la vueprincipal (categorisé par unid evenement) un getdocumentbykey de l'unid de l'evenement puis une boucle qui me prend chaque contact de l'évenement.
A l'interieur de cette boucle je fais un getdocumentbykey du nom du contact (vue catégorisé par contact) puis une boucle, si ce contact est dans un evenement secondaire je supprime celui-ci dans l'évenement principal.
Bien sur le document contact de l'évenement principal est présent dans la vue catégorisée par contact. Ce qui provoque le bug quand il arrive à ce document.

Pour éviter les problèmes liés au doc.remove que l'on connait (déclaré le doc suivant avant etc...) pour l'instant je me contente seulement de renseigner le nom du contact doublons dans un string.
Je touche pas aux document pour éviter les soucis de SELECT.

Je vais remonter l'incident chez IBM (via mon perstataire domino).

Merci beaucoup pour votre aide, je vous tiendrais au courant.

Bonne journée.

Hello,

Pourquoi affiches-tu dans ta 2ème vue le document principal ?!?
Tu n'en as pas besoin vu que l'unid du document "parent" se trouve dans tes documents "enfants".

Bonjour,

il n'y a pas de notion de parent/enfant entre les évenements (donc pas moyen de le différencier dans les vues), c'est l'utilisateur qui choisi le principal et les secondaires avec des picklists, c'est juste pour supprimer les doublons (meme nom prenom date naissance) entre les 2 évenements.

J'ai résolu mon problème en contournant le bug avec notamment des notesdocumentscollections, je crée une collection par évenement, j'ai changer carrément la philosophie de mon code.

Sinon il faut utiliser des entryCollection
Set entryCollection = view.Allentries
Si on traite les documents par entry ça fonctionne (peut-être que ça marche aussi avec les notesdocumentscollections à la place des vues).

J'utilise rarement les collections mais c'est pas mal.

Bonne journée, parallèlement j'ai ouvert un ticket chez IBM.

Bonjour,

Mon prestataire a eu une réponse d'IBM, problème déjà connu mais pas de correctif prévu.

Petit extrait de la réponse:
Our development has already investigated the issue and marked the SPR as Closed/No plans to fix in this codestream...

Bonne journée. Et merci de votre aide.