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?

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

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.

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

[courdi95]

Autant pour moi ....

Effectivement on peut utiliser HChangeRep en C/S.....

Mais c'est sans doute un peu risqué visiblement.

Donc mauvaise piste pour ton problème. Désolé, je ne vois pas ce qui peut ne pas marcher dans ton cas

[Hemgé]

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

Bonjour,

Ne vous laissez pas submerger par le problème que vous rencontrez au point de commencer à prendre à partie un autre membre qui tente de vous aider.

courdi95 pense - à tort ou à raison - avoir identifié un problème et vous en fait part.
Si vous ne partagez pas son point de vue, faites le lui savoir, mais ne lui reprochez pas d'être inefficace et ne l'accusez pas non plus de vous faire, en quelque sorte, perdre votre temps.
Parce que lui, il perd du temps à tous les coups en vous tentant de vous aider, que son intervention soit décisive ou non.

Bonne journée, avec un zeste de zénitude en plus.

Hemgé

[xavier.ninane]

Donc mauvaise piste pour ton problème. Désolé, je ne vois pas ce qui peut ne pas marcher dans ton cas

Merci d'avoir pris la peine d'y réfléchir.

[courdi95]

Autre piste ? quelle est la version logicielle de la base HFSQL C/S ?

@Hemgé : merci.

[xavier.ninane]

Ne vous laissez pas submerger par le problème que vous rencontrez au point de commencer à prendre à partie un autre membre qui tente de vous aider.
Hemgé

Je n'ai pris personne à partie, et tout en même temps que vous postiez votre "recadrage", je remerciais courdi9 de son intervention.

Tout au plus, voulais-je réorienter la réflexion en considérant le fait qu'un HChangeRep n'est pas interdit en C/S et qu'il semble plutôt qu'une interaction avec la connexion se produit, puisque le contournement du problème réside dans une fermeture de la connexion et une réouverture.

Si mes propos ont prêté à mécompréhension je m'en excuse.

[courdi95]

Peut être est ce aussi un truc qui se marche sur lui même puisque ton HChangeRep est fait visiblement dans une procédure stockée à laquelle tu accèdes avec une connexion que tu modifies ? .... pour en savoir plus il faudrait que tu montres le code de ta procédure stockée...

[xavier.ninane]

Autre piste ? quelle est la version logicielle de la base HFSQL C/S ?

J'ai fait mes tests tant sur la dernière version serveur de la V21 que de la V20.

[xavier.ninane]

Peut être est ce aussi un truc qui se marche sur lui même puisque ton HChangeRep est fait visiblement dans un procédure stockée à laquelle tu accèdes avec une connexion que tu modifies ?

Non : ma procédure stockée est uniquement utilisée pour déléguer des calculs assez lourds au serveur.
La procédure stockée ne procède aucun HchangeRep.

[courdi95]

Sans ton code de tests, je ne vois pas .... Mais bon, pour aujourd'hui, de mon côté, c'est fini.

[xavier.ninane]

Il semblerait que c'est vraiment le fait de faire appel à une procédure stockée (dans l'aspect connexion) qui crée le soucis.
J'ai rapatrié toute la procédure stockée (et toutes les requêtes nécessaires) dans une procédure globale du projet : l'enchaînement ne pose aucun soucis.

Bref, ça reste un mystère.

[Hemgé]

Je n'ai pris personne à partie, et tout en même temps que vous postiez votre "recadrage", je remerciais courdi9 de son intervention.

Tout au plus, voulais-je réorienter la réflexion en considérant le fait qu'un HChangeRep n'est pas interdit en C/S et qu'il semble plutôt qu'une interaction avec la connexion se produit, puisque le contournement du problème réside dans une fermeture de la connexion et une réouverture.

Si mes propos ont prêté à mécompréhension je m'en excuse.

Désolé, mais j'avais eu cette impression.
Je suis donc 'ravi' de m'être trompé.

Hemgé

[dsr57]

Bonjour

Il semblerait que c'est vraiment le fait de faire appel à une procédure stockée (dans l'aspect connexion) qui crée le soucis.
J'ai rapatrié toute la procédure stockée (et toutes les requêtes nécessaires) dans une procédure globale du projet : l'enchaînement ne pose aucun soucis.

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.

Est ce que mon approche est plausible, aucune idée, mais cela donne une piste à votre problème...

Avez-vous testé le retour de la fonction hChangeRep ?
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.


Bon courage