Blocajele bazei de date de fișiere - cum să evitați (din experiența recentă). Blocajele bazei de date de fișiere - cum să evitați (din experiența recentă) Tabelul de configurare a eșuat

Costuri 8.1 set pentru 5 utilizatori.
Folosim contabilitatea standard.
Funcționează în principal prin terminal, uneori fără acesta.
Opțiunea bazei de date - fișier
Erori observate de cei din terminal

ceva de genul. Am scotocit prin net, Yandex - în general, totul este cumva vag.
Recomandări cheie găsite:
1) Descărcați/Încărcați baza de date - în sensul creării uneia noi din configurator
2) rulați \Program Files\1cv81\bin\chdbfl.exe - verificarea integrității fizice a bazei de date
3) Testați și corectați baza de informații
4) actualizați la cea mai recentă versiune 8.1

Stie cineva ceva mai concret?

13.5.2010, 10:05

Tot ce aveți nevoie v-a fost deja sugerat; încercați mai întâi. Există erori fizice pe media?
Nu cred că cineva poate fi mai precis.

13.5.2010, 10:56

Deci asta... daca il luam in considerare fara a tine cont de 1C, dar in general, atunci prostesc cineva din doua locuri incearca sa blocheze o masa, prima reuseste, iar restul sunt trimise. Uită-te la ce operațiuni/tranzacții/procesări (sau cum le numesc ei în 1C) sunt efectuate în acest moment. Este posibil ca problema să nu fie platforma, ci configurațiile scrise greșit sau modul în care aceste configurații funcționează asupra datelor dvs.

P.S. Și bazele de date de fișiere în modul multi-utilizator sunt o perversiune.

13.5.2010, 10:58

Deși cine naiba știe cum este făcută baza de date în 1C-v, s-ar putea să fie o problemă undeva în baza de date și să ajute tot felul de reparații.

13.5.2010, 11:06

Da, mi se pare că octogonul este ca o platformă - este încă umed. Undeva au scris că testarea și corectarea trebuie făcute PERIODIC

13.5.2010, 11:10

improbabil. Pentru cei opt, a fost achiziționat un nou server cu Windows licențiat

Concluzia este că unul blochează masa, restul așteaptă până la expirarea timpului.
De ce nu au timp este o mare întrebare. Uită-te la media fizică, poate fi o prostie. Jurnal de sistem MHDD. Și toate acele acțiuni care sunt scrise în primul post sunt obligatorii.

P.S. Nou nu înseamnă 100% funcțional.

13.5.2010, 11:38

Tot ce aveți nevoie v-a fost deja sugerat, încercați mai întâi

deci da, trebuie sa asteptam pana seara.
Erau puține speranțe de a auzi ceva nou

Nu spune miracole. Există o mulțime de necazuri acolo, dar acestea nu sunt ele.

unde sunt minunile? Nu înțeleg, cineva va pretinde că 8.1 este o platformă cool, fără cusur?

a scris că testarea și corectarea trebuie făcute PERIODIC

Se pare că avem un astfel de caz.
Un sondaj efectuat individual de utilizatori (pentru a nu sta întinși împreună) a arătat că această situație pare să apară NUMAI în rândul utilizatorilor care lucrează în terminal. Iar cei care nu trec prin terminal unde
Windows Server 2003 R2 Standart 64, fie nu-și amintesc această situație, fie pur și simplu nu le-a trecut prin cap.
Mai mult, doi cei deosebit de observatori au remarcat că în urmă cu 1,5-2 luni acest fenomen a fost observat MULT mai rar.

13.5.2010, 12:42

Ucigașul născut, Există vreun antivirus instalat pe server? Dacă da, încercați să o dezactivați sau să adăugați baza de date la excepții

13.5.2010, 13:14

Există vreun antivirus instalat pe server?

Nu, va trebui să arunc o privire. Acesta este un server inamic
smart-ass francs a luat una dintre bazele noastre de date pentru întreținere, și-a securizat serverul și par să ne supravegheze munca
accesul la serverul lor a fost oferit, dar într-o versiune redusă.
Voi arunca o privire.

Se pare că nu există niciun antivirus...

13.5.2010, 13:23

Nu înțeleg, cineva va pretinde că 8.1 este o platformă cool, fără cusur?
da, la naiba. 7.7 este încă o porcărie pe alocuri, dar pe la 8 este timpul să scriem legende despre problemele sale

Cât de mare este baza de date și câți utilizatori?

Adaugă-l. Dați un exemplu concret.
Cât de mare este baza de date și câți utilizatori?

Am facut un test noaptea si l-am reparat. Înainte de aceasta, 1cv8.1CD era de 2 GB, acum este de 1,5 GB.
Există 5 utilizatori, precum și licența în sine.
În ceea ce privește legendele despre erori, a existat un singur caz. Acum, dacă luați 7.7 și pur și simplu copiați 1 bază de date prin Total într-o altă locație - o copie fără probleme.
Odată ce am încercat să fac același lucru cu o bază de date de opt ori, am copiat directorul bazei de date într-o altă locație,
înregistrat, a deschis ambele baze de date în același timp, una era destinată perversiunilor.
Am marcat mai multe documente pentru ștergere în copie, am trecut la fereastra cu baza de date reală și nu mi-a venit să cred ochilor: aceleași documente au fost marcate și acolo pentru ștergere.

Stump de frasin, 1C are un răspuns la toate: faceți o copie zilnică a bazei de date.
Da, dar acesta este un răspuns prost

MMMarina

Ucigașul născut,

Buna prietene...

Mit!
Așa se nasc legendele...

Buna prietene...

Buna prietene. Deci te-ai lăsat dus

Și apoi pictogramele de pe desktop au devenit silențioase

Mit!
Așa se nasc legendele...

L-am vazut. Nu a fost amuzant pentru mine să fac distincția între documentele postate și cele nepostate după eliminarea semnului de ștergere, toate devin nepostate.

Nu-mi amintesc ce platformă era atunci.

incearca sa faci la fel. Poate o poți face și tu

Așa se nasc legendele...

Voi spune mai multe: când am demarcat manual câteva documente pentru ștergere,
Același lucru s-a întâmplat în baza de date reală. Nu am avut timp atunci să documentez cumva această senzație.
Așa că am pus totul înapoi așa cum era și n-am mai făcut-o.

eliminarea găurilor în cunoștințele informatice...
Chiar cred că sunt fără speranță...

Acest subiect anume nu este deloc pentru tine, dragă (c)
în general, totul este de înțeles
fă-ți un prieten cu informatica, ca opțiune)))

Nu am copiat niciodată o bază de date de fișiere cu una a opta
Nu a fost nicidecum o senzație.

S-ar putea să nu crezi, dar s-a întâmplat.

Cert este că am lucrat foarte strâns cu 8 de câțiva ani. De îndată ce nu au fost copiate. Deci nu pot să cred
Dar pot presupune că atunci când o persoană este obosită, multe sunt posibile. O știu de la mine.

Nu vă faceți griji, baza de date de fișiere poate fi copiată și creată cu ușurință în orice alt mod. Nu ar trebui să existe erori.

14.5.2010, 10:52

14.5.2010, 11:28

Am o presupunere: am înregistrat aceeași bază de date de două ori când am parcat.

8 oferte de înlocuit

14.5.2010, 11:31

nu... 7.7, când încerc să fac asta, tace prostește și nu adaugă baza de date în listă (pur și simplu nu reacționează deloc)
8 oferte de înlocuit

Poate că tocmai am ratat cu un mouse și l-am lansat pe același... Miracolele nu se întâmplă

14.5.2010, 11:47

Poate că tocmai am ratat marcajul cu mouse-ul și l-am lansat pe același...

Voi încerca să modelez ceva asemănător acasă. Voi scrie înapoi mai târziu.
De obicei, înainte de orice acțiune periculoasă, în 1C (7.7. sau 8) dau clic pe semnul întrebării (calea către baza de date este afișată acolo).

Atunci oamenii au râs de legenda mea atât de unanim încât am început să mă îndoiesc de ea.
Deși există mai multe erori în cele opt decât în cele șapte.

O, ce eroare stupidă, nu am fost singurul care a văzut asta.
În general, au batjocorit o bază a 8-a la un client când eu încă lucram în franciză.
Într-o zi o persoană, alta - a doua, în a treia am fost. I-am întrebat - au făcut o copie de rezervă înainte de exploit-uri? Ca răspuns - nechează ca caii, au marcat pe scurt, doar că au luat baza pe mașina aia

14.5.2010, 12:35

- nechează ca caii, au marcat mai scurt, doar că au luat baza local,
și am avut ocazia să o trag de pe net. Urmând exemplul lui Tavarischi anterior, am decis să nu fac o copie de rezervă,
Era tânăr și prost - a fost multă expoziție.
În general, am făcut modificări la conf, salvez conf, în timp ce salvam conf, s-a întâmplat un fel de accident, iar baza de date a căzut, seara. Şoc. Dimineața au mers acolo 3 specialiști, printre care și eu.
Accidentul a fost că numărul eliberării a fost smuls din baza de date, adică. în configurație, când ați dat clic pe întrebare, aceasta era goală, iar numele conf. în sine lipsea. iar la intrarea în baza de date nu se vedea nimic, inclusiv interfața. a zburat, a fost imposibil să introduceți jurnalele de documente.
Am rezolvat problema actualizând baza de date ucisă cu un fișier de configurare relativ proaspăt, totul a funcționat.
Totul a renascut.
Acesta este un exemplu de legendă adevărată. 3 persoane nu ar trebui să se defecteze în același timp

14.5.2010, 13:53

în timpul salvării conf., a avut loc un fel de accident și baza de date a căzut

Ei bine, dacă a fost o eroare hardware, atunci nimic surprinzător.
Dar dacă ați găsit o eroare care apare în mod constant după efectuarea anumitor acțiuni, atunci este o altă poveste.

14.5.2010, 14:39

Ei bine, dacă a fost o eroare hardware, atunci nimic surprinzător

Idk, ce sa întâmplat. fierul, plasa sau platforma nu sunt atât de importante acum.
Mi se pare că software-ul nu ar trebui să se comporte atât de încântător
Este același lucru cu lansarea Vista și admiterea că este o porcărie. Cumva au sărit rapid de la 8.0 la 8.1
P.S. Înțeleg sensul cuvântului bug, mulțumesc pentru îngrijorare)))

14.5.2010, 19:37

Să presupunem că, dacă, atunci când rulați pachete de servicii sau ceva important pe Vista, apare o „gată” similară, atunci este probabil ca sistemul, chiar dacă pornește, să funcționeze extrem de instabil.
Sau, să zicem, în momentul luării insulinei are loc un cutremur, atunci diabeticul poate muri, pentru că. seringa s-a rostogolit sub canapea în timp ce se agita.

14.5.2010, 22:32

Born Killer, există vreun antivirus instalat pe server? Dacă da, încercați să o dezactivați sau să adăugați baza de date la excepții

Cum poate un antivirus să afecteze blocarea meselor? baza de date 8.x este un singur fișier.

Am marcat mai multe documente pentru ștergere în copie, am trecut la fereastra cu baza de date reală și nu mi-a venit să cred ochilor: aceleași documente au fost marcate pentru ștergere și acolo shok.gif
În general, nu mi-au plăcut acest nenorocit de topuri, de atunci am făcut doar o copie a bazei de date prin Upload/Load.
Cum vă place această legendă tristă, domnule?
Ce se întâmplă dacă m-am lăsat dus și am făcut lucruri mai serioase în copie (de exemplu, documente șterse marcate pentru ștergere) și, într-un mod neclar, aceleași acțiuni au fost efectuate în baza de date principală?

Nu, asta nu poate fi, miracolele nu se întâmplă. Probabil te-ai autentificat în aceeași bază de date... În 8, te poți autentifica în baza de date de 2 ori sub același nume fără probleme.

Din când în când, au apărut probleme la efectuarea/înregistrarea documentelor cu o eroare de formular
„Conflict de blocare în timpul tranzacției: nu s-a putut bloca tabelul „_DOCUMENT158”

Deci, primul lucru pe care trebuie să-l faceți este să determinați ce document de metadate îi corespunde tabelul „_DOCUMENT158”. În acest scop, există o metodă de context global „GetDatabaseStorageStructure”. În acest fel veți înțelege cel puțin exact ce document este „buggy”.

Apoi trebuie să înțelegeți dacă cineva a schimbat modulul de conducere în el și să bată în cap dacă l-a schimbat într-un singur loc. Cel mai probabil, seturile de înregistrări de registru sunt scrise în mod explicit folosind metoda Write în loc să permită platformei să facă acest lucru corect. Și succesiunea lor este confuză...
Nu există blocaje?

În general, 5 persoane nu trebuie ținute în modul fișier. Puteți lua un subd gratuit, puteți cumpăra doar o cheie pentru serverul de cluster și gata. Sau este prea scump pentru birou?
Nu-mi amintesc dacă jurnalul tehnologic poate fi filmat în modul fișier sau nu...

14.5.2010, 22:53

=========================================================
http://odines.ru/thread1386.html - acesta este firul tău?

Adică tranzacția nu are loc nici măcar atunci când un utilizator lucrează? Atunci problema probabil nu este în codul strâmb atunci când înregistrați mișcările. Pentru că nu pot exista blocări în modul pentru utilizator unic. Înregistrarea se face secvenţial.

Apoi se pare că problema constă în încălcări ale structurii bazei de date în sine.
Este mai bine să efectuați mai întâi Testarea și corectarea bazei de date cu indicatorul „Restructurare tabelele bazei de date” activat.
Încărcarea în dt și apoi încărcarea are, de asemenea, sens...
Este puțin probabil ca chdbfl.exe să ajute în acest caz... deși, desigur, merită încercat dacă orice altceva nu ajută.

Gee - tocmai acum m-am uitat la data postărilor în firul http://odines.ru/thread1386.html Și dezvoltarea celor standard într-un nou mod controlat nu este departe.
Iar diferența dintre 8.2 și 8.1 este mult mai mare decât între 8.1 și 7.7, mai ales pentru dezvoltatori, creierul lor trebuie să fie complet reconstruit pentru a se dezvolta pentru un mod de operare „controlat”.

Simptomele și istoricul pacientului:

Munca mai multor utilizatori prin intermediul rețelei cu același fișier (bază de date) include un mecanism de blocare a rețelei. Acest lucru obligă sistemul să piardă timp prețios identificând sesiuni deschiseînregistrări și, în consecință, soluționarea conflictelor.

Principalele semne ale blocării operațiunii:

lucrează rapid utilizatorul cu baza de date prin rețea în modul exclusiv și extrem de lent când lucrează mai mulți utilizatori simultan
experiență rapidă de utilizator cu o bază de date locală pe server și lucru lentor în rețea
atrage Sistemul de fișiere puțin sub 10 MB/sec

Așadar, mi s-a dat sarcina de a mă asigura că până la trei utilizatori pot lucra în 1C în același timp! Amuzant, nu-i așa?

Am uitat toate glumele când am văzut cu ce am de-a face: un „server” reprezentat de un obișnuit calculator de birou si doua laptopuri.

Fericirea ar fi incompletă dacă nu ar fi minunat OS- pe un computer și pe unul Laptop Windows 7, pe de altă parte - Windows 8.

Când încercam să postezi simultan documente pe laptopuri, unul a rămas blocat timp de aproximativ un minut, iar al doilea a ieșit din 1C cu textul de eroare „nu a putut bloca masa...”.

Lansarea 1C pe un laptop este un spectacol separat care a durat aproximativ 3 minute!

Pe multe resurse am găsit sfaturi pentru a trece la lucrul în accesul la terminal. Din păcate, Windows 7 nu permite mijloace regulate se transformă într-un server terminal - maximum o conexiune activă. În acest caz, sesiunile rămase nu se termină; vă puteți reconecta sub alt utilizator - „eliminând” utilizatorul anterior, dar fără a-și termina sesiunea. Prin urmare, ar trebui să transferați 1C pe un sistem de operare server, unde nu există astfel de restricții. Clientul, pe propriul risc, a rezolvat problema folosind în schimb un utilitar terță parte Windows7_SP1_RDPhack.

Dar aventurile nu s-au terminat aici. Chiar și la conexiunea la terminale au existat întârzieri semnificative. Încă o dată, motoarele de căutare atotputernice m-au ajutat. Mai jos sunt sfaturi pentru accelerarea fișierului 1C, pe care le-am urmat:

1. Dezactivați utilizarea protocolului de rețea IPv6, configurați adresarea pe „vechiul” IPv4.

2. Adăugați procese 1C la excepții Windows Firewall, precum și în excepțiile antivirus, sau dezactivați-le complet (mai riscant, dar un test simplu a arătat cresterea vitezei retransferul documentelor atunci când antivirusul Avast este dezactivat factor de!)

3. Începeți să indexați căutarea text integral în 1C sau dezactivați-o complet

4. Rulați Testarea și repararea bazei de date, verificând cu utilitarul ChDbfl

5. Rulați elementul Verificare configurație din configurație (dacă configurația nu este standard, aceasta poate fi utilă). Pe baza rezultatelor verificării configurației, a scăzut în mod magic în dimensiune cu aproape o treime. Nu m-am aprofundat cu exactitate în ceea ce au actualizat programatorii primii înaintea mea, dar faptul este evident.

6. Dezactivați opțiunile funcționale inutile.

7. Configurați drepturile de utilizator. (Acesta și sfatul anterior mi s-au părut stupide până când am urmărit desenul forme controlate la deschiderea listei de documente. Cu cât sunt mai puține lucruri inutile într-o interfață gestionată, cu atât funcționează mai rapid, de regulă)

8. Începeți să recalculați totalurile și să restabiliți secvența (o creștere semnificativă poate apărea numai dacă pentru o lungă perioadă de timp rezultatele nu au fost restabilite)

9. Specificați „Viteza conexiunii - scăzută” în setările listei bazei de date (acest lucru nu a dat prea mult rezultat, cu excepția faptului că imaginile subsistemelor au fost oprite :))

După parcurgerea tuturor acestor pași, baza de date a fișierelor 1C a început să funcționeze mult mai rapid. A început să se lanseze în maxim 10 secunde, iar viteza de transfer a documentelor a crescut în medie de 12 ori.

Poate că acest scurt articol vă va fi util dacă brusc trebuie să vă accelerați baza de date a fișierelor 1C.

P.S: Și rulați fișierul 1C folosind acces la reteaîntr-un folder partajat - încă nerealist, deoarece Dasha este cel mai rapid unitate SSD, RAM iar procesorul va fi blocat în rețea, iar munca mai multor utilizatori va fi practic imposibilă. Vorbim în special despre configurația UT 11.1. Auto-scris configuratii mici Ele pot funcționa destul de repede chiar și în versiunea fișierului.

Adăugiri din comentarii pentru publicare:

Defragmentator de disc cu bază de fișiere

Convoluţie baza de date (poate fi utilă dacă baza de date este mare, de exemplu, pentru câțiva ani). Baza de date a clientului era destul de tânără, așa că reducerea a fost imposibilă.

Upgrade hardware - hard disk mai rapid, comutator nou, procesor etc.

Instalați pe server web, acces folosind client slab. Aici părerile sunt împărțite. Unii spun că este de multe ori mai rapid, alții spun că nu se notează nicio accelerație.

În sistemele multi-utilizator, organizarea corectă a structurii și înființarea încuietorilor joacă un rol important. 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. 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ă posibila prezență a problemelor î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 o performanță similară și o 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 de a intra în probleme mari în cel mai crucial moment, de exemplu, la depunerea rapoartelor trimestriale sau anuale. Î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 aflat î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 companiile mici în care numărul de utilizatori 1C nu depășește câteva zeci de persoane, aceasta cea mai buna varianta soluții;
Dacă controlați un sistem cu sute de angajați, găsiți sesiunea potrivită fără specializare software poate dura mult timp. În acest caz, va fi mult mai eficient să reporniți serverul.

Aceste decizii sunt radicale și vizează numai decizie rapidă probleme și eliberarea datelor pentru transmiterea urgentă a rapoartelor. Poate fi eradicată doar prin înțelegerea motivului pentru care a apărut un conflict de blocare la executarea 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.

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 că aceleași date nu pot fi modificate de către diferiți utilizatori in acelasi moment.

De asemenea, ar trebui să verificați dacă vreunul dintre utilizatori execută procesare de modificare a datelor în masă. Acesta ar putea fi 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.

Astfel, ambii utilizatori vor lucra într-un sistem stabil și ei înșiși vor lucra sarcini de rutină se va finaliza cu succes, deoarece probabilitatea conflictelor cu sesiunile utilizatorilor va fi redusă.

„Sesiuni de suspendare”

Problema „sesiunilor blocate” ale utilizatorilor este familiară pentru aproape toți cei care au întâlnit întreținerea 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.

Cât de des vezi acest mesaj? Cred că toți cei care au experiență de lungă durată cu 1C au întâlnit o astfel de eroare cel puțin o dată. De ce produce programul o astfel de eroare? „Conflict de blocare în timpul tranzacției: tabelul nu a fost blocat”?

Ei bine, cel mai adesea acest lucru se întâmplă din cauza faptului că unul dintre utilizatori efectuează deja un fel de operație care a blocat aceasta masa. Pentru a rezolva această problemă, toți utilizatorii trebuie doar să părăsească programul. Dar se întâmplă și ca utilizatorul să părăsească programul, dar procesul programului nu este descărcat din memorie. Nu vă panicați! Dacă toți utilizatorii au părăsit programul, dar mesajul apare în continuare, trebuie să deschideți meniul Instrumente -> Utilizatori activi.

Și vezi cine în afară de tine acest moment lucrează cu programul. Dacă toți utilizatorii s-au deconectat și încă vezi că există altcineva în afară de tine, nu te alarma. S-a întâmplat. Procesul este blocat. Reporniți computerul utilizatorului care este în modul activ.

Dar uneori nici asta nu rezolvă problema. Se întâmplă ca în timp ce o tranzacție este în curs de executare, ledul să clipească sau, de exemplu HDD cu un picior în groapă. Și ceea ce este, de asemenea, probabil, cineva a scos cordonul hub-ului de rețea și a pornit ibricul în locul lui, iar în acel moment calculați amortizarea. Deci, în astfel de momente, baza de date poate fi deteriorată sau datele pot fi înregistrate cu o eroare.

În acest caz și aproape întotdeauna, dacă rețetele de mai sus nu au ajutat, utilitarul chdbfl.exe ajută. Se află în folderul cu fisier executabil 1C. Calea către fișier va fi aproximativ „C:\Program Files\1Cv82\platform_version_number\bin\chdbfl.exe”. Vă rugăm să rețineți că acest utilitar dintr-o versiune a platformei poate să nu funcționeze pentru alta.

Prin urmare, trebuie să deschideți folderul cu numărul platformei curente pe care lucrați.

Cum pot vedea numărul platformei? Foarte simplu. Accesați meniul Instrumente -> Despre program. Și apoi imaginea arată unde să cauți numărul platformei.

Bifați caseta de selectare „remediați erorile detectate”. Și faceți clic pe butonul de executare. Acest utilitar corectează 90% din toate erorile care apar. Vă recomand cu tărie să faceți înainte de a utiliza acest utilitar copie de rezervă baza de date, dar dacă eroarea apare chiar în momentul descarcării, atunci copiați întregul folder din baza de informatii date.