Comment j'ai diagnostiqué des problèmes de blocage. Comment j'ai diagnostiqué les problèmes de verrouillage 1c erreur de conflit de verrouillage lors de l'exécution d'une transaction

Je ne pouvais pas écrire les modifications pour le transfert vers une base de données distribuée, j'ai contacté le support 1c et proposé ce qui suit. J'ai décidé de redémarrer simplement le serveur d'applications et le serveur avec SQL. De manière générale, vous pouvez cocher la case "Blocage programmé
tâches incluses"
Cela a également aidé sans redémarrer.

Opérations planifiées au niveau du SGBD pour MS SQL Server

Instructions pour effectuer des opérations de routine au niveau du SGBD.

Les informations s'appliquent à la version client-serveur de 1C:Enterprise 8 lors de l'utilisation du SGBD MS SQL Server.

informations générales

L'exécution incorrecte ou intempestive d'opérations de routine au niveau du SGBD est l'une des causes les plus courantes d'un fonctionnement non optimal du système. Il est particulièrement important d'effectuer ces procédures de routine dans les grands systèmes d'information qui fonctionnent sous une charge importante et desservent simultanément un grand nombre d'utilisateurs. La spécificité de tels systèmes est que les actions habituelles effectuées automatiquement par le SGBD (en fonction des paramètres) ne suffisent pas à un fonctionnement efficace.

Si un système en cours d'exécution présente des symptômes de problèmes de performances, vous devez vérifier que le système est correctement configuré et effectue régulièrement toutes les opérations de maintenance de routine recommandées au niveau du SGBD.

L'exécution des procédures de routine doit être automatisée. Pour automatiser ces opérations, il est recommandé d'utiliser les outils intégrés de MS SQL Server : Plan de maintenance. Il existe également d'autres moyens d'automatiser ces procédures. Dans cet article, pour chaque procédure planifiée, un exemple de sa configuration est donné à l'aide du plan de maintenance pour MS SQL Server 2005.

Il est recommandé de contrôler régulièrement la rapidité et l'exactitude de la mise en œuvre de ces procédures de routine.

Mise à jour des statistiques

MS SQL Server construit un plan de requête basé sur des informations statistiques sur la distribution des valeurs dans les index et les tables. Les informations statistiques sont collectées sur la base d'une partie (échantillon) de données et sont automatiquement mises à jour lorsque ces données changent. Parfois, cela ne suffit pas à MS SQL Server pour construire de manière cohérente le plan le plus optimal pour exécuter toutes les requêtes.

Dans ce cas, des problèmes de performances de requête peuvent se produire. Dans le même temps, des signes caractéristiques de travail non optimal (opérations non optimales) sont observés dans les plans de requête.

Afin de garantir le fonctionnement le plus correct de l'optimiseur MS SQL Server, il est recommandé de mettre à jour régulièrement les statistiques de la base de données MS SQL.

Pour mettre à jour les statistiques de toutes les tables de la base de données, vous devez exécuter la requête SQL suivante :

exec sp_msforeachtable N"MISE À JOUR DES STATISTIQUES ? AVEC ANALYSE COMPLÈTE"

La mise à jour des statistiques n'entraîne pas le verrouillage des tables et n'interfère pas avec le travail des autres utilisateurs. Les statistiques peuvent être mises à jour aussi souvent que nécessaire. Gardez à l'esprit que la charge sur le serveur SGBD lors de la mise à jour des statistiques augmentera, ce qui peut nuire aux performances globales du système.

La fréquence optimale de mise à jour des statistiques dépend de l'ampleur et de la nature de la charge sur le système et est déterminée expérimentalement. Il est recommandé de mettre à jour les statistiques au moins une fois par jour.

La requête ci-dessus met à jour les statistiques de toutes les tables de la base de données. Dans un système réel, différentes tables nécessitent différents taux de mise à jour des statistiques. En analysant les plans de requête, vous pouvez déterminer quelles tables nécessitent les mises à jour de statistiques les plus fréquentes et configurer deux procédures de routine différentes (ou plus) : pour les tables fréquemment mises à jour et pour toutes les autres tables. Cette approche réduira considérablement le temps de mise à jour des statistiques et l'impact du processus de mise à jour des statistiques sur le fonctionnement du système dans son ensemble.

Configuration de la mise à jour automatique des statistiques (MS SQL 2005)

Démarrez MS SQL Server Management Studio et connectez-vous au serveur DBMS. Ouvrez le dossier Gestion et créez un nouveau plan de maintenance :

Créez un sous-plan (Ajouter un sous-plan) et nommez-le "Mise à jour des statistiques". Ajoutez-y la tâche de mise à jour des statistiques depuis la barre des tâches :

Configurez un calendrier de mise à jour des statistiques. Il est recommandé de mettre à jour les statistiques au moins une fois par jour. Si nécessaire, la fréquence de mise à jour des statistiques peut être augmentée.

Définissez les paramètres de la tâche. Pour cela, double-cliquez sur la tâche dans le coin inférieur droit de la fenêtre. Dans le formulaire qui s'affiche, indiquez le nom de la base de données (ou de plusieurs bases de données) pour laquelle les statistiques seront mises à jour. De plus, vous pouvez spécifier pour quelles tables mettre à jour les statistiques (si vous ne savez pas exactement quelles tables vous devez spécifier, définissez la valeur sur All).

La mise à jour des statistiques doit être effectuée avec l'option Analyse complète activée.

Enregistrez le plan créé. Lorsque l'heure spécifiée dans le calendrier arrive, les statistiques sont mises à jour automatiquement.

Vider le cache procédural

L'optimiseur MS SQL Server met en cache les plans de requête pour une réexécution. Ceci est fait afin de gagner du temps lors de la compilation d'une requête si la même requête a déjà été exécutée et que son plan est connu.

Il est possible que MS SQL Server, s'appuyant sur des informations statistiques obsolètes, élabore un plan de requête non optimal. Ce plan sera stocké dans le cache procédural et utilisé lorsque la même requête sera invoquée à nouveau. Si vous avez mis à jour les statistiques mais que vous n'avez pas vidé le cache procédural, SQL Server peut choisir l'ancien plan de requête (non optimal) dans le cache au lieu de créer un nouveau (meilleur) plan.

Pour vider le cache procédural de MS SQL Server, vous devez exécuter la requête SQL suivante :

Cette requête doit être exécutée immédiatement après la mise à jour des statistiques. En conséquence, la fréquence de son exécution doit correspondre à la fréquence de mise à jour des statistiques.

Configuration de l'effacement procédural du cache (MS SQL 2005)

Étant donné que le cache procédural doit être vidé à chaque mise à jour des statistiques, il est recommandé d'ajouter cette opération au sous-plan "Mettre à jour les statistiques" déjà créé. Pour ce faire, ouvrez le sous-plan et ajoutez la tâche d'exécution d'instruction T-SQL à son schéma. Ensuite, vous devez connecter la tâche de mise à jour des statistiques avec une flèche à la nouvelle tâche.

Dans le texte de la tâche d'exécution d'instruction T-SQL créée, vous devez spécifier la requête "DBCC FREEPROCCACHE":

Défragmentation d'index

Lorsque vous travaillez intensivement avec des tables de base de données, l'effet de fragmentation des index se produit, ce qui peut entraîner une diminution de l'efficacité des requêtes.

sp_msforeachtable N"DBCC INDEXDEFRAG (<имя базы данных>, ""?"")"

La défragmentation d'index ne bloque pas les tables et n'interfère pas avec le travail des autres utilisateurs, cependant, elle crée une charge supplémentaire sur SQL Server. La fréquence optimale d'exécution de cette procédure de routine doit être sélectionnée en fonction de la charge du système et de l'effet obtenu à partir de la défragmentation. Nous vous recommandons de défragmenter vos index au moins une fois par semaine.

Il est possible de défragmenter une ou plusieurs tables, pas toutes les tables de la base de données.

Configuration de la défragmentation d'index (MS SQL 2005)

Dans le plan de maintenance créé précédemment, créez un nouveau sous-plan nommé "Réindexer". Ajoutez-y une Tâche de reconstruction de l'index :

Définissez la planification d'exécution de la tâche de défragmentation d'index. Il est recommandé d'exécuter la tâche au moins une fois par semaine, et si les données de la base de données sont très volatiles, encore plus souvent - jusqu'à une fois par jour.

Réindexation des tables de base de données

La réindexation des tables comprend une reconstruction complète des index des tables de la base de données, ce qui conduit à une optimisation significative de leur travail. Il est recommandé d'effectuer une réindexation régulière des tables de la base de données. Pour réindexer toutes les tables de la base de données, vous devez exécuter la requête SQL suivante :

sp_msforeachtable N"DBCC DBREINDEX(""?"")"

La réindexation des tables les bloque pendant toute la durée de leur travail, ce qui peut affecter considérablement le travail des utilisateurs. À cet égard, il est recommandé d'effectuer la réindexation pendant la charge minimale du système.

Après la réindexation, il n'est pas nécessaire de défragmenter les index.

Configuration de la réindexation des tables (MS SQL 2005)

Dans le plan de maintenance précédemment créé, créez un nouveau sous-plan nommé "Index Defragmentation". Ajoutez-y une tâche de reconstruction d'index :

Définissez le calendrier d'exécution de la tâche de réindexation de table. Il est recommandé d'exécuter la tâche pendant la charge minimale du système, au moins une fois par semaine.

Personnalisez la tâche en spécifiant la base de données (ou plusieurs bases de données) et en sélectionnant les tables requises. Si vous ne savez pas exactement quelles tables spécifier, définissez la valeur sur Tous.

Lorsque des centaines d'utilisateurs travaillent avec des programmes et des données en même temps, il n'y a des problèmes inhérents qu'aux solutions à grande échelle. Nous parlons des problèmes causés par les verrous de données.

Parfois, les utilisateurs découvrent des verrous à partir de messages indiquant l'impossibilité d'écrire des données ou d'effectuer une autre opération. Parfois en raison d'une baisse très importante des performances du programme (par exemple, lorsque le temps nécessaire pour effectuer une opération est multiplié par des dizaines ou des centaines).

Les problèmes causés par le blocage n'ont pas de solution générale. Par conséquent, nous essaierons d'analyser les causes de ces problèmes et de systématiser les options pour leur solution.

RAISONS DU BLOCAGE DES TRANSACTIONS

Rappelons-nous d'abord ce que sont les verrous, et en même temps, nous déterminerons s'ils sont nécessaires. Examinons quelques exemples classiques de blocage que nous rencontrons dans la vie.

Exemple 1 : Achat d'un billet d'avion ou de train. Supposons que nous exprimions nos souhaits au caissier. La caissière nous indique la disponibilité des places, parmi lesquelles nous pouvons choisir celle qui nous plaît le plus (s'il y en a plusieurs, bien sûr). Jusqu'à ce que nous choisissions et confirmions notre accord avec l'option proposée, ces sièges ne peuvent être vendus à personne d'autre, c'est-à-dire Bloqué temporairement. S'ils n'étaient pas bloqués, au moment de la confirmation, il pourrait y avoir une situation où les billets que nous avons choisis ont déjà été vendus. Et dans ce cas, le cycle de sélection peut être un nombre imprévisible de répétitions. Pendant que nous choisissons des lieux, mais ils ont déjà été vendus !.. Pendant que nous en choisissons d'autres, et qu'ils ne sont plus là...

Exemple 2 : acheter quelque chose dans un magasin ou un marché. Nous sommes montés au comptoir, avons choisi la plus belle pomme parmi une centaine disponible. Ils ont choisi et mis la main dans leur poche pour de l'argent. À quoi cela ressemblera-t-il si, pendant que nous comptons l'argent, c'est la pomme que nous avons choisie qui sera vendue à l'acheteur arrivé plus tard que nous ?

Ainsi, le blocage en soi est un phénomène nécessaire et utile. C'est grâce au blocage que nous garantissons l'exécution des actions en une seule étape. Et le plus souvent, la mise en œuvre logicielle la moins réussie mène à la négativité, lorsque, par exemple :

• un nombre excessif d'objets (tickets, pommes) est bloqué ;
• le temps de blocage est prolongé de manière déraisonnable.

VERROUILLAGES EXCESSIFS DANS LES CONFIGURATIONS TYPIQUES 1C

Sur les grands projets, en règle générale, nous utilisons 1C:Enterprise. Par conséquent, nous essaierons de décrire des recommandations pratiques pour résoudre les problèmes de blocage en utilisant l'exemple du bundle 1C:Enterprise + MS-SQL.

La 8e génération de 1C:Enterprise offre un très, très bon parallélisme d'utilisation. Simultanément avec une configuration (c'est-à-dire sur une base), avec des serveurs et des canaux de communication normaux, un grand nombre d'utilisateurs peuvent travailler. Par exemple, des centaines de commerçants traitent l'émission ou la réception des marchandises, les économistes calculent simultanément le coût des salaires pour différents départements, les comptables calculent et calculent les salaires, etc.

Mais il y a une raison pour laquelle il y a une opinion contraire - le mythe selon lequel, avec une utilisation simultanée intensive, il est inconfortable ou impossible de travailler avec des solutions basées sur 1C : Enterprise. Après tout, dès que des centaines d'utilisateurs commencent à utiliser des solutions standard pour 1C:Enterprise à l'échelle industrielle, de plus en plus souvent une fenêtre apparaît à l'écran avec une fière inscription : « Erreur lors de l'appel de la méthode de contexte (Record) : Lock conflit lors de l'exécution d'une transaction : ... » et plus loin en fonction du type de serveur SQL utilisé, quelque chose comme « Fournisseur Microsoft OLE DB pour SQL Server : délai d'expiration de la demande de verrouillage dépassé. ...".

Presque toutes les solutions standard dans la mise en œuvre "prête à l'emploi" proposée sont configurées pour la gestion automatique des serrures. « Automatique » ici peut être considéré comme « paranoïaque ». Juste au cas où, lors de la réalisation d'un document, nous bloquons tout ce qui peut y être lié d'une manière ou d'une autre. Il s'avère donc que lorsqu'un utilisateur dépense quelque chose (et parfois écrit simplement), le reste ne peut qu'attendre.

Je vais exprimer mon avis pourquoi 1C a décidé de ne pas personnaliser ses solutions standards pour un parallélisme d'utilisation élevé. Les coûts de main-d'œuvre pour un tel raffinement ne sont pas élevés - quelques "mois-personnes", ce qui n'est pas significatif en termes d'échelle 1C. Je pense que la raison est différente.

Premièrement, un tel raffinement complique considérablement les processeurs pour afficher tous les documents. Cela signifie que pour les consommateurs qui utilisent 1C pour de petites tâches, sans aucun gain, il n'y aura qu'un inconvénient - la complexité de la finalisation d'une configuration typique deviendra plus compliquée. Dans le même temps, les statistiques suggèrent quelle catégorie de clients est le principal alimentateur pour 1C ...

La deuxième raison est enfouie dans les paramètres de base typiques des serveurs SQL, par exemple MS-SQL, qui est encore utilisé plus souvent que d'autres. Il se trouve que les priorités dans les paramètres sont données pour économiser la RAM du serveur et non pour réduire le blocage. Cela conduit au fait que, s'il est nécessaire de verrouiller plusieurs lignes, le serveur SQL prend une décision "économique" pour la mémoire et le processeur - verrouiller toute la table d'un coup !...

Ce sont ces lacunes dans les solutions standard ou les spécificités des paramètres du serveur de base de données utilisé qui sont souvent identifiés avec des problèmes causés par le blocage. De ce fait, les carences techniques entraînent des problèmes d'organisation très importants. Après tout, si un employé reçoit une raison d'être distrait du travail ou justifie pourquoi le travail n'a pas pu être fait, une minorité travaillera efficacement. Eh bien, un message sur le blocage des transactions ou un programme de "ralentissement" est une justification idéale pour laquelle rien ne peut être fait.

RECOMMANDATIONS POUR L'ÉLIMINATION DU BLOCAGE EXCESSIF POUR 1C:ENTERPRISE

Que faire si la solution des problèmes de blocage excessif est si importante ?

Au stade final de la mise en œuvre de tous les grands complexes, il est nécessaire de procéder à un raffinement fin afin d'éliminer les blocages de transaction inutiles. Il est essentiel de résoudre les problèmes pouvant résulter de conditions de blocage ou d'une méthodologie de mise en œuvre insuffisamment développées.

Car Cette opération est extrêmement importante, elle doit être effectuée en permanence. Par conséquent, pour simplifier la mise en œuvre d'un tel raffinement, nous avons élaboré un certain nombre de recommandations de base que nous essayons de respecter. Recommandations reçues et testées sur l'expérience d'un nombre important d'implémentations à grande échelle.

1. Si votre SGBD ou votre système de développement (par exemple, 1C:Enterprise) utilise le verrouillage automatique des données par défaut, désactivez la gestion automatique du verrouillage. Configurez vous-même les règles de blocage, décrivez les critères de blocage pour des tableaux entiers ou des lignes individuelles.
2. Lors de l'élaboration d'un programme, dans la mesure du possible, reportez-vous aux tableaux dans le même ordre.
3. Essayez de ne pas écrire dans la même table plusieurs fois au cours de la même transaction. Si cela est difficile, réduisez au moins la durée entre la première et la dernière opération d'écriture.
4. Analysez la possibilité de désactiver l'escalade de verrous au niveau du serveur SQL.
5. Informez clairement les utilisateurs des raisons de l'impossibilité d'effectuer des actions si elles sont dues à un blocage. Donnez des recommandations accessibles et compréhensibles sur ce qu'il faut faire ensuite.

Si vous regardez attentivement les recommandations, il devient clair que un tel développement est approprié non seulement pour 1C:Enterprise, mais pour tous les systèmes. Peu importe la langue dans laquelle ils sont écrits et le serveur de base de données avec lequel ils travaillent. La plupart des recommandations sont de nature universelle et sont donc également valables lors de l'utilisation de 1C: Enterprise et pour les programmes "auto-écrits" ou d'autres systèmes ERP "en boîte".

PS Saviez-vous que nous proposons une assistance professionnelle pour la mise à jour de 1C au meilleur prix ?

Balises de recherche :

• Verrouillage des transactions
• Suppression des blocages
• Blocage 1C
• blocage
• Conflit de verrouillage
• Conflit de verrouillage lors de l'exécution d'une transaction

Salut tout le monde!

L'autre jour au travail, j'ai rencontré un problème avec les verrous, à savoir le message "Conflit de verrou lors de l'exécution d'une transaction. Le délai d'attente maximal pour l'octroi d'un verrou a été dépassé" a commencé à apparaître.

De toute évidence, il n'y a pas de problème de blocage ici, c'est juste qu'une session a mis un verrou et "oublié" de le supprimer. Dans le même temps, le problème menaçait de graves conséquences - le document Ventes de biens et services n'a pas été réalisé. Environ 100 personnes travaillent dans la base de données à la fois, et il est impossible d'effectuer une opération typique et fréquente !

Il y avait deux solutions : redémarrer le serveur ou rechercher une session ayant échoué. La première solution est simple et rapide, mais, comme quelqu'un l'a déjà écrit ici, vous pouvez redémarrer le serveur jusqu'à ce que vous soyez viré. Décidé d'aller dans le deuxième sens.

Le premier jour - le problème est apparu dans l'après-midi, au début, il semblait que le problème provenait de l'utilisateur distant qui était bloqué dans le configurateur. Il semblait que l'exécution venait de s'arrêter à un moment donné et que le verrou, bien sûr, n'avait pas été libéré. Après quelques heures, nous avons réussi à libérer le configurateur, mais le problème n'a pas disparu. Il était extrêmement indésirable de tuer le configurateur de force, peut-être qu'ils y travaillaient. Après cela, Google a pris le relais. J'ai trouvé un article sur ce site, qui explique comment trouver des verrous dans le SGBD MS SQL, vérifié, il n'y avait pas de verrous au niveau du SGBD. Bizarre. En outre, il y a eu des tentatives pour les ajuster. magazine. Installez-vous, quelle est la prochaine étape ? En 15 minutes, quelques concerts de journaux! Comment les lire, que rechercher ? Inconnue.

J'ai trouvé un article sur la façon de voir ce qui est bloqué via SQL Trace. Même si je le trouve, alors quoi ? J'ai besoin d'une séance !

Plus près de 16h00, quand j'ai réalisé que je ne pouvais pas le tirer plus loin, j'ai fait un redémarrage. Dans l'espoir que cela ne se reproduise plus (et c'était le premier cas en six mois de travail), j'ai poussé un soupir de soulagement, tout a fonctionné. Mais en vain ... Le deuxième jour - la même situation. J'ai creusé pendant une heure et demie, encore une fois des tentatives incompréhensibles de google et ainsi de suite. Aucun résultat. Redémarrez. À la fin de la journée, cela s'est reproduit. Eh bien, je pense que c'est génial, je vais rentrer calmement à la maison et m'asseoir, creuser plus profondément. Je rentre, tout va bien. Malheureusement.

Le troisième jour, j'ai regardé un webinaire et parlé d'un moyen intéressant et efficace de trouver un problème. Rappelé, mais le problème ne se posait plus. Une semaine s'est écoulée et le voici - à nouveau bloquant ! Je me frotte les mains et commence à agir.

La première consiste à configurer le journal. Oui, je ne peux pas m'en passer, mais maintenant je peux le lire. Nous définissons deux événements : le premier est TLOCK, le second est TTIMEOUT. Le premier affiche tous les événements bloquants, le second affiche les blocages qui n'ont pas pu être établis dans le temps imparti. En fait, très probablement, seul TTIMEOUT suffit.

Nous copions le fichier journal technique à l'emplacement prévu, accédons au programme, appelons le verrou, recevons un message et supprimons ou renommons le fichier journal technique. Nous n'avons pas besoin de tonnes d'informations sur d'autres blocages !

Accédez au dossier rphost_PID, recherchez les fichiers texte et recherchez le mot TTIMEOUT. On voit la ligne :

53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID= 2242,Usr=*******,AttenteConnexions=8239

Au fait, il peut y avoir plusieurs dossiers rphost_PID, tout dépend du nombre de processus de travail en cours d'exécution sur le serveur.

Et puis tout est simple : regardez au bout de la ligne - WaitConnections = 8239, c'est notre numéro de CONNEXION. Nous allons à la console du serveur, allons dans Connexions, trouvons ce numéro et regardons le numéro de session. Dans mon cas, il y avait deux sessions par utilisateur - une qui a échoué et une autre. Crash de la session indiquée par le journal technique. Et à propos d'un miracle! Tout a fonctionné, il n'y a pas de limite à la joie! Mais, comme il s'est avéré plus tard, la session n'a pas été suspendue :), ils y ont travaillé. Par conséquent, pour l'avenir, il est conseillé de contacter l'utilisateur et de l'avertir.

À mon avis, une solution assez typique à un problème assez typique. On ne sait pas pourquoi je ne l'ai pas rencontré, peut-être parce que je devais le chercher en cas d'alarme, et lorsque les utilisateurs n'appuyaient pas, il n'était alors pas possible d'effectuer des tests - il n'y avait pas d'erreur.

Il n'est pas rare que lorsque vous travaillez dans 1C, l'erreur "Conflit de verrouillage lors de l'exécution de transactions : le temps d'attente maximal pour l'octroi d'un verrou a été dépassé" se produit. Son essence réside dans le fait que plusieurs sessions tentent d'effectuer simultanément des actions similaires, affectant la même ressource. Aujourd'hui, nous allons découvrir comment corriger cette erreur.

Un grand nombre d'opérations

Tout d'abord, lorsque vous recherchez des raisons, vous devez clarifier le nombre d'utilisateurs travaillant simultanément dans l'infobase dans laquelle une telle erreur est générée. Comme nous le savons, leur nombre maximum peut être assez important. C'est mille cinq mille.

Le mécanisme des verrous et des transactions est décrit dans le guide du développeur. Ils sont utilisés lorsque plusieurs sessions accèdent aux mêmes données en même temps. Il est logique que les mêmes données ne puissent pas être modifiées par différents utilisateurs au même moment.

Vous devez également vérifier si l'un des utilisateurs a commencé le traitement de la modification en masse des données. Cela peut être comme , fermeture du mois et autres. Dans ce cas, après la fin du traitement, l'erreur disparaîtra d'elle-même.

Devoirs planifiés

Il n'est pas rare que la cause de l'erreur réside dans le traitement d'une grande quantité de données. Il est recommandé de faire de telles choses la nuit. Planifiez l'exécution de ces tâches planifiées pendant les heures non ouvrables.

Ainsi, les deux utilisateurs travailleront dans un système stable et les tâches planifiées elles-mêmes seront terminées avec succès, car la probabilité de conflits avec les sessions utilisateur diminuera.

"Sessions bloquées"

Le problème des «sessions bloquées» des utilisateurs est familier à presque tous ceux qui ont rencontré le service 1C. L'utilisateur peut avoir quitté le programme il y a longtemps ou fermé un document, mais sa session reste dans le système. Le problème est le plus souvent unique et il suffit de mettre fin à une telle session via la console administrateur. Les mêmes problèmes peuvent se produire avec les tâches en arrière-plan.

Selon de nombreux commentaires sur Internet, de telles situations sont plus courantes lors de l'utilisation de clés de sécurité réseau. Si la situation de "sessions bloquées" se répète systématiquement, c'est la raison d'une vérification et d'une maintenance approfondie du système et des serveurs (si la base est client-serveur).

Erreurs lors de l'écriture de la configuration

Toutes les configurations typiques sont développées par des spécialistes et des experts qualifiés. Chaque système est soigneusement testé et optimisé pour un travail plus rapide et plus correct.

À cet égard, la cause de l'erreur peut résider dans un code sous-optimal écrit par un développeur tiers. Il peut s'agir d'une requête "lourde" qui bloquera les données pendant une longue période. Il n'est pas rare non plus de construire des algorithmes avec de faibles performances et une violation de la logique.

Il est fort probable qu'un conflit de verrouillage soit survenu précisément à cause d'erreurs du développeur s'il est survenu après la mise à jour du programme. Pour vérifier, vous pouvez simplement "annuler" les améliorations ou refactoriser le code.