Bonjour,
dans notre environnement de production , nous rencontrons une erreur aléatoire qui bloque la saisie au niveau de plusieurs fonctions :
Avez vous une idée de ce que ca peut être ?
Merci
Bonjour,
dans notre environnement de production , nous rencontrons une erreur aléatoire qui bloque la saisie au niveau de plusieurs fonctions :
Avez vous une idée de ce que ca peut être ?
Merci
Bonjour,
j'imagine qu'il y a plusieurs causes possibles mais parmi elles, un conflit dans les compteurs X3. J'ai déjà vu ça par le passé.
pour débloquer, il faut revalider la table mais il faut investiguer pour trouver la cause réelle. Un traitement spé qui verrouille une transaction ?
J'ai revalidé toutes les tables liées à l'erreur mais en vain.
Bonour,
Est-ce que vous avez regardé du coté des traitements verrouillés en surveillance ?
J'ai déjà eu ce problème, c'était un traitement lancé par la compta.
maintenant ils le lance le soir.
certains traitements peuvent en effet verrouiller certaines fonctionnalités
la fonction "processus" devrait pouvoir vous aider à un peu plus cibler la provenance
Bonjour.
Je vois le sujet un peu en retard et j'arrive peut-être après la bataille.
Nous sommes sur V5 et nous avons eu à subir ce problème d'une façon pénalisante (et pénalisante est un doux euphémisme tellement ça nous a cassé les pieds pendant des années .....).
Il s'agit en fait du phénomène de "contention" documenté dans l'aide de X3 de la fonction "paramétrage compteurs".
Chez nous le souci apparaissait lorsque plusieurs workflows de tous types étaient envoyés simultanément par différentes services. En effet, lorsqu'on met un type de séquence "normal", un compteur, donc dans notre cas le compteur de workflows, est en quelque sorte "réservé" jusqu'à sa libération, ce qui faisait que quiconque avait à l'écran une fenêtre de validation de workflow, voire même si un traitement avait planté/bloqué en laissant un verrou dessus, les utilisateurs suivants ne pouvaient obtenir de numéro le workflow suivant et voyaient donc le message que vous avez mentionné.
Nous l'avons résolu définitivement en mettant "Séquence BDD" en type de séquence dans la définition des compteurs de type workflow.
Depuis cela fait partie de nos souvenirs .... ouf .....
Même problème (AVALNUM / WIP) et même solution ici : passer en séquence bdd.
Le problème se présentait en création de commande.
Il est tout de même incroyable que ce compteur ne soit pas paramétré de la sorte en standard.
Bonjour à tous, je déterre ce post car je rencontre aussi ce message.
N'y a t il pas un moyen de trouver l'utilisateur qui verrouille la table, ou le traitement ? via un les processus ou en passant par SQL server ?
Et surtout pouvoir débloquer cela
Sinon le fait de passer en séquence BDD peut poser problème ou non ? des retours d'expériences la dessus serait les bienvenues
Bonjour
Sur le retour d'expérience je peux dire qu'il est ultra positif. Depuis mai 2018 où j'ai donné ma dernière réponse, soit désormais 5 ans d'expérience, le nombre de blocage a été réduit à peau de chagrin et nous n'avons pas du tout été impacté par cette modification de fonctionnement.
Quand à trouver l'utilisateur bloquant, c'est très difficile sur X3. Je n'ai pas trouvé d'autre solution que de passer par la fonction "Processus Oracle", onglet "Verrous", puis de récupérer le numéro de session, puis aller voir à qui appartient cette session dans l'onglet "Processus". Et encore, chez nous, c'est le nom du service pour toutes les sessions ! Autant dire que les investigations n'ont jamais été vraiment poussée.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager