Cum să remediați conflictul de blocare 1s 8.3. Cum am diagnosticat problemele de blocare. Un număr mare de operații efectuate

Nu este neobișnuit când lucrați în 1C să primiți eroarea „Conflict de blocare la executarea tranzacțiilor: timpul maxim de așteptare pentru acordarea unei blocări a fost depășit”. Esența sa constă în faptul că mai multe sesiuni încearcă să efectueze simultan acțiuni similare, afectând aceeași resursă. Astăzi vom afla cum să remediam această eroare.

Un număr mare de operații efectuate

Primul pas în căutarea motivelor este să clarificăm câți utilizatori concurenți sunt în baza de informații în care este generată o astfel de eroare. După cum știm, numărul lor maxim poate fi destul de mare. Aceasta este și o mie și cinci mii.

Mecanismul de blocare și tranzacții este descris în ghidul dezvoltatorului. Ele sunt utilizate atunci când mai multe sesiuni accesează aceleași date simultan. Este logic ca aceleași date să nu poată fi modificate de diferiți utilizatori în același timp.

De asemenea, ar trebui să verificați dacă vreunul dintre utilizatori a început procesarea până la schimbare masivă date. Acest lucru ar putea fi ca, sfârșitul lunii și altele asemenea. În acest caz, după finalizarea procesării, eroarea va dispărea de la sine.

Sarcini programate

Nu este neobișnuit ca cauza unei erori să se afle într-un sistem care procesează cantități mari de date. Este recomandat să faci astfel de lucruri noaptea. Stabiliți un program pentru efectuarea unor astfel de sarcini de rutină în afara orelor de lucru.

În acest fel, utilizatorii vor lucra într-un sistem stabil, iar sarcinile de rutină în sine vor fi finalizate cu succes, deoarece probabilitatea conflictelor cu sesiunile utilizatorilor va fi redusă.

„Sesiuni de lucru”

Problema „sesiunilor blocate” ale utilizatorilor este familiară pentru aproape toți cei care au întâlnit serviciul 1C. Utilizatorul ar fi putut părăsi programul cu mult timp în urmă sau ar fi închis un document, dar sesiunea sa rămâne încă în sistem. Problema este cel mai adesea izolată și este suficient să încheiați o astfel de sesiune prin consola de administrator. Aceleași probleme pot apărea și cu joburile de fundal.

Potrivit numeroaselor comentarii de pe internet, astfel de situații sunt mai frecvente atunci când se utilizează chei de securitate pentru rețea. Dacă situația cu „înghețarea sesiunilor” se repetă sistematic, acesta este un motiv pentru a verifica și întreține temeinic sistemul și serverele (dacă baza de date este client-server).

Erori la scrierea configurației

Toate configurațiile standard sunt dezvoltate de specialiști și experți calificați. Fiecare sistem este testat temeinic și optimizat pentru o funcționare mai rapidă și mai corectă.

În acest sens, cauza erorii poate sta în codul suboptimal scris de un dezvoltator terță parte. Aceasta ar putea fi o solicitare „grea” care va bloca datele pentru o perioadă lungă de timp. Există, de asemenea, cazuri frecvente de construire a algoritmilor cu performanță scăzută și încălcare a logicii.

Există o mare probabilitate ca conflictul de blocare să apară tocmai din cauza erorilor dezvoltate, dacă a apărut după o actualizare a programului. Pentru a verifica, puteți pur și simplu să „retroduceți” îmbunătățirile sau să refactorizați codul.

Ce sunt încuietorile în 1C, de ce sunt necesare și cum să evitați problemele atunci când lucrați cu ele

Cu siguranță mulți dintre voi atunci când utilizați sisteme informatice 1C Enterprise (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) a întâlnit un astfel de fenomen precum blocarea. Mai mult, de regulă, toată lumea numește acest fenomen în mod diferit: „blocare 1C”, „conflict de blocare 1C”, „erori de blocare 1C”, „blocare tranzacție 1C” și alte nume. Să aruncăm o privire rapidă la ce sunt blocajele (nu blocajele), de ce sunt necesare și cum să evitați problemele atunci când lucrați cu ele.

Încuietorile în sine (inclusiv în 1C și alte sisteme) sunt un instrument util care oferă capacitatea de a lucra în mod constant cu resurse partajate. De exemplu, conceptul de „resurse partajate” ne înconjoară pe tot parcursul vieții, de exemplu, în timp ce conduceți o mașină, nimeni altcineva nu o poate conduce. Prin urmare, mașina este o resursă comună. Iar al doilea șofer așteaptă până ajungi tu, de exemplu, soția/soțul tău. Amândoi concurați pentru o resursă comună - o mașină. Cine va conduce mașina momentul actual Definiți la nivel conceptual cum ar trebui să fim sisteme automatizate??? Acesta este motivul pentru care am venit cu un instrument blocare, care asigură organizarea procesului de accesare a unei resurse partajate și definesc o coadă. De regulă, în viață, ca și în sistemele informaționale (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), există o mulțime de resurse partajate, deci există și multe blocaje. Acum al doilea punct important– cât timp va aștepta soția/soțul tău ca mașina să fie eliberată. Este logic să presupunem că nu va dura pentru totdeauna? Prin urmare, blocărilor li se acordă o limită de timeout - altfel cunoscută sub numele de timeout time. Timeout este timpul maxim pe care un participant concurent (soția/soțul) așteaptă ca resursa partajată să fie eliberată. Apoi, ori continuă să aștepte același timp, ori merge. În sistemele de informații 1C, expirarea timpului de expirare se termină cu mesajul „1C lock conflict”, „1C lock errors”, „1C transaction locks”, „Timeout when locking”.

Un detaliu important care trebuie reținut este că blocările (în special în 1C) pot fi explicite (setate de utilizator) și implicite (setate de platforma SQL). În articol vorbim despre blocări explicite, deci sunt întotdeauna folosite într-o tranzacție, prin urmare se dovedește că „1C Blocking” și „1C Transaction Blocking” sunt sinonime.

Am decis că, dacă este depășit timpul de expirare, utilizatorul va primi un mesaj de eroare pentru el, procesul de așteptare în sine arată ca ecranul sistemului de informații 1C este blocat; Probabilitatea apariției unui mesaj de timeout (eroare utilizator 1C) este afectată de următorii indicatori:

• Multe 1C blochează o tranzacție;
• Durata tranzacției.

Pentru a minimiza mesajele asociate cu erorile de blocare, este necesar fie reducerea numărului de blocări (optimizarea selectivității), fie reducerea duratei tranzacțiilor.
Acum să determinăm cum acești indicatori pot fi influențați într-un sistem informatic real 1C.

Pentru a reduce multe blocaje:

În 1C: Enterprise 7.7:

Sistemul informatic 1C 7.7. Pentru blocare se folosesc încuietori de masă, care paralizează munca utilizatorilor. De regulă, mai mult de 50 de persoane dintr-o bază de date nu pot lucra fără erori, iar problemele pot apărea și în bazele de date a 20 de utilizatori.
Soluţie:

• Încuietori flexibile 1C de la compania Softpoint. Cu ajutorul lor, nu numai că veți optimiza multe încuietori (înlocuirea blocărilor de masă cu blocări de utilizator), ci și veți accelera selecțiile, căutările și rapoartele.

În 1C:Enterprise 8.x:
Sistemul informatic 1C 8.1., 1C 8.2., 1C 8.3. în modul automat folosește încuietori redundante de tipul (REPEATABLEREAD, SERIALIZABLE). Acest lucru are ca rezultat o experiență de utilizator degradată de 100 sau mai mult.
Soluţie:

• Încuietori gestionate 1C - un instrument încorporat al platformei 1C pentru configurarea mai selectivă a încuietorilor. Pentru a-l folosi, programatorul trebuie să scrie operatori speciali în locurile potrivite din cod pentru a-i bloca pe cei necesari ( dupa parerea lui!) înregistrări în tabelele sistemului informatic;
• Încuietori flexibile 1C - Tehnologie Softpoint pentru înlocuirea încuietorilor standard cu unele personalizate.

Pentru a reduce timpul de tranzacție:

Pentru orice sisteme informaționale 1C (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3) ca și pentru alte sisteme informaționale, sunt utilizate abordări similare:

Verificați și setare corectăîntreținerea de rutină a bazei de date (întreținerea fișierelor, indexuri, statistici, baze de date temporare de tabele, configurare Windows și SQLServer);

Analiza și optimizarea interogărilor grele 1C și SQL (ajustarea indexului, rescrierea interogărilor);

Verificarea redundanței tranzacției. În multe cazuri, operațiunile sunt incluse în mod nerezonabil într-o tranzacție fără a realiza modul în care aceasta va afecta durata și, odată cu aceasta, performanța.

1. Dacă doriți să rezolvați în mod independent problemele tehnice de performanță ale 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) și ale altor sisteme informaționale , atunci pentru tine există o listă unică de articole tehnice în Almanahul nostru (Blocarea și blocajele, încărcarea grea pe CPU și discuri, întreținerea bazei de date și reglarea indexului sunt doar o mică parte din materialele tehnice pe care le vei găsi acolo).
2. Dacă doriți să discutați problemele de performanță cu expertul nostru sau să comandați o soluție de monitorizare a performanței PerfExpert, apoi lăsați o cerere și vă vom contacta în cel mai scurt timp posibil.

Salutare tuturor!

Zilele trecute, la serviciu, am întâlnit o problemă de blocare, și anume mesajul „Există un conflict de blocare în timpul executării unei tranzacții. Timpul maxim de așteptare pentru acordarea unei blocări a fost depășit”.

Evident, nu există nicio problemă de blocaj aici, doar o sesiune a pus o blocare și a „uitat” să o elimine. În același timp, problema amenința cu consecințe grave - documentul Vânzări de bunuri și servicii nu a fost efectuată. Aproximativ 100 de oameni lucrează în baza de date simultan și este imposibil să efectuați o operație tipică și frecventă!

Au existat două soluții - reporniți serverul sau căutați o sesiune eșuată. Prima soluție este simplă și rapidă, dar, așa cum a scris cineva deja aici, puteți reporni serverul până când sunteți concediat. Am hotărât să merg pe a doua cale.

Prima zi - problema a apărut în timpul zilei la început părea că problema era cu un utilizator de la distanță care se autentificase în Configurator. Părea că execuția pur și simplu s-a oprit la un moment dat, iar blocarea, desigur, nu a fost eliminată. După câteva ore, am reușit să lansăm configuratorul, dar problema nu a dispărut. Era extrem de nedorit să ucizi forțat configuratorul, poate că lucrau în el. După aceea, Google a intrat în joc. Am găsit un articol pe acest site care spune cum să găsești încuietori într-un SGBD MS SQL, verificat, nu existau încuietori la nivel de SGBD. Ciudat. În continuare, au fost încercări de a configura tehnologie. revistă. Configurați-o, ce urmează? În 15 minute, câteva concerte de bușteni! Cum să le citești, ce să cauți? Necunoscut.

Am găsit un articol despre cum să vezi ce este blocat folosind SQL Trace. Chiar dacă îl găsesc, ce urmează? Am nevoie de o sesiune!

Mai aproape de ora 16:00, când mi-am dat seama că nu mai pot aștepta, am făcut un reboot. Sperând că acest lucru nu se va mai întâmpla (și aceasta a fost prima dată în șase luni de muncă), am răsuflat ușurat, totul a funcționat. Dar degeaba... A doua zi - aceeași situație. Am săpat timp de o oră și jumătate, iar încercări de neînțeles de a căuta pe google și așa mai departe. Niciun rezultat. Reporniți. La sfârșitul zilei s-a întâmplat din nou. Ei bine, cred că este grozav, voi veni calm acasă și voi sta și voi săpa. Vin acasă, totul este bine. Din pacate.

În a treia zi am urmărit webinarul, au vorbit despre un interesant și mod eficientîn căutarea unei probleme. Mi-am amintit, dar problema nu a mai apărut. A trecut o săptămână și iată-l - blocaje din nou! Îmi frec mâinile și încep să acționez.

Mai întâi, configurați jurnalul. Da, nu mă pot lipsi, dar acum știu să o citesc. Am stabilit două evenimente: primul este TLOCK, al doilea este TTIMEOUT. Primul afișează toate evenimentele de blocare, al doilea arată evenimentele de blocare care nu au putut fi instalate în timpul alocat. De fapt, cel mai probabil doar TTIMEOUT este suficient.

Copiem fișierul jurnal tehnic în locul desemnat, zburăm în program, apelăm blocarea, primim un mesaj și eliminăm sau redenumim fișierul jurnal tehnic. Nu avem nevoie de tone de informații despre alte blocări!

Accesați folderul rphost_PID, găsiți fișierele text și căutați cuvântul TTIMEOUT. Vedem linia:

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=*******,WaitConnections=8239

Apropo, pot exista mai multe foldere rphost_PID, totul depinde de câte procese de lucru rulează pe server.

Și apoi totul este simplu: uită-te la sfârșitul liniei - WaitConnections = 8239, acesta este numărul nostru CONNECTION. Mergem la consola serverului, mergem la Conexiuni, găsim acest număr și ne uităm la numărul sesiunii. În cazul meu, au existat două sesiuni per utilizator - cea nereușită și alta. Sesiunea către care a indicat jurnalul tehnic s-a prăbușit. Și iată și iată! Totul a funcționat, bucuria nu are limite! Dar, după cum s-a dovedit mai târziu, sesiunea nu a fost înghețată :), ei lucrau în ea. Prin urmare, pe viitor, este recomandabil să contactați utilizatorul și să avertizați.

În opinia mea, o soluție destul de standard la o problemă destul de standard. Nu se știe de ce nu l-am dat peste el, poate pentru că a trebuit să-l caut din alarmă, iar când utilizatorii nu l-au apăsat, nu a fost posibil să efectuez teste - nu a existat nicio eroare.

Când sute de utilizatori lucrează simultan cu programe și date, apar probleme care sunt caracteristice doar soluțiilor la scară largă. Vorbim despre probleme cauzate de blocarea datelor.

Uneori, utilizatorii învață despre blocare din mesaje care indică faptul că nu pot scrie date sau nu pot efectua alte operațiuni. Uneori din cauza unei scăderi foarte semnificative a performanței programului (de exemplu, când timpul necesar pentru efectuarea unei operații crește de zeci sau sute de ori).

Problemele cauzate de blocare nu au solutie generala. Prin urmare, vom încerca să analizăm cauzele unor astfel de probleme și să sistematizăm opțiunile de rezolvare a acestora.

MOTIVE PENTRU BLOCAREA TRANZACȚIILOR

Să ne amintim mai întâi ce sunt încuietori și, în același timp, să ne dăm seama dacă sunt necesare. Să ne uităm la câteva exemple clasice de blocaje pe care le întâlnim în viață.

Exemplul 1: cumpărarea unui bilet de avion sau de tren. Să presupunem că ne-am exprimat dorințele casierului. Casiera ne spune disponibilitatea locurilor disponibile, din care putem alege pe cel care ne place cel mai mult (daca sunt mai multe, bineinteles). În timp ce selectăm și confirmăm acordul nostru cu opțiunea propusă, aceste locuri nu pot fi vândute nimănui altcineva, de exemplu. sunt temporar „blocate”. Dacă nu erau blocate, atunci până la momentul confirmării ar putea exista o situație în care biletele selectate de noi au fost deja vândute. Și în acest caz, ciclul de selecție poate avea un număr imprevizibil de repetări. În timp ce noi alegem locuri, au fost deja vândute!.. În timp ce noi alegem altele, și nu mai sunt acolo...

Exemplul 2: cumpărând ceva dintr-un magazin sau dintr-un bazar. Ne-am apropiat de tejghea și am ales cel mai frumos măr dintre sutele disponibile. Au ales-o și au băgat mâna în buzunare după bani. Cum va arăta dacă, în acel moment, în timp ce numărăm banii, mărul ales de noi va fi vândut unui cumpărător care a venit mai târziu decât noi?

Astfel, blocarea în sine este un fenomen necesar și util. Datorită blocării, garantăm că acțiunile sunt finalizate într-un singur pas. Și cel mai adesea nu este cea mai reușită implementare care duce la negativitate. software când, de exemplu:

• un număr excesiv de obiecte (bilete, mere) sunt blocate;
• Timpul de blocare este prelungit nejustificat.

BLOCARE EXCESIVĂ ÎN CONFIGURAȚII TIPICE 1C

Pe proiecte majore, de regulă, folosim 1C:Enterprise. De aceea recomandari practice Vom încerca să descriem soluții pentru problemele de blocare folosind exemplul combinației 1C:Enterprise + MS-SQL.

A 8-a generație de 1C:Enterprise oferă un paralelism de utilizare foarte, foarte bun. Poate funcționa simultan cu o singură configurație (adică pe o singură bază) cu servere și canale de comunicație normale cantitate uriașă utilizatorii. De exemplu, sute de depozitari procesează emiterea sau primirea mărfurilor, economiștii calculează simultan costurile cu forța de muncă pentru diverse departamente, contabilii efectuează calcule și salarii etc.

Dar există un motiv pentru care există o opinie contrară - mitul că, cu utilizare simultană intensivă, lucrul cu soluții bazate pe 1C:Enterprise este incomod sau imposibil. La urma urmei, de îndată ce soluțiile standard pentru 1C:Enterprise încep să fie folosite de sute de utilizatori scara industriala, tot mai des apare pe ecran o fereastră cu o inscripție mândră: „Eroare la apelarea metodei contextului (Scrie): Conflict de blocare la executarea unei tranzacții: ...” și apoi, în funcție de tipul de server SQL folosit, ceva de genul „Microsoft OLE DB Provider for SQL Server: Perioada de expirare a cererii de blocare a fost depășită. ...".

Aproape toate soluțiile standard din implementarea propusă out-of-the-box sunt configurate pentru gestionarea automată a încuietorilor. „Automat” aici poate fi perceput ca „paranoic”. Pentru orice eventualitate, la procesarea oricărui document, blocăm tot ce ar putea fi cumva legat de acesta. Deci, se dovedește că atunci când un utilizator face ceva (și uneori doar îl notează), restul poate doar aștepta.

Îmi voi exprima părerea de ce 1C a decis să nu-și configureze soluțiile standard pentru utilizare în paralel. Costurile forței de muncă pentru o astfel de modificare nu sunt mari - câteva „luni de om”, ceea ce nu este semnificativ pe scara 1C. Mi se pare că motivul este altul.

În primul rând, o astfel de modificare complică semnificativ procesarea tuturor documentelor. Aceasta înseamnă că pentru acei consumatori care folosesc 1C pentru sarcini mici, fără nici un câștig, va exista doar un dezavantaj - dificultatea de a modifica configurația standard va deveni mai complicată. Statisticile sugerează, în același timp, care categorie de clienți este principalul jgheab de hrănire pentru 1C...

Al doilea motiv este îngropat în setările de bază tipice ale serverelor SQL, de exemplu, MS-SQL, care este încă folosit mai des decât altele. Se întâmplă că prioritățile în setări sunt date pentru salvare RAM servere în loc să reducă blocarea. Acest lucru duce la faptul că, dacă este necesar să blocați mai multe rânduri, serverul SQL ia o decizie de „economisire a memoriei și a procesorului” - să blocheze întregul tabel deodată!...

Acestea sunt neajunsurile soluții standard sau specificul setării serverului de baze de date utilizat este adesea identificat cu probleme cauzate de blocare. Ca urmare, deficiențele tehnice duc la foarte semnificative probleme organizatorice. La urma urmei, dacă unui angajat i se oferă un motiv pentru a fi distras de la muncă sau pentru a justifica de ce munca nu a putut fi făcută, o minoritate va lucra eficient. Ei bine, un mesaj despre blocarea tranzacțiilor sau un program de „frânare” este o justificare ideală pentru ce nu s-a putut face ceva.

RECOMANDĂRI PENTRU ELIMINAREA BLOCĂRILOR EXCESIVE PENTRU 1C:ENTERPRISE

Ce să faci dacă rezolvarea problemelor de blocare excesivă este atât de importantă?

La etapa finală de implementare a tuturor complexe mari este necesar să se efectueze o reglare fină pentru a elimina blocarea inutilă a tranzacțiilor. Este esențial să se rezolve problemele care pot apărea din cauza condițiilor de blocare sau a tehnicilor de implementare insuficient dezvoltate.

Deoarece Această operație este extrem de importantă și trebuie efectuată în mod constant. Prin urmare, pentru a simplifica astfel de modificări, am dezvoltat o serie de recomandări de bază pe care încercăm să le respectăm. Recomandări primite și testate din experiența unui număr semnificativ de implementări la scară largă.

1. Dacă DBMS sau sistemul de dezvoltare pe care îl utilizați (de exemplu, 1C:Enterprise) utilizează implicit modul automat de blocare a datelor, refuzați gestionarea automată a blocării. Configurați singur regulile de blocare, descrieți criteriile pentru blocarea tabelelor întregi sau a rândurilor individuale.
2. La dezvoltarea unui program, ori de câte ori este posibil, accesați tabelele în aceeași ordine.
3. Încercați să nu scrieți în același tabel de mai multe ori în cadrul aceleiași tranzacții. Dacă acest lucru este dificil, atunci cel puțin minimizați intervalul de timp dintre prima și ultima operație de scriere.
4. Analizați posibilitatea dezactivării escaladei de blocare la nivel de server SQL.
5. Informați în mod clar utilizatorii despre motivele pentru care nu pot efectua nicio acțiune dacă se datorează blocării. Oferă recomandări accesibile și ușor de înțeles despre ce să faci în continuare.

Dacă te uiți cu atenție la recomandări, devine clar că o astfel de testare este adecvată nu numai pentru 1C:Enterprise, ci și pentru orice sistem. Nu contează deloc în ce limbă sunt scrise și cu ce server de baze de date lucrează. Majoritatea recomandărilor sunt de natură universală și, prin urmare, sunt la fel de valabile atunci când utilizați 1C:Enterprise și pentru programe „scrise acasă” sau alte sisteme ERP „în cutie”.

P.S. Știați că oferim asistență profesională pentru actualizarea software-ului 1C? cel mai bun pret?

Etichete pentru căutare:

• Blocarea tranzacțiilor
• Îndepărtarea blocajelor
• 1C încuietori
• Blocare
• Conflict de blocare
• Blocați disputa în timpul tranzacției

În sistemele multi-utilizator joacă un rol important organizare adecvată structuri şi înfiinţarea ecluzelor. Dacă nu există, utilizatorii vor trebui adesea să facă față erorilor cauzate de concurența pentru anumite resurse de sistem. Dar există o problemă de conflict de blocare care este familiară pentru mulți utilizatori. De ce apare un conflict de blocare 1C și cum să-l rezolvi?

Blocați conflictul în 1C 8.3 și semnificația acestuia

Pentru majoritatea utilizatorilor, un mesaj despre un conflict de blocare 1C înseamnă doar o eroare care îi împiedică să-și facă treaba. Ei vor să scape de această problemă cât mai repede posibil și să asedieze departamentul IT cu plângeri că „1C nu funcționează”.

Dar pentru administratorii de sistem și dezvoltatori, un astfel de mesaj indică faptul că pot exista probleme în structura de configurare. Înainte de a încerca să mulțumiți utilizatorii și să eliminați blocajele, trebuie să analizați situația și să înțelegeți motivul mesajului de eroare.

Motive pentru blocarea erorilor în 1C

Testarea de încărcare demonstrativă demonstrează că serverul 1C poate rezista la operarea în paralel a peste cinci mii de utilizatori. Dar condițiile ideale pentru astfel de experimente sunt de neatins în condițiile de zi cu zi ale companiilor mari și mijlocii. Pentru a obține performanțe similare și funcționare fără erori, configurația trebuie să fie proiectată și adaptată în mod ideal la procesele de afaceri specifice ale întreprinderii.

Dacă nu utilizați opțiunile ideale, atunci apar conflicte de blocare 1C din următoarele motive:

Munca simultană a utilizatorilor cu o cantitate mare de date. Această cauză fundamentală este dictată de mecanismele interne ale 1C. Acestea presupun interzicerea modificărilor datelor implicate într-o tranzacție lansată în numele altui utilizator;

Erori și omisiuni în configurație. Structura soluțiilor standard de la compania 1C ține cont de recomandări pentru maximizarea productivității. Dar dezvoltatorii terți nu respectă întotdeauna standarde înalte, iar următoarele defecte pot fi adesea găsite în codul lor:

• Interogări suboptimale;
• Solicitare de solduri la inceputul actiunilor;
• Înțelegerea greșită a scopului obiectelor de configurare și utilizarea lor incorectă;
• Redundanța interblocărilor încorporate în sistem sau dezvoltate suplimentar.

Cum să remediați un conflict de blocare în 1C 8.3

Mesajul de sistem „conflict de blocare la executarea unei tranzacții 1C 8.3” nu caracterizează configurația ca fiind proiectată incorect. Dar dacă astfel de semnale sunt ignorate, atunci există posibilitatea ca, în momentul cel mai crucial, de exemplu, la trecerea unui trimestru sau rapoarte anuale intri in mari probleme. În cel mai bun caz, un sistem lent și utilizatori nemulțumiți. În cel mai rău caz, datele de ieșire sunt incorecte, ceea ce poate duce la sancțiuni din partea autorităților de reglementare.

Soluția la problema conflictelor de blocare din 1C 8.3 poate fi transferarea configurației într-un mod de gestionare a blocării gestionat (manual). Implementat în versiunea 8.1, mecanismul în mâinile specialiștilor competenți rezolvă problema conflictelor de blocare în timpul unei tranzacții în 1C.

Dar merită să rețineți că această acțiune va reduce nivelul de protecție a datelor împotriva modificărilor în timp ce sunt citite de alți utilizatori. Prin urmare, dacă nu sunteți pregătit să controlați în mod independent toate încuietorile din sistem, nu vă grăbiți să modificați setările de configurare.

Soluție rapidă la conflictul de blocare 1C

În munca unui administrator sau dezvoltator, poate apărea o situație când nu există timp pentru a verifica o eroare și a căuta cauzele principale ale problemei. De exemplu, este necesar să trimiteți un raport sau să trimiteți date până la un anumit timp, dar erorile de blocare 1C împiedică acest lucru.

Există două moduri de a rezolva rapid problema:

• Găsiți și încheiați sesiunea care blochează datele necesare. ÎN firme mici, unde numărul de utilizatori 1C nu depășește câteva zeci de persoane, aceasta este soluția optimă;
• Dacă controlați un sistem cu sute de angajați, găsirea sesiunii potrivite fără software specializat poate dura mult timp. În acest caz, va fi mult mai eficient să reporniți serverul.

Aceste soluții sunt radicale și vizează doar rezolvarea rapidă a problemei și eliberarea datelor pentru raportare urgentă. Poate fi eradicată doar prin înțelegerea motivului pentru care a apărut un conflict de blocare la efectuarea unei tranzacții 1C. După astfel de acțiuni, este necesar să găsiți vulnerabilități în sistem, să optimizați configurația sau munca angajaților. Nu este recomandat să folosiți astfel de măsuri în mod continuu în cazul unor conflicte regulate de blocare a tranzacțiilor.