PC SOFT

GRUPOS DE DISCUSSÃO PROFISSIONAL
WINDEVWEBDEV e WINDEV Mobile

Inicio → WINDEV 2024 → Perte du dernier enregistrement d'un fichier
Perte du dernier enregistrement d'un fichier
Iniciado por s.vignale, jul., 18 2005 2:01 PM - 22 respostas
Publicado em julho, 18 2005 - 2:01 PM
En 5 ans d'utilisation de Windev (5.5 => 9), il m'est arrivé 3 ou 4 fois de perdre le dernier enregistrement d'un fichier, ceci sans respecter les regles d'intégrité de la base de données. Je n'avais jamais pu reproduire le problème que je mettais sur le compte d'une instabilité passagère du système.

Cette fois-ci, pourtant, j'ai un cas où j'arrive à reproduire la disparition du dernier enregistrement.
J'ai voulu gérer les exceptions générales dans mon projet et j'ai donc insérer dans la déclaration globale du projet un code du type :

QUAND EXCEPTION
HRAZ(FichierErreurs)
FichierErreurs.TexteErreur=ExceptionInfo(errComplet)
HAjoute(FichierErreurs)
Ouvre(FenetreAffichageErreur")
FinProgramme()
FIN

En placant un point d'arrêt juste apres le hajoute et en ouvrant WDMAP, je m'apercois que l'enregistrement a bien été ajouté et après le test, il a disparu. Le problème est reproduisible avec un jeu de fichiers dont certains sont endommagés mais pas 'FichierErreur'

Si quelqu'un a une idée de comment quelque chose comme ça, je suis preneur.
Merci d'avance
Publicado em julho, 18 2005 - 4:15 PM
Bonjour,

Deux remarques :

- Dans le cas d'un fichier à fiche unique, utiliser plutôt un fichier texte. La syntaxe en est simple et pratique.

- La perte de fiches survient surtout en l'absence du contexte hyperfile indépendant, ou lorsque plusieurs opérations perturbent les pointeurs.

Par exemple le remplissage d'une combo. Le pointeur est alors sur la dernière fiche et il n'y a plus de cohérence lors de EcranVersFichier.

La fiche écran écrase une fiche fichier qui est soit la première, soit la dernière.

Bien cordialement,

Jacques De Schryver
Publicado em julho, 18 2005 - 5:08 PM
Bonjour,

Deux remarques :

- Dans le cas d'un fichier à fiche unique, utiliser plutôt un fichier texte. La syntaxe en est simple et pratique.

Effectivement, pour ce que j'en fais, j'aurais pu simplement utiliser un fichier texte, mais pour l'instant, ce qui m'intéresse surtout, c'est de savoir comment on peut perdre un enregistrement de façon reproductible

- La perte de fiches survient surtout en l'absence du contexte hyperfile indépendant, ou lorsque plusieurs opérations perturbent les pointeurs.

Par exemple le remplissage d'une combo. Le pointeur est alors sur la dernière fiche et il n'y a plus de cohérence lors de EcranVersFichier.

La fiche écran écrase une fiche fichier qui est soit la première, soit la dernière.

Je suis d'accord, mais ce n'est pas mon cas, mon traitement n'a pas d'incedence graphique (autre que l'ouverture d'une fenetre qui ne change rien au pb), et EcranVersFichier n'est pas utilisé.

Bien cordialement,

Jacques De Schryver


Conclusion: je ne suis pas plus avancé, mais merci quand même
Publicado em julho, 18 2005 - 5:13 PM
Face à ce problème, je me pose d'autres questions.

Combien de fiches contient ce fichier vulnérable ?

Après le HAjoute, quelle clé utilises-tu pour la lecture ?

Y-a-t-il des doublons autorisés ?

Ce fichier est-il parfois réindexé ou optimisé (sinon le faire) ?

Quel est l'ordre qui affiche dans la fenêtre de gestion des erreurs ?

Apparemment, une lecture sur HlitDernier(identifiantunique) serait intéressante.

Ce problème intéresse tout le monde et j'espère que ce fil de discussion va s'étoffer.

Bien codialement,

Jacques De Schryver
Publicado em julho, 18 2005 - 5:18 PM
Bonjour,

je pose plus particulièrement la question à Jacques, tu dis:
Par exemple le remplissage d'une combo. Le pointeur est alors sur la dernière
fiche et il n'y a plus de cohérence lors de EcranVersFichier.
La fiche écran écrase une fiche fichier qui est soit la première, soit la
dernière.


J'avais essayé de trouver de l'aide sur un PB similaire non
reproductible. Celà se passe chez un client et je n'avais jamais pu
"voir" le PB jusqu'à hier.
J'ai rapatrié des données pour grosses modif et j'ai fait un RAD
complet table et fiches de façon à avoir de quoi manipuler.
j'avais une table en lecture sous les yeux et :
une ligne s'est dupliquée au moment de la fermeture de la fenêtre. J'ai
cru à un moment à un effet d'affichage et pour m'assurer de ne pas
avoir révé, je reprends les données d'origine et je compare.
Je retrouve 2 enregistrement totalement identique à part l'identifiant.
L'identifiant de la fiche en trop est celui d'un autre enregistremen,
qui lui bien sûr a été perdu!
je précise le contexte:
les données en question n'avaient jamais été altérées précedement et le
soft est un bête RAD!!! ce ne sont ni les données, ni le soft du client
qui perd ses données mais le phénomène est le même.
Celà est réellement trés inquiétant et je cherche des infos allant dans
ce sens ou mieux des indications pour pallier ce PB.

Jean-daniel





Deux remarques :

- Dans le cas d'un fichier à fiche unique, utiliser plutôt un fichier texte.
La syntaxe en est simple et pratique.

- La perte de fiches survient surtout en l'absence du contexte hyperfile
indépendant, ou lorsque plusieurs opérations perturbent les pointeurs.

Par exemple le remplissage d'une combo. Le pointeur est alors sur la dernière
fiche et il n'y a plus de cohérence lors de EcranVersFichier.

La fiche écran écrase une fiche fichier qui est soit la première, soit la
dernière.

Bien cordialement,

Jacques De Schryver



--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Publicado em julho, 18 2005 - 5:57 PM
Bonjour,

J'ai failli perdre mon boulot pour la même raison.

J'ai donc mis au point une solution qui fonctionne toujours, quel que soit le contexte.

Sur chaque fenêtre, j'affiche l'identifiant unique (et non le numéro d'enregistrement) de la fiche en cours à l'écran.

Ensuite, avant chaque modification, je relis la fiche concernée depuis son fichier grâce à l'identifiant unique.

Bien sûr je ne fais aucun FichierVersEcran.

Ensuite, j'ai la certitude que ma fiche écran et ma fiche fichier sont syncrhonisées, puisque je viens de la relire.

Mon instruction de modification, précédée de EcranVersFichier est donc fiable.

De ce fait, une fiche n'en écrase plus une autre.

Ce mécanisme me semble sain et je l'ai généralisé.

Je peux vous donner des exemple de ce code sous différentes déclinaisons.

Bien cordialement,

Jacques De Schryver

NB : On notera qu'en étendant ce principe aux instructions Suivant et Précédent, on ne tombe plus sur le message Fin de fichier alors que la première se trouve à l'écran !!!

Ceci était la signature d'une lecture de première fiche, suivie d'un remplissage de combo ou zone de liste ou de table, positionnant les pointeurs en fin de fichier. Dès lors la porte était ouverte à des comportements insolents du fichier lors de diverses instructions.
Publicado em julho, 18 2005 - 6:05 PM
Bonjour,
J'ai eu un problème similaire:
J'avais activé la saisie automatique sur une rubrique texte qui me sert de
clef unique.
Lorsque je venais pour modifier cette rubrique sur un enregistrement
existant, il m'écrasait une fiche et m'en créait un autre avec la nouvelle
clef.
J'ai supprimé la saisie automatique et tout est maintenant OK.
Je n'ai pas eu le temps d'envoyer çà au support technique, mais si quelqu'un
d'autre vérifie ce problème, çà serait bien de les contacter !
--
Christophe


"jean daniel" <ns_jean-daniel.hoarau@laposte.net> a écrit dans le message de
news: mn.93967d570edb68eb.26715@laposte.net...

Bonjour,

je pose plus particulièrement la question à Jacques, tu dis:
Par exemple le remplissage d'une combo. Le pointeur est alors sur la
dernière
fiche et il n'y a plus de cohérence lors de EcranVersFichier.
La fiche écran écrase une fiche fichier qui est soit la première, soit la
dernière.

J'avais essayé de trouver de l'aide sur un PB similaire non
reproductible. Celà se passe chez un client et je n'avais jamais pu
"voir" le PB jusqu'à hier.
J'ai rapatrié des données pour grosses modif et j'ai fait un RAD
complet table et fiches de façon à avoir de quoi manipuler.
j'avais une table en lecture sous les yeux et :
une ligne s'est dupliquée au moment de la fermeture de la fenêtre. J'ai
cru à un moment à un effet d'affichage et pour m'assurer de ne pas
avoir révé, je reprends les données d'origine et je compare.
Je retrouve 2 enregistrement totalement identique à part l'identifiant.
L'identifiant de la fiche en trop est celui d'un autre enregistremen,
qui lui bien sûr a été perdu!
je précise le contexte:
les données en question n'avaient jamais été altérées précedement et le
soft est un bête RAD!!! ce ne sont ni les données, ni le soft du client
qui perd ses données mais le phénomène est le même.
Celà est réellement trés inquiétant et je cherche des infos allant dans
ce sens ou mieux des indications pour pallier ce PB.

Jean-daniel





Deux remarques :

- Dans le cas d'un fichier à fiche unique, utiliser plutôt un fichier
texte.
La syntaxe en est simple et pratique.

- La perte de fiches survient surtout en l'absence du contexte hyperfile
indépendant, ou lorsque plusieurs opérations perturbent les pointeurs.

Par exemple le remplissage d'une combo. Le pointeur est alors sur la
dernière
fiche et il n'y a plus de cohérence lors de EcranVersFichier.

La fiche écran écrase une fiche fichier qui est soit la première, soit la
dernière.

Bien cordialement,

Jacques De Schryver


--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

Publicado em julho, 18 2005 - 6:08 PM
Face à ce problème, je me pose d'autres questions.

Combien de fiches contient ce fichier vulnérable ?

Au départ, aucune, mais j'ai fait le test avec une ou plusieurs et ça ne change rien au problème

Après le HAjoute, quelle clé utilises-tu pour la lecture ?

Apres le Hajoute, il n'y a pas de lecture, puisqu'il y a directement un "finprogramme" qui est selon toute vraisemblance lié au problème (avant, l'enregistrement a été crée, hors du programme, il a disparu)

Y-a-t-il des doublons autorisés ?

Non, ca c'est un autre pb que se posent certains et qui, lui, ressemble plus à un problème de programmation ou d'indexation

Ce fichier est-il parfois réindexé ou optimisé (sinon le faire) ?

Le fichier est vide et n'a jamais été utilisé (créé par hcreationsiinexistant quelques minutes plus tôt)

Quel est l'ordre qui affiche dans la fenêtre de gestion des erreurs ?

Si j'ai bien compris la question, la fenetre affiche une erreur de doublon sur un autre fichier (sans lien), qui est elle due à une mauvaise indexation.

Apparemment, une lecture sur HlitDernier(identifiantunique) serait intéressante.

Effectivement, c'était interessant.
1er essai : lecture ok, id=6
2ème essai : lecture ok, id=7, preuve que l'id auto a bien été incrémenté
=>Cela m'a permis au moins de comprendre que contrairement à ce que je pensais, le fichier n'était pas bien indexé (bien que vide et jamais utilisé ?), je l'ai réindexé (et lui seul) et j'ai obtenu le même résultat, mais avec des id=1 puis 2
Conclusion : bien tenté, mais c'est pas encore ça

Ce problème intéresse tout le monde et j'espère que ce fil de discussion va s'étoffer.

Bien codialement,

Jacques De Schryver

Publicado em julho, 18 2005 - 6:14 PM
Pour une meilleure compréhension du contexte, voici comment je procède habituellement (ce qui est très proche de ce que vous décrivez) :

Si ModeAppel=Mode_Creation alors
HRAZ(Fichier)
sinon
Hlitrecherche(Fichier,IdFichier,CleMemorisee)
fin
EcranVersFichier("",Fichier)
Si ModeAppel=Mode_Creation alors
Hajoute(Fichier)
sinon
Hmodifie(Fichier)
fin

Ainsi, je n'ai jamais eu de problème de duplication/suppression à tort, sauf bien sûr celui sur lequel je suis tombé (tout ca me conforte dans mon idée que mon problème n'est pas le même que celui des gens qui utilisent directement le RAD)
Publicado em julho, 18 2005 - 6:24 PM
Bonjour,

Que se passe-t-il si tu utilises HFerme avant FinProgramme ?

Cela devrait permettre au fichier de se mettre à jour avant la fin du programme, à supposer que des tampons soient utilisés à fins d'optimisation.

Cela expliquerait aussi des dysfonctionnements sur d'autres fichiers, si le FinProgramme s'avère brutal dans le contexte.

Le problème devient passionnant...

Jacques De Schryver
Publicado em julho, 18 2005 - 6:41 PM
Je n'ai pas essayé, mais ça m'étonnerait que cela donne quelque chose car comme je suis dans un traitement d'exception, il n'y a aucune fenetre ouverte, hferme devrait renvoyer une erreur je pense.
=> apres essai, il n'y a pas eu d'erreur, mais cela n'a tout de même rien donné :
- le hferme a été ignoré, le programme a continuer (ce qui revient à dire qu'il s'est relancé puisque le code est dans l'init du projet)
- le problème a quand même eu lieu (ce qui est interessant puisque cela voudrait dire que finprogramme n'y est pour rien finalement)
On avance ?
Publicado em julho, 18 2005 - 7:46 PM
Peux-tu faire une recherche sur le nom du fichier ?

S'il y en a plusieurs, à plusieurs endroits, peux-tu vérifier avec WinMap que les fiches perdues ne se trouvent pas sur l'un des autres fichiers que celui auquel tu t'attends ?

Auquel cas, on aura au moins un début de piste.

Comme ces polars où des jumeaux s'amusent à confondre de braves détectives...

A suivre...

Jacques

nb : Imaginon qu'n fichier soit à un endroit donné, puis suivi d'un HChangeRep ?
Publicado em julho, 19 2005 - 10:19 AM
Il y a bien plusieurs fichiers du même nom, mais le risque de hchangerep intempestif est microscopique (système de chgt de dossier mis en place depuis des années et bien vérouillé). De plus, ca n'expliquerait pas pourquoi l'enregistrement se crée bien là où il faut, mais ne disparait que plus tard.
=> j'ai vérifié quand même au cas où (au point où j'en suis...), mais effectivement, RAZ

Si ca continue, la seule solution qu'il me restera si je veux trouver une explication (ou au moins envoyer qq chose à PC Soft) va être de reconstituer un mini-projet reproduisant le problème , ce qui dans ce cas peut être très long (il faut que je simplifie progressivement mon cas tout en vérifiant que le problème periste)
Publicado em julho, 19 2005 - 11:16 AM
J'ai l'explication (ou à peu près), que j'ai trouvé en essayant d'isoler le problème :
Lors du message d'erreur, il y avait une transaction active, et donc le HtransactionFin n'a pas été exécuté. Pendant l'exception, il est donc toujours actif est annule de lui même l'ajout dans mon fichier d'erreur.
Ce qui m'a induit en erreur est que jusque là, je ne pensais qu'on pouvait voir dans WDMap les opérations d'une transaction pendant qu'elle est active, je pensais que ces opérations étaient effectuées à part, sur un fichier temporaire (ce qui semble ne pas être exactement le cas puisque sur mon fichier, l'IDauto a été incrémenté)

Voilà, plus de mystère, la vie est belle, j'ai simplement rajouté un HtransactionAnnule au début de mon traitement d'exception et ca marche tres bien.
Publicado em julho, 19 2005 - 11:20 AM
Bonjour,

Je te suggère de détruire tous les fichiers de mêê nom sauf un.

Ensuite reproduit le bug.

Puis vérifie s'il existe un seul fichier, ou s'il s'en est recréé un.

Là, sont-ils identiques ou en existe-t-il un correct et un autre presque correct.

Nous avançons ?!?

Jacques De Schryver
Publicado em julho, 19 2005 - 11:38 AM
En fait, c'est tragique ... tout cela n'avait absolument aucun rapport avec les fichiers eux-mêmes ni avec le fait qu'au moins 1 était corrompu
Publicado em julho, 19 2005 - 12:28 PM
Bonjour,
j'ai le meme pb que je ne peux pas cerner car j'ai 20 utlisateurs sur la
meme base qui effectue un suivi technique a des phases differentes.
un fichier affaire relié a un fichier dossier.
une affaire a un ou pls dossiers.
chaque dossier a 10 phases de traitement.
je suis passé en WD8 en juillet 2004.
les premiers pb sont apparus fin 2004 a savoir des enregistrements qui ont
remplacés d'autres.
Mon probleme je ne peux reproduire l'incident, c'est aleatoire et on ne le
decouvre que 1 ou 2 mois ou 3 jours apres.
Sur 15000 dossiers une 30 sont dans ce cas.
J'ai régulariser avec le dossier papier et WDMAP.
J'espere avec WD9....
Ma fenetre de saisie a 12 fichier reliés 3 onglets dans chaque onglet 2
autres et une bonne 100 de rubriques.
Voila vous n'etes pas tout seul..



Salutations
Dominique Giraud
Responsable Informatique
S.D.E.E.G
144 Avenue du Médoc
33320 Eysines
Tél : 05.56.16.10.70 Fax : 05.56.16.10.71

**************************************************************************
Ce message électronique et tous les fichiers attachés qu'il
contient sont confidentiels et destinés exclusivement à
l'usage de la personne à laquelle ils sont adressés.
Si vous avez reçu ce message par erreur, merci de le
retourner à son émetteur. La publication, l'usage, la distribution,
l'impression ou la copie non autorisée de ce message et des
attachements qu'il contient sont strictement interdits.

**************************************************************************

"jean daniel" <ns_jean-daniel.hoarau@laposte.net> a écrit dans le message de
news: mn.93967d570edb68eb.26715@laposte.net...

Bonjour,

je pose plus particulièrement la question à Jacques, tu dis:
Par exemple le remplissage d'une combo. Le pointeur est alors sur la

dernière
fiche et il n'y a plus de cohérence lors de EcranVersFichier.
La fiche écran écrase une fiche fichier qui est soit la première, soit la
dernière.

J'avais essayé de trouver de l'aide sur un PB similaire non
reproductible. Celà se passe chez un client et je n'avais jamais pu
"voir" le PB jusqu'à hier.
J'ai rapatrié des données pour grosses modif et j'ai fait un RAD
complet table et fiches de façon à avoir de quoi manipuler.
j'avais une table en lecture sous les yeux et :
une ligne s'est dupliquée au moment de la fermeture de la fenêtre. J'ai
cru à un moment à un effet d'affichage et pour m'assurer de ne pas
avoir révé, je reprends les données d'origine et je compare.
Je retrouve 2 enregistrement totalement identique à part l'identifiant.
L'identifiant de la fiche en trop est celui d'un autre enregistremen,
qui lui bien sûr a été perdu!
je précise le contexte:
les données en question n'avaient jamais été altérées précedement et le
soft est un bête RAD!!! ce ne sont ni les données, ni le soft du client
qui perd ses données mais le phénomène est le même.
Celà est réellement trés inquiétant et je cherche des infos allant dans
ce sens ou mieux des indications pour pallier ce PB.

Jean-daniel





Deux remarques :

- Dans le cas d'un fichier à fiche unique, utiliser plutôt un fichier

texte.
La syntaxe en est simple et pratique.

- La perte de fiches survient surtout en l'absence du contexte hyperfile
indépendant, ou lorsque plusieurs opérations perturbent les pointeurs.

Par exemple le remplissage d'une combo. Le pointeur est alors sur la

dernière
fiche et il n'y a plus de cohérence lors de EcranVersFichier.

La fiche écran écrase une fiche fichier qui est soit la première, soit

la
dernière.

Bien cordialement,

Jacques De Schryver


--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net

Publicado em julho, 19 2005 - 12:32 PM
Bonjour,

Ca c'est une bonne piste.
J'ai commencé à avoir ce PB aprés le passage en version 8...
et ça ne s'est pas arrangé avec la version 9.
J'ai bataillé avec les utilisateurs en criant à la fausse manip, en
mettant des dispositifs de rattrapage des données (lourd, trés lourd)
et enfin j'ai eu le cas sous les yeux!!! donc il y a un vrai problème
de perte de données, contraiment à ce qui m'a été répondu, à savoir que
la perte de données avec windev n'était pas possible.

A suivre de trés prés
Jean-Daniel


dgd a écrit :
Bonjour,
j'ai le meme pb que je ne peux pas cerner car j'ai 20 utlisateurs sur la
meme base qui effectue un suivi technique a des phases differentes.
un fichier affaire relié a un fichier dossier.
une affaire a un ou pls dossiers.
chaque dossier a 10 phases de traitement.
je suis passé en WD8 en juillet 2004.
les premiers pb sont apparus fin 2004 a savoir des enregistrements qui ont
remplacés d'autres.
Mon probleme je ne peux reproduire l'incident, c'est aleatoire et on ne le
decouvre que 1 ou 2 mois ou 3 jours apres.
Sur 15000 dossiers une 30 sont dans ce cas.
J'ai régulariser avec le dossier papier et WDMAP.
J'espere avec WD9....
Ma fenetre de saisie a 12 fichier reliés 3 onglets dans chaque onglet 2
autres et une bonne 100 de rubriques.
Voila vous n'etes pas tout seul..



Salutations
Dominique Giraud
Responsable Informatique
S.D.E.E.G
144 Avenue du Médoc
33320 Eysines
Tél : 05.56.16.10.70 Fax : 05.56.16.10.71

**************************************************************************
Ce message électronique et tous les fichiers attachés qu'il
contient sont confidentiels et destinés exclusivement à
l'usage de la personne à laquelle ils sont adressés.
Si vous avez reçu ce message par erreur, merci de le
retourner à son émetteur. La publication, l'usage, la distribution,
l'impression ou la copie non autorisée de ce message et des
attachements qu'il contient sont strictement interdits.

**************************************************************************

"jean daniel" <ns_jean-daniel.hoarau@laposte.net> a écrit dans le message de
news: mn.93967d570edb68eb.26715@laposte.net...

Bonjour,

je pose plus particulièrement la question à Jacques, tu dis:
Par exemple le remplissage d'une combo. Le pointeur est alors sur la
dernière fiche et il n'y a plus de cohérence lors de EcranVersFichier.
La fiche écran écrase une fiche fichier qui est soit la première, soit la
dernière.

J'avais essayé de trouver de l'aide sur un PB similaire non
reproductible. Celà se passe chez un client et je n'avais jamais pu
"voir" le PB jusqu'à hier.
J'ai rapatrié des données pour grosses modif et j'ai fait un RAD
complet table et fiches de façon à avoir de quoi manipuler.
j'avais une table en lecture sous les yeux et :
une ligne s'est dupliquée au moment de la fermeture de la fenêtre. J'ai
cru à un moment à un effet d'affichage et pour m'assurer de ne pas
avoir révé, je reprends les données d'origine et je compare.
Je retrouve 2 enregistrement totalement identique à part l'identifiant.
L'identifiant de la fiche en trop est celui d'un autre enregistremen,
qui lui bien sûr a été perdu!
je précise le contexte:
les données en question n'avaient jamais été altérées précedement et le
soft est un bête RAD!!! ce ne sont ni les données, ni le soft du client
qui perd ses données mais le phénomène est le même.
Celà est réellement trés inquiétant et je cherche des infos allant dans
ce sens ou mieux des indications pour pallier ce PB.

Jean-daniel





Deux remarques :

- Dans le cas d'un fichier à fiche unique, utiliser plutôt un fichier
texte. La syntaxe en est simple et pratique.

- La perte de fiches survient surtout en l'absence du contexte hyperfile
indépendant, ou lorsque plusieurs opérations perturbent les pointeurs.

Par exemple le remplissage d'une combo. Le pointeur est alors sur la
dernière fiche et il n'y a plus de cohérence lors de EcranVersFichier.

La fiche écran écrase une fiche fichier qui est soit la première, soit la
dernière.

Bien cordialement,

Jacques De Schryver


--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net



--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Publicado em julho, 19 2005 - 1:17 PM
Bonjour,


Grâce à toi, j'ai appris ce qu'était une transaction.

Je suis surpris qu'elle puisse influencer un fichier précisément sans besoin de transaction.

Ainsi tu aurais pu écrire :

// Désactive la gestion des transactions sur le fichier erreurs
HGèreTransaction ( ClienMes_erreurs , Faux )

Toutes ces subtilités s'acquièrent heureusement grâce au forum.

Bon développement,

Jacques De Schryver
Publicado em julho, 19 2005 - 3:48 PM
Bonjour,

Le mieux serait d'envoyer vos éléments de reproduction au Support.

--
Ed en Ligne


"Stéphane VIGNALE" <s.vignale@wanadoo.fr> a écrit dans le message de news:
42db7318$1@news.pcsoft.fr...

En 5 ans d'utilisation de Windev (5.5 => 9), il m'est arrivé 3 ou 4 fois
de perdre le dernier enregistrement d'un fichier, ceci sans respecter les
regles d'intégrité de la base de données. Je n'avais jamais pu reproduire
le problème que je mettais sur le compte d'une instabilité passagère du
système.

Cette fois-ci, pourtant, j'ai un cas où j'arrive à reproduire la
disparition du dernier enregistrement.
J'ai voulu gérer les exceptions générales dans mon projet et j'ai donc
insérer dans la déclaration globale du projet un code du type :

QUAND EXCEPTION
HRAZ(FichierErreurs)
FichierErreurs.TexteErreur=ExceptionInfo(errComplet)
HAjoute(FichierErreurs)
Ouvre(FenetreAffichageErreur")
FinProgramme()
FIN

En placant un point d'arrêt juste apres le hajoute et en ouvrant WDMAP, je
m'apercois que l'enregistrement a bien été ajouté et après le test, il a
disparu. Le problème est reproduisible avec un jeu de fichiers dont
certains sont endommagés mais pas 'FichierErreur'

Si quelqu'un a une idée de comment quelque chose comme ça, je suis
preneur.
Merci d'avance


Publicado em julho, 19 2005 - 4:44 PM
Bonjour,

Si on utilise le RAD et qu'on ajoute une zone de liste ou une combo, on sait que le problème de désynchronisation est lié au parcoirs du fichier, se terminant à la dernière fiche en général.

Même chose pour une table ou une requète.

Donc, éviter ce problème consiste à :

- afficher l'identifiant automatique

- relire la fiche en cours d'affichage

- alors seulement, réaliser la modification

Dès lors, avec ou sans contexte hyperfile indépendant, avec ou sans remplissage de liste ou combo ou table ou requète...

C'est le numéro de fiche (à travers son id) qui sera modifié.

Il est souhaitable également que Suivant, Précédent, Premier, Dernier suivent les mêmes principes. Le message 'Fin de fichier atteinte' ou 'Début de fichier atteint' servent de warning, de clignotant rouge qu'un train est en train de passer...



En espérant avoir été clair,

Jacques De Schryver
Publicado em julho, 19 2005 - 5:12 PM
Bonjour
le pb c'est que je n'ai jamais pu reproduire vonlontairement le
phénomène par contre, je l'ai constaté personnellement.
Comme je disais dans un post précédent, j'ai rapatrié un fichier pour
modif et j'ai fait un rad complet pour le lire.
j'étais entrain de parcourir le fichier par une table RAD, au moment de
la fermeture de celle-ci, j'ai eu le temps d'appercevoir 2 lignes
identiques. En comparant le fichier d'origine et celui sur lequel
j'étais, j'ai constaté une duplication ou plus exactement un
enregistrement qui s'est copié sur un autre en l'écrasant.
Je pense qu'un test à faire c'est de prendre une appli + fichiers de
données et construire un projet RAD puis de parcourir un des fichiers
en espérant que cela se produise.
Jean-daniel



Après mure réflexion, Ed en ligne a écrit :
Bonjour,

Le mieux serait d'envoyer vos éléments de reproduction au Support.

--
Ed en Ligne


"Stéphane VIGNALE" <s.vignale@wanadoo.fr> a écrit dans le message de news:
42db7318$1@news.pcsoft.fr...

En 5 ans d'utilisation de Windev (5.5 => 9), il m'est arrivé 3 ou 4 fois
de perdre le dernier enregistrement d'un fichier, ceci sans respecter les
regles d'intégrité de la base de données. Je n'avais jamais pu reproduire
le problème que je mettais sur le compte d'une instabilité passagère du
système.

Cette fois-ci, pourtant, j'ai un cas où j'arrive à reproduire la
disparition du dernier enregistrement.
J'ai voulu gérer les exceptions générales dans mon projet et j'ai donc
insérer dans la déclaration globale du projet un code du type :

QUAND EXCEPTION
HRAZ(FichierErreurs)
FichierErreurs.TexteErreur=ExceptionInfo(errComplet)
HAjoute(FichierErreurs)
Ouvre(FenetreAffichageErreur")
FinProgramme()
FIN

En placant un point d'arrêt juste apres le hajoute et en ouvrant WDMAP, je
m'apercois que l'enregistrement a bien été ajouté et après le test, il a
disparu. Le problème est reproduisible avec un jeu de fichiers dont
certains sont endommagés mais pas 'FichierErreur'

Si quelqu'un a une idée de comment quelque chose comme ça, je suis
preneur.
Merci d'avance





--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Publicado em julho, 19 2005 - 5:39 PM
Bonjour,
Moi auusi ca a debuter en version 8 pas en7.5 ni les autres avant.

Je pense que ca vient du hlitrecherche en 7.5 est different de la 8 et a la
bascule l'option hidentique n'a pas été mise je viens de le faire pour
eviter que le htrouve est a vrai (avec in id different) alors que hendehors
est a faux, donc pour eviter de tester les deux j'ai mis l'option et
j'attend de voir les resultats..

affaire a suivre..


Salutations
Dominique Giraud
Responsable Informatique
S.D.E.E.G
144 Avenue du Médoc
33320 Eysines
Tél : 05.56.16.10.70 ou 06.73.67.77.68
Fax : 05.56.16.10.71

**************************************************************************
Ce message électronique et tous les fichiers attachés qu'il
contient sont confidentiels et destinés exclusivement à
l'usage de la personne à laquelle ils sont adressés.
Si vous avez reçu ce message par erreur, merci de le
retourner à son émetteur. La publication, l'usage, la distribution,
l'impression ou la copie non autorisée de ce message et des
attachements qu'il contient sont strictement interdits.

**************************************************************************

"jean daniel" <ns_jean-daniel.hoarau@laposte.net> a écrit dans le message de
news: mn.9a787d571d562cfb.26715@laposte.net...

Bonjour,

Ca c'est une bonne piste.
J'ai commencé à avoir ce PB aprés le passage en version 8...
et ça ne s'est pas arrangé avec la version 9.
J'ai bataillé avec les utilisateurs en criant à la fausse manip, en
mettant des dispositifs de rattrapage des données (lourd, trés lourd)
et enfin j'ai eu le cas sous les yeux!!! donc il y a un vrai problème
de perte de données, contraiment à ce qui m'a été répondu, à savoir que
la perte de données avec windev n'était pas possible.

A suivre de trés prés
Jean-Daniel


dgd a écrit :
Bonjour,
j'ai le meme pb que je ne peux pas cerner car j'ai 20 utlisateurs sur la
meme base qui effectue un suivi technique a des phases differentes.
un fichier affaire relié a un fichier dossier.
une affaire a un ou pls dossiers.
chaque dossier a 10 phases de traitement.
je suis passé en WD8 en juillet 2004.
les premiers pb sont apparus fin 2004 a savoir des enregistrements qui

ont
remplacés d'autres.
Mon probleme je ne peux reproduire l'incident, c'est aleatoire et on ne

le
decouvre que 1 ou 2 mois ou 3 jours apres.
Sur 15000 dossiers une 30 sont dans ce cas.
J'ai régulariser avec le dossier papier et WDMAP.
J'espere avec WD9....
Ma fenetre de saisie a 12 fichier reliés 3 onglets dans chaque onglet 2
autres et une bonne 100 de rubriques.
Voila vous n'etes pas tout seul..



Salutations
Dominique Giraud
Responsable Informatique
S.D.E.E.G
144 Avenue du Médoc
33320 Eysines
Tél : 05.56.16.10.70 Fax : 05.56.16.10.71


**************************************************************************
Ce message électronique et tous les fichiers attachés qu'il
contient sont confidentiels et destinés exclusivement à
l'usage de la personne à laquelle ils sont adressés.
Si vous avez reçu ce message par erreur, merci de le
retourner à son émetteur. La publication, l'usage, la distribution,
l'impression ou la copie non autorisée de ce message et des
attachements qu'il contient sont strictement interdits.


**************************************************************************

"jean daniel" <ns_jean-daniel.hoarau@laposte.net> a écrit dans le

message de
news: mn.93967d570edb68eb.26715@laposte.net...

Bonjour,

je pose plus particulièrement la question à Jacques, tu dis:
Par exemple le remplissage d'une combo. Le pointeur est alors sur la
dernière fiche et il n'y a plus de cohérence lors de EcranVersFichier.
La fiche écran écrase une fiche fichier qui est soit la première, soit

la
dernière.

J'avais essayé de trouver de l'aide sur un PB similaire non
reproductible. Celà se passe chez un client et je n'avais jamais pu
"voir" le PB jusqu'à hier.
J'ai rapatrié des données pour grosses modif et j'ai fait un RAD
complet table et fiches de façon à avoir de quoi manipuler.
j'avais une table en lecture sous les yeux et :
une ligne s'est dupliquée au moment de la fermeture de la fenêtre. J'ai
cru à un moment à un effet d'affichage et pour m'assurer de ne pas
avoir révé, je reprends les données d'origine et je compare.
Je retrouve 2 enregistrement totalement identique à part l'identifiant.
L'identifiant de la fiche en trop est celui d'un autre enregistremen,
qui lui bien sûr a été perdu!
je précise le contexte:
les données en question n'avaient jamais été altérées précedement et le
soft est un bête RAD!!! ce ne sont ni les données, ni le soft du client
qui perd ses données mais le phénomène est le même.
Celà est réellement trés inquiétant et je cherche des infos allant dans
ce sens ou mieux des indications pour pallier ce PB.

Jean-daniel





Deux remarques :

- Dans le cas d'un fichier à fiche unique, utiliser plutôt un fichier
texte. La syntaxe en est simple et pratique.

- La perte de fiches survient surtout en l'absence du contexte

hyperfile
indépendant, ou lorsque plusieurs opérations perturbent les pointeurs.

Par exemple le remplissage d'une combo. Le pointeur est alors sur la
dernière fiche et il n'y a plus de cohérence lors de EcranVersFichier.

La fiche écran écrase une fiche fichier qui est soit la première, soit

la
dernière.

Bien cordialement,

Jacques De Schryver


--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net


--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net