Discussion :

[xavier.ninane]

Bonjour,


Je suis confronté à un (gros) soucis sur lequel je cale depuis de nombreux jours.

Comme cela m'est déjà arrivé plusieurs fois, j'ai créé un projet pour avoir un protocole de reproduction (le soucis se pose initialement dans un gros projet) : souvent l'exercice de reproduction permet de prendre du recul et d'identifier son erreur.
Ici, cependant, nada : le problème se reproduit exactement.

Typiquement, l'application de type comptable repose sur une arborescence de sous répertoires qui représentent chacun un exercice.
Le passage d'un exercice à l'autre se fait par un HChangeRep.

L'incident se produit lorsque j'enchaîne deux opérations, dans la même session.
1/ Une des opérations fait appel à une procédure stockée sur le serveur (aucun HChangeRep dans cette opération) ;
2/ La 2e fait des aller-retours entre deux exercices (clôture comptable de l'un, ouverture de l'autre et écritures automatiques liées au changement d'exercice) via des HChangeRep

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.


Si j'interroge la communauté, c'est parce que chaque séquence fonctionne parfaitement, pour autant qu'entre les deux je sorte complétement de l'application.
Je n'arrive pas à identifier ce qui provoque ce comportement quand les séquences sont enchaînées dans la même session...

J'ai vérifié mon code par rapport à la libération des filtres et requêtes (lesquels sont "tués" à la fermeture du programme), aucun soucis de ce côté-là.

J'ai aussi vérifié dans quels répertoires l'application travaillait via une trace du ..répertoire : avec ou sans enchaînement, le répertoire est identique.

J'ai également passé l'ensemble du processus en mode débogage.
J'obtiens des résultats erratiques très difficiles à reproduire (dans ces tests j'ai tantôt visualisé la source de donnés dans le débogueur, tantôt via WDMAP).
Toujours est-il que de temps-en-temps, l'enchaînement, en déboguant pas à pas, n'a posé aucun soucis...

J'en suis venu à envisager un problème de connexion (laquelle est "resetée" quand on ferme le programme).
Et de fait, si je fais précéder le HSupprime par un HfermeConnexion suivi d'un HchangeConnexion, tout rentre dans l'ordre !

Est-ce normal ?
A quoi n'ai-je pas pensé ? Je suis à court de ressources...

D'avance merci.

X.

PS je suis prêt à publier le code, mais je ne sais trop ce qui est pertinent.
Je peux également mettre un projet "test" à disposition.

[xavier.ninane]

Le 1er enchaînement fait appel à une procédure stockée pour laquelle je dois faire référence à une connexion (syntaxe HExécuteProcédure).

Est-ce que l'exécution de cette procédure créerait une interférence sur la connexion initiale ?

En tout état de cause, l'application est lancée sur une connexion qui a été établie dans une variable globale du projet.
Chaque fois que je fais appel à une procédure stockée, je fais référence à cette variable globale pour référencer la connexion nécessaire.

Est-ce une erreur ?
Est-ce que je dois créer des variables de connexion indépendantes lorsque j'exécute des procédure stockées ?
Ou est-ce que je dois protéger ma variable globale de connexion ? (Et comment ?)

Toujours est-il que j'utilise assez bien les procédures stockées, et que c'est la 1e fois que je rencontre un soucis qui en implique une...

Je réfléchis tout haut...

[courdi95]

Je pensais que hchangerep ne marchait qu'avec des fichiers hfsql et pas en c/s ????

Du coup, sans le vouloir, est ce que tu ne serais pas en train de travailler avec des fichiers hfsql alors que tu penses être sur la base pour une partie de ton code?

Pourquoi ne pas travailler avec deux bases c/s et des alias sur les fichiers?

[xavier.ninane]

Du coup, sans le vouloir, est ce que tu ne serais pas en train de travailler avec des fichiers hfsql alors que tu penses être sur la base pour une partie de ton code?

Je ne saisis pas ce que tu envisages. Toujours est-il que ma procédure stockée travaille effectivement sur des fichiers hfsql.

Pourquoi ne pas travailler avec deux bases c/s et des alias sur les fichiers?

Travailler avec deux bases n'est pas approprié pour le modèle de données. Dans un logiciel comptable multi société, l'arborescence est la plus appropriée.

[EDM-TAHITI]

Hello Xavier,
Comme toujours, mes contributions restent à la discrétion des membres du forum. En effet, sur la problématique de départ, il se peut que des modifications interviennent.
aussi, tu es le seul à pouvoir maitriser et apporter ici les solutions que tu juges opportunes.
J'ai ajouté des fonctions qui sont commentées (et les traces qui listent les actions) afin que le projet soit en mesure dès l'installation, de réaliser l'ensemble des concepts de l'analyse sans qu'un informaticien doivent intervenir (gniarf, sale bête).
WinDev a des fonctions très puissantes qui nous permettent de faire le plus simple possible (mais que c'est dure!)
J'y ai mis un peu de mes concepts que j'espère simple, un peu de factorisation, un peu de calculs mais le fond reste le tien.
Allez, nous attendons avec impatience ton retour.
Un jour peut-être, je posterais certains concepts de WinDev qui nous permettent d'aller très vite (si, si).
Bon dev!

[xavier.ninane]

Bonjour à tous,

Je remercie encore vivement Éric qui a consacré son temps et son savoir.

Je me suis attaché à l'analyse du code de son projet. Il utilise les perso dossiers. Et j'avais un peu peur que ce soit cet aspect qui solutionne le problème : cette solution est difficile à mettre en place pour une partie de mon modèle de données.
Mais ce n'est pas, semble-t-il, cet aspect qui résout le problème

En effet, je découvre que le HChangeRep (factorisé) utilise en pratique un HcréationSiInexistant placé après le HChangeRep...
(Pour la petite info, je factorise aussi mes HChangeRep, mais via une indirection. Pas fait dans ce cas-ci, car je devais aller à l'essentiel)

Pour l'honnêteté intellectuelle et un grand merci également, cette analyse rejoint celle yoshi570 que je n'avais pas eu le temps d'analyser en profondeur (il était tard hier...)

Je me pose la question (c'est ma 1e nature ) : pourquoi créer des fichiers qui... existent déjà ?
La philosophie d'Éric est cependant emprunte de sagesse et d'une prudence de sioux : autant s'assurer que les fichiers soient ouverts, et tant qu'à faire créés.

Hop, hop, j'ajoute 3 HCréationSiInexistant :

Code :

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

1
2
3
4
5
6
HChangeRep(Facture,".\" + gnDossierEnCours + "\Compta\")
HChangeRep(LigneFacture,".\" + gnDossierEnCours + "\Compta\")
HChangeRep(Produit,".\" + gnDossierEnCours + "\Compta\")
HCréationSiInexistant(Facture)
HCréationSiInexistant(LigneFacture)
HCréationSiInexistant(Produit)

Et...

Pour info : je n'ai pas fait précéder d'un HFerme. PCSoft indique dans la documentation que la fonction HChangeRep procède automatiquement à la fermeture des fichiers concernés.

Je continue à réfléchir : outre créer le fichier, la fonction HCréationSiInexistant équivaut à la fonction Houvre (documentation PCSoft : "Si le fichier de données existe, ouvre le fichier de données.")
Testons : Je remplace le HCréationSiInexistant par un Houvre.

Et là :

Moi y'en a pas comprendre, mais alors vraiment pas.

Je pense qu'après avoir enquiquiné la communauté, je vais laisser ce Post en l'état : j'ai des solutions de contournement qui ne m'obligent pas de manipuler la connexion existante (et me ferait perdre tous les contextes liés à celle-ci !) :

1/ passer par des requêtes SQL en dur de type DELETE, etc. (Merci Nico_tournai)
2/ faire suivre ce HChangeRep du HCréationSiInexistant avec un mix de factorisation telle que proposée par EDM-TAHITI et yoshi570

J'ai cependant l'intention de griller une de mes 15 cartouches auprès du ST car ce comportement est imprévisible, non documenté et pose quand même de sérieuses questions (le retour du ..répertoire, l'utilisateur "fantôme", le fait que ce problème ne se pose que lors d'un appel à une procédure stockée, etc.). Je pense qu'on doit raisonnablement considérer que c'est une sérieuse anomalie, voire un bug.

Je ne mets donc pas ce post en résolu : je le ferai après le retour (ou pas ) de PCSoft !

Belle journée à tous.

[EDM-TAHITI]

Hello,
Effectivement, le projet en l'état ne peut fonctionner. Déjà, pas de Hferme avant la modification du répertoire, puis, pas de factorisation du changement de répertoire pour les fichiers...
Mais le projet modifié fonctionne avec deux ou trois bricoles que j'ai ajouté. Je laisse le soin à Xavier de nous faire un retour sur la philosophie du projet modifié.
Si tel n'était pas le cas, je vous posterais alors l'ensemble des modifications.
Bon Dev!!!!!!

[xavier.ninane]

Mais le projet modifié fonctionne avec deux ou trois bricoles que j'ai ajouté. Je laisse le soin à Xavier de nous faire un retour sur la philosophie du projet modifié.
Bon Dev!!!!!!

Bonjour Eric,

Ta contribution est telle que je serais très mal venu de mettre un quelconque veto sur la publication de tes modifications.
De prime abord, l'attaque qui est faite du schéma de données en arborescence est différente. En cela, je considère que c'est une contribution très intéressante.

Je teste et triture ton code et reviendrai plus amplement plus tard.

Bien à toi.

X.

[courdi95]

Le 1er enchaînement fait appel à une procédure stockée pour laquelle je dois faire référence à une connexion (syntaxe HExécuteProcédure).

Est-ce que l'exécution de cette procédure créerait une interférence sur la connexion initiale ?

En tout état de cause, l'application est lancée sur une connexion qui a été établie dans une variable globale du projet.
Chaque fois que je fais appel à une procédure stockée, je fais référence à cette variable globale pour référencer la connexion nécessaire.

Est-ce une erreur ?
Est-ce que je dois créer des variables de connexion indépendantes lorsque j'exécute des procédure stockées ?
Ou est-ce que je dois protéger ma variable globale de connexion ? (Et comment ?)

Toujours est-il que j'utilise assez bien les procédures stockées, et que c'est la 1e fois que je rencontre un soucis qui en implique une...

Je réfléchis tout haut...

Faire référence à une variable globale qui stocke la connection ne suffit pas. Il faut auparavant ouvrir cette connexion et vérifier si elle est ouverte

SI HouvreConnexion (gcnMaConnexion) ALORS .....

Ensuite cette connexion qui pointe sur un serveur Hfsql c/s tu peux l'utiliser pour y associer des fichiers hChangeConnexion

Dans mes applications j'ai plusieurs serveurs et je fais des connections dynamiques comme cela.

[xavier.ninane]

Faire référence à une variable globale qui stocke la connection ne suffit pas. Il faut auparavant ouvrir cette connexion et vérifier si elle est ouverte

SI HouvreConnexion (gcnMaConnexion) ALORS .....

Ensuite cette connexion qui pointe sur un serveur Hfsql c/s tu peux l'utiliser pour y associer des fichiers hChangeConnexion

Dans mes applications j'ai plusieurs serveurs et je fais des connections dynamiques comme cela.

C'est comme ça que je fonctionne. J'utilise une variable globale de type connexion : http://doc.pcsoft.fr/fr-FR/?1514073&name=Type_Connexion
Lorsque l'utilisateur se logue, il ouvre la connexion, et tous les fichiers de l'analyse sont associés à cette connexion.

Et chaque fois qu'une opération par procédure stockée doit être faite, c'est cette variable de connexion qui est utilisée.

Je n'ai jamais rencontré de soucis, sauf dans ce fichu enchaînement, et encore, uniquement la partie HSupprime. Les HEnregistre, hlit, etc, fonctionnent parfaitement.

[courdi95]

Si tu utilises hchangeconnexion c'est très bien.

Du coup pourquoi utilises tu hchangerep ? Hchangerep ne doit pas être utilisé sur des données/fichiers gérés par un serveur hfsql .

[xavier.ninane]

Hchangerep ne doit pas être utilisé sur des données/fichiers gérés par un serveur hfsql .

Pourquoi "ne doit pas" ? Si le modèle est tel que l'utilisateur peut passer d'une société à une autre, et au sein de cette société, d'un exercice comptable à un autre, je vois difficilement comment faire sans utiliser le HChangeRep, et sans modéliser les données sous forme d'une arborescence.
Le HchangeRep fonctionne parfaitement en C/S, PCSoft ne déconseille pas cette utilisation, et cette utilisation est d'ailleurs documentée !
Je cite (http://doc.pcsoft.fr/fr-FR/?3044168&name=HChangeRep)
Le chemin d'accès au fichier de données doit être relatif à la base de données présente sur le serveur. Il n'est pas possible d'indiquer un chemin en dehors de la base de données. Si l'on tente d'accéder à des fichiers de données en dehors de la base, une erreur WLangage est affichée.

Je ne comprends dès lors votre assertion : "ne doit pas".

Et en tout état de cause, cela ne me fait pas avancer dans la résolution de mon problème.

[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.