Discussion :

[pierrot67]

Bonjour


J'ai une boucle comme ci-dessous qui s'execute correctement sauf qu'il
me reste des enregistrements qu'elle n'a pas prise en compte.
il me semble qu'elle prend un enregistrement sur deux Pourquoi?
BOUCLE :
while datamodule3.Repartitionmclasse.value= datamodule3.ClassegroupClasse.value do
begin
datamodule3.Repartitionm.Edit;
datamodule3.RepartitionmEnseignant.Value :=edit1.text;
datamodule3.Repartitionm.post;


Merci d'avance.

[Bejaia-In]

Il ne manquent pas des "NEXT" dans ta boucle ?

[pierrot67]

Merci pour ta réponse

Mais si c'est une boucle elle doit continuer jusqu'a ce que la condition soit fausse non?

[dd_garion]

Je suis d'avis de rejoindre Bejaia_in

En delphi, tu dois incrémenter le compteur dans la boucle while, contrairement à une boucle for.

Donc,

While myQuery.EOF do
begin
...
...
myQuery.next; // doit s'y trouver explicitement.
end;

Sauf erreur de ma part... mais ce qui me surprend c'est que tu dis que certains enregistrement ont bien été pris en compte ...

[pierrot67]

Exact

donc ma boucle fonctionne mais par exemple sur 30 enregistrements il reste à la fin de la boucle 4 ou 5 qui n'ont pas été éxécutés.

[Bejaia-In]

BOUCLE :
while datamodule3.Repartitionmclasse.value= datamodule3.ClassegroupClasse.value do
begin
datamodule3.Repartitionm.Edit;
datamodule3.RepartitionmEnseignant.Value :=edit1.text;
datamodule3.Repartitionm.post;
Quesqu'il y a ICI ?

[pierrot67]

rien à part le end;

[Cl@udius]

Salut.

Alors dans ce cas Bejaia-In et dd_garion ont raison. Il te manque un next.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
while datamodule3.Repartitionmclasse.value= datamodule3.ClassegroupClasse.value do
begin
  datamodule3.Repartitionm.Edit;
  datamodule3.RepartitionmEnseignant.Value :=edit1.text;
  datamodule3.Repartitionm.post;
  datamodule3.Repartionm.Next;
end;

Une autre solution serait de faire une requête Update.

@+

[TicTacToe]

Exact

donc ma boucle fonctionne mais par exemple sur 30 enregistrements il reste à la fin de la boucle 4 ou 5 qui n'ont pas été éxécutés.

Il ne manque pas forcément un Next.

Il suffit que les champs modifiés fassent partie de l'index pour que l'ordre des enregistrements change pendant l'évolution de la boucle.

--> Ce qui expliquerait pourquoi certains enreg sont modifiés et pas tous, et cela de manière aléatoire (enfin l'impression que c'est aléatoire...).

Est-ce que "RepartitionmEnseignant" fait partie de l'index de la table ventilée ???

[Hauwke]

+10 avec TicTacToe. C'est d'ailleurs pour ce genre de situation qu'il est fortement déconseillé d'utiliser une boucle While sur un critére d'égalité de valeur (valeurs prises directement dans la table concernée, bien sûr, tout autre critére d'égalité restant utilisable sans souci). Le mieux serait

1. De filtrer la table afin de sélectionner les enregistrements valides pour le traitement
2. De mettre une boucle for sur le nombre d'enregistrement renvoyé par le (1)
3. D'effectuer le traitement
4. Optionnel : refaire un tour afin de vérifier que tous les enregistrements traités sont valides

Cordialement,
Hauwke

[Bejaia-In]

Il ne manque pas forcément un Next.

Il suffit que les champs modifiés fassent partie de l'index pour que l'ordre des enregistrements change pendant l'évolution de la boucle.

--> Ce qui expliquerait pourquoi certains enreg sont modifiés et pas tous, et cela de manière aléatoire (enfin l'impression que c'est aléatoire...).

C'est étonnent ce que tu écrit là !
Ca veux dire que lorsqu'on parcours une table en la modifiant, les enregistrements de celle-ci changent de positions a chaque "post" selon l'ordre d'un index et qu'on risque de modifier une 2eme fois le même champ ?

[TicTacToe]

C'est étonnent ce que tu écrit là !
Ca veux dire que lorsqu'on parcours une table en la modifiant, les enregistrements de celle-ci changent de positions a chaque "post" selon l'ordre d'un index et qu'on risque de modifier une 2eme fois le même champ ?

Exact !

Si la modification porte sur un champ, qui fait partie de l'index en cours, c'est exact, et cela débouche soit sur un parcours incomplet (visiblement le cas ici), soit sur une boucle infinie, selon la nature du changement (si l'édit du champ provoque par exemple une remise en tête de table pour une raison X).

[Bejaia-In]

Je viens de tester cette situation, il s'avère que le "post" n'a aucun effet sur l'arrangement de la table, ce qui veux dire qu'on ne passe pas a un autre enregistrement. mais losque aprés un "post" on utilse "next", la table est ventilée selon l'index et on saute plusieurs enregistrements.
Comme notre ami pierrot67 n'utilise pas de "next", d'ou viens le problème alors ?

[dd_garion]

Grrr, ...

Que quelqu'un nous donne l'explication...

... un ptit problème, qui semble anodin au départ, retient l'haleine de millions de télespectateur

Merci à tic tac toc, j'aurai au moins apris à ne pas utiliser de boucle while quand je travail sur un index.

Bonne soirée

[TicTacToe]

Je viens de tester cette situation, il s'avère que le "post" n'a aucun effet sur l'arrangement de la table, ce qui veux dire qu'on ne passe pas a un autre enregistrement. mais losque aprés un "post" on utilse "next", la table est ventilée selon l'index et on saute plusieurs enregistrements.
Comme notre ami pierrot67 n'utilise pas de "next", d'ou viens le problème alors ?

Attention, je n'ai pas dit que l'on changeait d'enreg, mais que l'enreg changeait de position tout en restant sur cet enreg, ce qui est différent.

Pour s'en convaincre, creer une table, avec 'Designation' et 'Reference' par exemple. Créer un Index sur Designation.
Afficher un DBGrid, avec cette table, avec cet Index.

Modifier la désignation dans la DBGrid, et la ligne se replacera au bon endroit une fois le post effectué, pour que le tri soit tenu. Le curseur de la table sera toujours sur cet l'enreg venant d'être modifié.
Si la référence change, l'ordre reste le même...

Il y a plusieurs solutions pour palier a ceci, dont une requête SQL (mais je laisse soins aux spécialistes là...), ou utiliser un table parallèle, ou ne pas utiliser cet index mais un filtres (plus lent), ou bien marquer les clefs dans une liste, et faire des FindKey dans un 'for', on est sur de rien louper, c'en en général se que je fais (une clef est souvent un entier pour moi, donc même bcp d'enreg, ca tient bien, et c'est fiable).

Tout dépend du contexte.

bon code!

[Bejaia-In]

Perso, je n'ai jamais eu ce genre de problème étant donnée que j'utilise majoritarement le SQL.
La solution la plus simple serait de désactiver l'index temporairement par les propriétés [IndexFieldNames=''] ou [IndexName=''], puis de le remettre aprés traitement.

j'aurai au moins apris à ne pas utiliser de boucle while quand je travail sur un index.

C'est pas seulement dans la boucle WHILE, mais dans tout traitement qui modifie le champ indexé.

[pierrot67]

Salut les gars


Je suis content d'avoir créé une discussion au combien
intéressante autour de mon sujet mais la clé du problème je l'ai trouvée. c'était un problème d'accent dans mon cas certains enregistrement n'avais pas d'accent donc la boucle s'arretait et il me restait les enregistrements sur les "bras".
Merci encore pour votre aide.