Discussion :

[xavier.ninane]

Intéressant, est ce que la procédure stockée effectue des actions sur les mêmes fichiers impactés par les hChangeRep?
J'explique mon approche, en lisant l'ensemble des échanges j'ai émis l'hypothèse que le traitement effectué par la procédure stockée n'était pas terminé lors de l'appel des fonctions hChangeRep et cela entrainerait un blocage et un dysfonctionnement des appels de la fonction hChangeRep.

Bonjour,

Merci d'alimenter la réflexion.

Oui, tant la procédure stockée que le HChangeRep et le HSupprime qui suivent travaillent (en partie) sur les mêmes fichiers

A mon sens on doit considérer que les traitements de la procédure stockées sont terminés dans la mesure où elle renvoit un booléen (vrai si les traitements se sont correctement déroulés).
Les HhangeRep qui suivent ne peuvent s'exécuter sans que la procédure stockée ne soit terminée : je suis dans code purement séquentiel

Avez-vous testé le retour de la fonction hChangeRep ?

Je ne l'ai pas testé en tant que tel. Mais j'ai truffé le code de trace qui me permettait de suivre la propriété ..répertoire pour voir sur quel répertoire les fichiers étaient renseignés.
Maintenant, il est possible que ce soit une interrogation "logique" et non une interrogation "physique".
Je vais réaliser ce test et vous reviendrai.

Essayez d'appeler MultiTache avec une attente significative (plusieurs dizaine de secondes) après l'appel de la procédure stockée pour peut être confirmer cette piste.

J'ai envisagé cette piste (une forme de latence du serveur ?!?), mais je ne l'ai fait que sur quelques centièmes de seconde.
Je vais retester avec les délais que vous préconisez.

Bon courage

J'en ai bien besoin

[xavier.ninane]

Temporisation de 120 secondes : aucun effet.

En débogage, la fonction HChangeRep renvoi Vrai

Le plus dingue, c'est que la fonction HSupprime respecte le HchangeRep pour un des deux fichiers traités, et ne le respecte pas pour le 2e fichier.
Ce n'est donc pas systématique.

[dsr57]

Bonjour ,

Merci pour le retour rapide.
Vous avez bien fait attention que la fonction MultiTache attend des millisecondes en paramètre.
A quel moment avez vous appelé la fonction MultiTache ?
Est ce que en debug vous avez le problème ?

Le plus dingue, c'est que la fonction HSupprime respecte le HchangeRep pour un des deux fichiers traités, et ne le respecte pas pour le 2e fichier.
Ce n'est donc pas systématique.

Ce n'est pas systématique ? c'est a dire que le problème ne se produit pas tout le temps ? Est ce toujours le même fichier qui pose problème ?
Quels types d'accès aux fichiers la procédure stockée effectue ?

Bon courage

[xavier.ninane]

Merci de continuer à indaguer avec moi...

Vous avez bien fait attention que la fonction MultiTache attend des millisecondes en paramètre.

Je n'ai pas utilisé la fonction MultiTache, mais la fonction Temporisation comme renseignée sur la documentation : http://doc.pcsoft.fr/fr-FR/?3015012&name=Temporisation
Voici le code (et l'attente a bien été de 2 minutes)

Code :

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

1
2
3
boucle(120)
Temporisation(100,tempoTimer)
FIN

A quel moment avez vous appelé la fonction MultiTache ?

J'ai appelé la fonction Temporisation rigoureusement au même endroit que celui où un HFermeConnexion et un HChangeConnexion résout le problème

Voici le bout de code qui n'est pas respecté : (les balises commentaires permettent d'identifier les scénarii envisagés)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//boucle(120)
// Temporisation(100,tempoTimer)
//FIN
//HFermeConnexion(gcnxConnexionServer)
//HChangeConnexion("*",gcnxConnexionServer)
// On se repositionne dans l'exercice comptable actuel : la clôture s'initie depuis l'exercice antérieur
HChangeRep(journaux,".\" + gnCoproEnCours + "\Compta")
HChangeRep(ecritures,".\" + gnCoproEnCours + "\Compta")
HChangeRep(mouvement,".\" + gnCoproEnCours + "\Compta")
HLitRecherchePremier(journaux,RefJournal,"ANR")
HLitRecherchePremier(ecritures,IDJournaux,journaux.IDJournaux)
nIDEcriture est entier sur 8 = ecritures.IDEcriture
//nNumEnregistrement est entier sur 8
HSupprime(ecritures,hNumEnrEnCours,hIgnoreIntégrité)
HFiltre(mouvement,IDEcriture,nIDEcriture)
POUR TOUT mouvement SUR IDEcriture
 HSupprime(mouvement,hNumEnrEnCours,hIgnoreIntégrité)
FIN
HDésactiveFiltre(mouvement)

Est ce que en debug vous avez le problème ?

De manière très difficile à reproduire, je suis arrivé rarement au résultat escompté, en mode pas à pas. Dans ces (rares) cas, j'attaquais également en parallèle la base via le centre de contrôle.
Sur les dizaines de tests que j'ai effectués il m'est très difficile de reproduire le scénario exact où le mode debug m'a permis d'obtenir le résultat attendu. (et je suis conscient que c'est une (lourde) piste d'investigation)

Ce n'est pas systématique ? c'est a dire que le problème ne se produit pas tout le temps ? Est ce toujours le même fichier qui pose problème ?
Quels types d'accès aux fichiers la procédure stockée effectue ?

Ce n'est pas systématique dans la mesure où ce ne sont pas tous les fichiers qui sont concernés.
C'est par contre systématique dans la mesure où c'est systématiquement le fichier "ecritures" qui pose problème.
J'ai envisagé un (stupide) conflit de nommage du fichier, sait-on jamais : "ecriture" ou "ecritures" : chou vert et vert chou.
J'ai aussi envisagé un problème dans les séquences de HChangeRep : chou vert et vert chou.

La procédure stockée utilise l'accès aux données natif de la connexion définie lors de l'initialisation.
Cette connexion "suit et propage" le HchangeRep dans toutes les procédures qui y font appel ou le modifie.
Je ne pense pas qu'il y'ait un problème de contexte : j'utilise beaucoup de procédures stockées (lourdes en traitement), et jamais je n'ai enregistré d'effet de bords ou d'anomalies.

Bon courage

Vos réflexions me poussent à réfléchir...

[yoshi570]

J'aimes bien les problèmes tordus

Histoire de faire avancer le schmilblick:
Est-ce que avec Hraye() a la place de HSupprime() donne le même problème?

Les fichiers ont-ils des mots de passe?, peut-être u problème a la réouverture automatique du fichier?

PS: Je suis plutôt: bonnet blanc et blanc bonnet
Enfin bon, c'est éléphant rose et rose éléphant tout ça !

[xavier.ninane]

J'aimes bien les problèmes tordus

Moi aussi, quand c'est pas les miens

Est-ce que avec Hraye() a la place de HSupprime() donne le même problème?

Belle piste, mais non.

Code :

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

HRaye(ecritures,hNumEnrEnCours,hIgnoreIntégrité)

Même résultat !

Les fichiers ont-ils des mots de passe?, peut-être u problème a la réouverture automatique du fichier?

Je suis en projet de reproduction : je supprime tout ce qui peut interférer.
J'en suis à éliminer tous les niveaux de complexité.

Pour dire : je suis en train de créer un projet "ab initio" pour voir si c'est HFSQL ou si c'est mon code (et si c'est mon code, merci, bonjour, pour trouver la ligne qui ne le fait pas !)

Ce qui me réconforte, c'est que la communauté s'intéresse au problème.
(Je vais mettre un projet en ligne, dès que j'aurai anonymiser les données)

[dsr57]

Bonjour


Quel type de requête est effectué sur les fichiers dans la procédure stockée (Insert, Update, Delete, Select) ?
Dans ces actions est ce qu'il y a un traitement qui diffère entre le fichier ecriture et les autres

D'autres pistes :

• est ce que les requêtes exécutées sont toutes fermées (HAnnuleDéclaration, HLibèreRequête) ?
• avez ou essayé d'appeler la fonction Hferme()

Bon courage

[Lo²]

Bonjour,

Juste pour signaler que dans l'aide du HChangeRep, il y a cela :

Code :

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

Pour modifier les paramètres de connexion d'un fichier de données non HFSQL, il est conseillé d'utiliser les fonctions HDécritConnexion et HChangeConnexion.

[xavier.ninane]

Pour modifier les paramètres de connexion d'un fichier de données non HFSQL, il est conseillé d'utiliser les fonctions HDécritConnexion et HChangeConnexion

Je travaille exclusivement sur des fichiers HFSQL

[Lo²]

oui mais en Client Serveur.
Si je ne me trompe pas, dans l'aide, le logo HFSQL fait référence aux fichiers classic et C/S, fait référence aux fichiers sur un serveur HF.

Comme courdi95, je suis surpris de l'utilisation du HChangeRep en mode C/S même si en effet il y a un exemple.

[xavier.ninane]

oui mais en Client Serveur.
Si je ne me trompe pas, dans l'aide, le logo HFSQL fait référence aux fichiers classic et C/S, fait référence aux fichiers sur un serveur HF.

Comme courdi95, je suis surpris de l'utilisation du HChangeRep en mode C/S même si en effet il y a un exemple.

Ma lecture est que la désignation HFSQL (et non le logo) englobe l'ensemble des fichiers de type HFSQL, qu'ils soient en local ou en C/S.
Et ma lecture est que ce qui est "non HFSQL" représente tous les autres types de BD.

En tout état de cause, tout mon modèle de données repose sur une arborescence de répertoires et sous répertoires pour lequel le HchangeRep est incontournable.
Ce modèle de données n'est d'ailleurs pas une invention de ma part : on le retrouve derrière de nombreux logiciels de comptabilité.
On pourrait ouvrir un nouveau post pour débattre de la pertinence du HchangeRep en C/S. PCSoft documente cette fonction, fournit des exemples. Je me sers simplement d'une fonction existante.

[xavier.ninane]

Quel type de requête est effectué sur les fichiers dans la procédure stockée (Insert, Update, Delete, Select) ?

Uniquement du SELECT, et dans la grande majorité, des requêtes réalisées via l'éditeur de requêtes

Dans ces actions est ce qu'il y a un traitement qui diffère entre le fichier ecriture et les autres

Au niveau de la procédure stockée, aucune requête n'attaque le fichier ecriture.
Il y a par contre des opérations d'écriture dans ce fichier (HRaz, HEnregistre) et dans d'autres qui eux ne sont pas impactés ensuite par le problème de HchangeRep.

• est ce que les requêtes exécutées sont toutes fermées (HAnnuleDéclaration, HLibèreRequête) ?

C'est un des éléments que j'ai analysés : j'ai déjà vérifié 3 fois que toutes les requêtes étaient bien fermées, et j'ai aussi vérifié que les filtres étaient désactivés.

• avez ou essayé d'appeler la fonction Hferme()

Bien vu, mais j'ai aussi envisagé cette piste.

Ce qui me rend marteau c'est que si je lance un trace sur le fichier ecriture, le trace travaille sur le bon fichier. De même qu'en debug, la lecture des sources de données pointent sur le bon fichier.
Il n'y a que cette fonction HSupprime qui part en vrille.

[yoshi570]

Xavier, en relisant (rapidement) le sujet la seul description de ce qui ce passe est:

Cet enchaînement fout une mélasse sans nom dans les fichiers, supprimant des enregistrement non concernés, et en écrivant là où il ne doit pas.
Cette mélasse se produit au moment d'un HSupprime.

Donc pour moi, le résultat, non voulu, n'est toujours pas clair.

Quel(s) fichier(s) sont impacté(s) ? Que "mouvement" a priori ?
Que ce passe-t-il réellement ? ...



sinon en regardant juste le code, cette syntaxe me parrait bizzare :

Code :

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

1
2
3
4
HFiltre(mouvement,IDEcriture,nIDEcriture)
POUR TOUT mouvement SUR IDEcriture
 HSupprime(mouvement,hNumEnrEnCours,hIgnoreIntégrité)
FIN

Certes, l'aide du pour tout indique:
"•Si la clé donnée au POUR TOUT est la clé renvoyée précédemment par la fonction HFiltre, le filtre sera respecté."

Mais j'aime pas trop les effets cachés (le 2ème effet KissCool peut faire mal)
Essaye avec le code exemple de HFiltre

Code :

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

1
2
3
4
5
6
7
8
CléParcours est une chaîne
 
CléParcours = HFiltre(mouvement,IDEcriture,nIDEcriture)
HLitPremier(mouvement, IDEcriture)
TANTQUE HEnDehors() = Faux
 HSupprime(mouvement,hNumEnrEnCours,hIgnoreIntégrité)
 HLitSuivant(mouvement, IDEcriture)
FIN

[xavier.ninane]

Quel(s) fichier(s) sont impacté(s) ?

Deux fichiers identiques placés dans des sous-répertoire différents :

Le fichier placé dans ./11/Compta/2015/ecritures.fic subit le HSupprime de celui qui a été visé par le HChangeRep et situé dans ./11/Compta/ecritures.fic

Que "mouvement" a priori ?

Qu'est-ce à dire ?

Essaye avec le code exemple de HFiltre

Code :

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

1
2
3
4
5
6
7
8
CléParcours est une chaîne
 
CléParcours = HFiltre(mouvement,IDEcriture,nIDEcriture)
HLitPremier(mouvement, IDEcriture)
TANTQUE HEnDehors() = Faux
 HSupprime(mouvement,hNumEnrEnCours,hIgnoreIntégrité)
 HLitSuivant(mouvement, IDEcriture)
FIN

A priori, le code que vous renseignez n'aura pas d'incidence dans la mesure où le Pour Tout que j'utilise manipule le fichier Mouvement et que sur ce fichier je ne rencontre aucune erreur de pointage. Le Hsupprime sur le fichier Mouvement se déroule au bon endroit renseigné par le HchangeRep.

Je cependant testé votre code, et le problème reste identique.

[yoshi570]

Comme quoi, je n'avais pas bien compris.

Et donc si vous isolez les opérations que sur le fichier "ecritures", en ne faisant absolument rien avec les autres fichiers?
J'ose espérer que ça marche.

[EDM-TAHITI]

Hello,
Dans ce que j'ai lu, il n'est pas fait mention d'un hferme([NomDuFichier]). En effet, dans certains cas, il est nécessaire de fermer le fichier avant de lui indiquer une nouvelle connexion afin que celui-ci la prenne en compte.
Ce changement de rep est possible en HFCS mais je n'y suis pas favorable. En effet, lors d'une modifications d'analyse, certains fichiers peuvent ne pas être pris en compte, pire encore, si les fichiers sont journalés alors cela risque véritablement de poser soucis (plantage de l'application avec un message hors de propos). Dans ce cas, il faut supprimer les fichiers de journaux (?), après avoir arrêté le serveur et tout repart normalement.
Bon dev!

[xavier.ninane]

Hello,
Dans ce que j'ai lu, il n'est pas fait mention d'un hferme([NomDuFichier]). En effet, dans certains cas, il est nécessaire de fermer le fichier avant de lui indiquer une nouvelle connexion afin que celui-ci la prenne en compte.

Le HFerme a été testé (voir plus haut dans les discussions). En tout état de cause, je n'indique pas aux fichiers de nouvelle connexion. L'application travaille sur une et même connexion déclarée à l'ouverture.

Ce changement de rep est possible en HFCS mais je n'y suis pas favorable. En effet, lors d'une modifications d'analyse, certains fichiers peuvent ne pas être pris en compte, pire encore, si les fichiers sont journalés alors cela risque véritablement de poser soucis (plantage de l'application avec un message hors de propos). Dans ce cas, il faut supprimer les fichiers de journaux (?), après avoir arrêté le serveur et tout repart normalement.
Bon dev!

Sur l'application C/S qui pose le soucis lié à ce post, j'ai une analyse de 54 fichiers et la profondeur des sous-répertoires sur le serveur est de 3.
Cette analyse a beaucoup évolué et je n'ai jamais rencontré aucune erreur de propagation de ces modifications. WinDev liste parfaitement tous les sous-répertoires.
La seule subtilité est la création des liaisons entre fichier. WinDev a tendance à pédaler lorsqu'il les propose. Un HCréationSiInexistant au bon endroit et au bon moment permet d'avoir des liaisons qui respectent les différents niveaux de profondeur des sous-répertoires.

Merci pour le retour sur la journalisation (que je n'utilise pas). mais je garde l'info sous le coude.

Concernant l'utilisation du HChangeRep, j'ai constaté que beaucoup le déconseille en C/S. Cependant, dans le cadre d'une architecture multi-sociétés, multi-exercices, personne n'a fait en parallèle de suggestions pour contourner le HChangeRep.
Je reste ouvert à toutes les pistes qui seraient proposées.

[xavier.ninane]

Je suis (mal)heureusement arrivé à créer un projet ab initio qui permet de reproduire exactement le soucis que je rencontre.

Compte tenu de la difficulté d'expliquer tous les tenants et aboutissants du problème, le projet de reproduction me paraît la meilleure issue.
Vous pouvez le télécharger ici: http://1drv.ms/1TirE89

Si l'un ou l'autre d'entre vous pouvait le tester pour confirmer que c'est un comportement reproductible et le cas échéant pour éventuellement pointer l'erreur que j'aurais faite.
Si le comportement est reproductible, sans erreur manifeste, je ferai remonter au ST.

La majorité du processus est documenté dans le code même.
Il ne faut pas chercher de "logique" dans les enchaînements : ce projet n'a pour seul but que de reproduire un enchaînement défaillant.

Le projet contient un jeu de données pour le test qui est situé dans le répertoire EXE. Il faut importer tout le contenu de ce répertoire sur une nouvelle base C/S.
Le serveur créera l'arborescence lors de l'import.
Ne pas oublier de mettre à jour la BDD avec la procédure stockée.

Le test est simple : via la seule fenêtre du projet 1/ se connecter à la BBD créée ; cliquer sur le bouton "Test Enchaînement"
Un STOP ouvrira la fenêtre de debug et vous pourrez constater les anomalies en faisant le pas à pas. A ce stade, le HSupprime aura travaillé dans les mauvais répertoires.

Vous pouvez constater les deux anomalies suivantes que j'ai rencontrées dans ce projet : le serveur considère qu'une autre personne a modifié les enregistrements, alors qu'il n'y a théoriquement qu'une seule connexion établie.
Je vous laisse juger.





Je vous remercie d'avance de tous les retours que vous ferez.

[Nico_tournai]

Bonjour

je suis ce post depuis le début et ca m'intrigue également ce phénomène

à la place du POUR TOUT... HSupprime... , avez vous essayer une requête sql de suppression (DELETE FROM ... WHERE id=..)?
Peut être que le traitement effectué par le moteur windev reste le même.. Ca peut être une façon de contourner votre problème qui sait, sans savoir vraiment ce qui coince finalement avec le HChangeRep et HSupprime...

N'étant pas au bureau, je ne peux pas tester votre projet pour le moment

[xavier.ninane]

à la place du POUR TOUT... HSupprime... , avez vous essayer une requête sql de suppression (DELETE FROM ... WHERE id=..)?

C'est une très belle piste de réflexion !

Et de fait, le code suivant travaille dans le bon répertoire indiqué par le HChangeRep (sans devoir toucher à la connexion initialement ouverte).

Code :

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

1
2
HExécuteRequêteSQL("DeleteProduit",hRequêteDéfaut,"DELETE FROM Produit WHERE Produit.IDProduit =" + nProduits)
HExécuteRequêteSQL("DeleteLigneProduit",hRequêteDéfaut,"DELETE FROM LigneFacture WHERE LigneFacture.IDProduit =" + nProduits)

Et c'est là qu'on se rend compte que ce n'est pas le HSupprime qui est "fautif".
Il semblerait que toutes les fonctions H d'écriture sont impactées car le problème se repose ensuite avec le HEnregistre qui suit dans le code !!!



Il semblerait que ce soucis est donc interne à certaines fonctions H.

Si d'autres utilisateurs confirment ce comportement (reproductibilité) je doute cependant d'arriver à faire bouger PCSoft sur ce problème car à mon avis cela touche au cœur des fonctions H.