1c 8.3 lukukonflikt, kuidas seda parandada. Kuidas ma blokeerimisprobleeme diagnoosisin. Suur hulk operatsioone

Harvadel juhtudel ilmneb 1C-s töötades tõrge "Lukustuskonflikt tehingute täitmisel: lukustamise maksimaalne ooteaeg on ületatud". Selle olemus seisneb selles, et mitu seanssi proovivad samaaegselt teha sarnaseid toiminguid, mis mõjutavad sama ressurssi. Täna selgitame välja, kuidas seda viga parandada.

Suur hulk operatsioone

Kõigepealt tuleks põhjuste otsimisel selgeks teha, kui palju samaaegselt töötavaid kasutajaid on infobaasis, kus selline viga tekib. Nagu me teame, võib nende maksimaalne arv olla üsna suur. See on tuhat ja viis tuhat.

Lukkude ja tehingute mehhanism on kirjeldatud arendaja juhendis. Neid kasutatakse siis, kui samadele andmetele pääseb korraga juurde mitu seanssi. On loogiline, et samu andmeid ei saa erinevad kasutajad samal hetkel muuta.

Samuti peaksite kontrollima, kas keegi kasutajatest on alustanud töötlemist massiivne muutus andmeid. See võib olla näiteks , kuu sulgemine jms. Sel juhul kaob viga pärast töötlemise lõppu iseenesest.

Plaanilised ülesanded

Pole harvad juhud, kui vea põhjus peitub suure andmemahu töötlemisel. Selliseid asju soovitatakse teha öösel. Planeerige selliste plaanitud ülesannete täitmine töövälisel ajal.

Seega töötavad mõlemad kasutajad stabiilses süsteemis ja ajastatud ülesanded ise täidetakse edukalt, kuna konfliktide tõenäosus kasutajaseanssidega väheneb.

"Kinnijäänud seansid"

Kasutajate riputatud seansside probleem on tuttav peaaegu kõigile, kes on 1C teenusega kokku puutunud. Kasutaja oleks võinud juba ammu programmist väljuda või dokumendi sulgeda, kuid tema seanss jääb endiselt süsteemi. Probleem on enamasti üksik ja piisab sellise seansi lõpetamisest administraatorikonsooli kaudu. Samad probleemid võivad tekkida ka taustatöödega.

Arvukate Interneti-kommentaaride kohaselt on sellised olukorrad tavalisemad võrgu turvavõtmete kasutamisel. Kui "riputatud seansside" olukord kordub süstemaatiliselt, on see põhjus süsteemi ja serverite (kui baasiks on klient-server) põhjalik kontroll ja hooldus.

Vead konfiguratsiooni kirjutamisel

Kõik tüüpilised konfiguratsioonid on välja töötatud kvalifitseeritud spetsialistide ja ekspertide poolt. Iga süsteem on hoolikalt testitud ja optimeeritud kiiremaks ja korrektsemaks tööks selles.

Sellega seoses võib vea põhjus peituda ebaoptimaalses koodis, mille on kirjutanud kolmanda osapoole arendaja. See võib olla "raske" päring, mis blokeerib andmed pikaks ajaks. Harvad pole ka madala jõudlusega ja loogikat rikkuvate algoritmide koostamine.

Suure tõenäosusega tekkis lukukonflikt just arendaja vigade tõttu, kui see tekkis pärast programmi värskendamist. Kontrollimiseks saate täiustusi lihtsalt "tagasi kerida" või koodi ümber kujundada.

Mis on 1C lukud, miks neid vaja on ja kuidas nendega töötamisel probleeme vältida

Kindlasti paljud teist, kui kasutate infosüsteemid 1C Enterprise (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) seisis silmitsi sellise nähtusega nagu blokeerimine. Pealegi nimetavad kõik seda nähtust reeglina erinevalt: “1C lukud”, “1C lukukonflikt”, “1C luku vead”, “1C tehingulukud” ja muud nimed. Mõistame lühidalt, mis on lukud (mitte ummikseisud), miks neid vaja on ja kuidas nendega töötamisel probleeme vältida.

Iseenesest on lukud (sealhulgas 1C ja teistes süsteemides) kasulik tööriist, mis annab võimaluse jagatud ressurssidega järjepidevalt töötada. Näiteks "jagatud ressursside" mõiste ümbritseb meid elus, näiteks kui sina sõidad autoga, ei saa keegi teine ​​seda juhtida. Seetõttu on auto jagatud ressurss. Ja teine ​​juht ootab teid, näiteks teie naine / abikaasa. Te mõlemad võistlete ühise ressursi – auto pärast. Kes hakkab autot juhtima Sel hetkel Te määratlete kontseptuaalsel tasandil, aga kuidas me peaksime olema automatiseeritud süsteemid??? Selleks mõtlesid nad välja tööriista blokeerimine, mis korraldavad jagatud ressursile juurdepääsu protsessi ja määratlevad järjekorra. Reeglina on elus, nagu ka infosüsteemides (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), palju ühiseid ressursse ja seetõttu on ka palju lukke. Nüüd teine oluline punkt- kui kaua naine / abikaasa teie auto vabastamist ootab, on loogiline eeldada, et see ei kesta igavesti. Seetõttu on lukkude jaoks seatud ajalõpu limiit - vastasel juhul ajalõpu aeg. Aegumine on maksimaalne aeg, mille jooksul konkureeriv osaleja (teie naine/abikaasa) saab oodata jagatud ressursi vabastamist. Siis kas ootab ta sama kaua edasi või läheb jalgsi. 1C infosüsteemides lõppeb ajalõpu aegumine teadetega "1C lukukonflikt", "1C luku vead", "1C tehingulukud", "Timeout on lock".

Oluline detail, mida tuleks samuti meeles pidada, on see, et lukud (eriti 1C-s) on selgesõnalised (määrab kasutaja) ja kaudsed (seadib SQL-platvorm). Artiklis räägime selgesõnalistest lukkudest, nii et neid kasutatakse tehingutes alati, seega selgub, et "1C Lock" ja "1C Transaction Lock" on sünonüümid.

Otsustasime, et ajalõpu ületamisel kuvatakse kasutajale veateade, ooteprotsess ise näeb tema jaoks välja nagu 1C infosüsteemi kleepuv ekraan. Järgmised indikaatorid mõjutavad ajalõpu teate tõenäosust (kasutaja 1C vead):

• Paljud 1C lukustuvad tehingus;
• Tehingu kestus.

Lukustusvigadega seotud teadete minimeerimiseks on vaja kas vähendada lukkude komplekti (optimeerida selektiivsust) või lühendada tehingute kestust.
Nüüd otsustame, kuidas saab neid näitajaid reaalses 1C infosüsteemis mõjutada.

Suure hulga blokeeringute vähendamiseks:

1C: Enterprise 7.7 puhul:

Infosüsteem 1C 7.7. lukkude jaoks kasutatakse laualukke, mis halvavad kasutajate töö. Reeglina ei saa ühes andmebaasis vigadeta töötada üle 50 inimese, samas võib probleeme ilmneda ka 20 kasutaja andmebaasides.
Otsus:

• Paindlikud lukud 1C firmalt "Softpoint". Nende abiga saate mitte ainult optimeerida paljusid lukke (asendades laualukud kohandatud lukudega), vaid ka kiirendada valikuid, otsinguid ja aruandeid.

1C: Enterprise 8.x:
Infosüsteem 1C 8.1., 1C 8.2., 1C 8.3. kasutab automaatselt üleliigset tüüpi lukke (REPEATABLEREAD, SERIALIZABLE). See toob kaasa kasutajakogemuse halvenemise 100-lt.
Otsus:

• Hallatavad lukud 1C on platvormi 1C sisseehitatud tööriist valikulisemate lukuseadete jaoks. Selle kasutamiseks peab programmeerija kirjutama koodi õigetesse kohtadesse spetsiaalsed operaatorid, et need vajalikud blokeerida ( tema arvates!) kanded infosüsteemi tabelitesse;
• Paindlikud lukud 1C - Softpoint tehnoloogia tavaliste lukkude asendamiseks kohandatud lukuga.

Tehingute kestuse lühendamiseks:

Mis tahes infosüsteemide 1C (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3), aga ka muude infosüsteemide jaoks kasutatakse sarnaseid lähenemisviise:

Kontrollige ja õige seadistus andmebaasi rutiinne hooldus (failide, indeksite, statistika, ajutiste tabelite andmebaaside, Windowsi ja SQLServeri sätete hooldus);

Raskete 1C ja SQL päringute analüüs ja optimeerimine (indeksi häälestamine, päringu ümberkirjutamine);

Tehingu koondamise kontroll. Paljudel juhtudel on ebamõistlik lisada tehingusse toiminguid, mõistmata, kuidas see mõjutab kestust ja koos sellega ka toimivust.

1. Kui soovite iseseisvalt tegeleda 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) ja teiste infosüsteemide tehniliste toimimisprobleemidega , siis teile unikaalne nimekiri tehnilistest artiklitest meie Almanahhis (lukud ja ummikseisud, suur protsessori- ja kettakoormus, andmebaasi hooldus ja indeksi häälestamine on vaid väike osa tehnilistest materjalidest, mida sealt leiate).
2. Kui soovite arutada jõudlusprobleeme meie eksperdiga või tellida PerfExpert jõudluse jälgimise lahendusesiis jätke päring ja me võtame teiega esimesel võimalusel ühendust.

Tere kõigile!

Üleeile tööl puutusin kokku probleemiga lukkudega, nimelt hakkas ilmuma teade "Tehingu sooritamisel tekkis lukukonflikt. Luku andmise maksimaalne aeg on ületatud".

Ilmselgelt pole siin ummikseisu probleemi, lihtsalt mingi seanss pani lukku ja "unustas" selle eemaldada. Samal ajal ähvardas probleem tõsiste tagajärgedega - dokumenti Kaupade ja teenuste müük ei teostatud. Korraga töötab andmebaasis umbes 100 inimest ning tüüpilist ja sagedast toimingut on võimatu teha!

Lahendusi oli kaks – serveri taaskäivitamine või ebaõnnestunud seansi otsimine. Esimene lahendus on lihtne ja kiire, kuid nagu keegi siin juba kirjutas, saate serveri taaskäivitada, kuni vallandatakse. Otsustas minna teist teed.

Esimene päev - probleem ilmnes pärastlõunal, alguses tundus, et probleem on kaugkasutajas, kes oli Configuratoris kinni. Näis, et hukkamine lihtsalt peatus ühel hetkel ja lukku loomulikult ei vabastatud. Paari tunni pärast õnnestus meil konfiguraator vabastada, kuid probleem ei kadunud. Konfiguraatori sunniviisiline tapmine oli äärmiselt ebasoovitav, võib-olla töötasid nad selles. Pärast seda võttis Google üle. Leidsin sellelt saidilt artikli, mis ütleb, kuidas MS SQL DBMS-is lukke leida, kontrollisin, DBMS-i tasemel lukke polnud. Imelik. Edasi püüti neid kohandada. ajakiri. Seadistage, mis edasi? 15 minutiga paar giga palki! Kuidas neid lugeda, mida otsida? Tundmatu.

Leidsin artikli selle kohta, kuidas näha, mis on SQL Trace'i kaudu blokeeritud. Isegi kui ma selle leian, mis siis? Ma vajan seanssi!

Kella 16.00-le lähemal, kui mõistsin, et ma ei saa seda enam edasi tõmmata, tegin taaskäivituse. Lootuses, et seda enam ei juhtu (ja see oli esimene juhtum kuue töökuu jooksul), hingasin kergendatult, kõik toimis. Aga asjata ... Teine päev - sama olukord. Kaevasin poolteist tundi, jälle arusaamatud katsed googeldada ja nii edasi. Tulemused puuduvad. Taaskäivitage. Päeva lõpuks juhtus see uuesti. Noh, ma arvan, et see on suurepärane, ma tulen rahulikult koju ja istun, kaevan sügavamale. Ma tulen koju, kõik on korras. Kurb küll.

Kolmandal päeval vaatasin veebiseminari, rääkisin huvitavast ja tõhus meetod otsige probleemi. Jäi meelde, aga probleemi enam ei tekkinud. Nädal on möödas ja siin ta on - jälle blokeerimine! Hõõrun käsi ja hakkan tegutsema.

Esimene on logi seadistamine. Jah, ma ei saa ilma selleta hakkama, aga nüüd saan seda lugeda. Seadsime kaks sündmust: esimene on TLOCK, teine ​​on TTIMEOUT. Esimene kuvab kõiki blokeerimissündmusi, teine ​​näitab ummistusi, mida ei õnnestunud määratud aja jooksul tuvastada. Tegelikult piisab suure tõenäosusega ainult TTIMEOUT-st.

Kopeerime tehnilise logifaili selleks ette nähtud kohta, lendame programmi, kutsume lukku, saame teate ning eemaldame või nimetame ümber tehnilise logifaili. Me ei vaja palju teavet muude blokeeringute kohta!

Minge kausta rphost_PID, leidke tekstifailid ja otsige sõna TTIMEOUT. Näeme rida:

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

Muide, rphost_PID kaustu võib olla mitu, kõik sõltub sellest, kui palju tööprotsesse serveris töötab.

Ja siis on kõik lihtne: vaadake rea lõppu - WaitConnections = 8239, see on meie CONNECTION number. Me läheme serverikonsooli, avame Ühendused, leiame selle numbri ja vaatame seansi numbrit. Minu puhul oli kasutaja kohta kaks seanssi – ebaõnnestunud ja mõni teine. Katkes tehnilises logis näidatud seanss. Ja imest! Kõik toimis, rõõmul pole piire! Aga nagu hiljem selgus, seanssi ei riputatud :), nad töötasid selles. Seetõttu on edaspidiseks soovitav kasutajaga ühendust võtta ja hoiatada.

Minu meelest üsna tüüpiline lahendus üsna tüüpilisele probleemile. Pole teada, miks ma sellega kokku ei puutunud, võib-olla seetõttu, et pidin seda häire ajal otsima ja kui kasutajad ei vajutanud, polnud teste võimalik teha - viga polnud.

Kui programmide ja andmetega töötavad korraga sadu kasutajaid, tekivad probleemid, mis on omased vaid suuremahulistele lahendustele. Jutt käib andmelukkudest põhjustatud probleemidest.

Mõnikord saavad kasutajad lukkudest teada sõnumitest, mis näitavad võimetust andmeid kirjutada või mõnda muud toimingut teha. Mõnikord programmi jõudluse väga olulise languse tõttu (näiteks kui toimingu sooritamiseks kuluv aeg kasvab kümneid või sadu kordi).

Lukkudest põhjustatud probleeme ei ole ühine lahendus. Seetõttu püüame analüüsida selliste probleemide põhjuseid ja süstematiseerida nende lahendamise võimalusi.

TEHINGU BLOKEERIMISE PÕHJUSED

Tuletagem kõigepealt meelde, mis on lukud, ja samal ajal selgitame välja, kas neid on vaja. Vaatame paari klassikalist näidet blokeerimisest, millega elus kokku puutume.

Näide 1: Lennu- või rongipileti ostmine. Oletame, et avaldasime oma soovid kassapidajale. Kassiir ütleb meile vabade kohtade olemasolu, mille hulgast saame valida endale meelepäraseima (kui neid on muidugi mitu). Kuni me ei vali ja kinnita oma nõusolekut pakutud variandiga, ei saa neid kohti kellelegi teisele müüa, s.t. ajutiselt blokeeritud. Kui neid ei blokeeritud, siis võis kinnitamise ajaks tekkida olukord, kus meie poolt valitud piletid on juba müüdud. Ja sel juhul võib valikutsükkel olla ettearvamatu arv kordusi. Samal ajal kui valime kohti, aga need on juba müüdud! .. Samal ajal kui me valime teisi ja neid pole enam...

Näide 2: millegi ostmine poest või turult. Läksime leti juurde, valisime sajast saadaolevast õunast kõige ilusama. Nad valisid ja ulatasid taskusse raha. Kuidas see välja näeb, kui raha lugemise ajal müüakse meie poolt valitud õun ostjale, kes tuli meist hiljem?

Seega on blokeerimine iseenesest vajalik ja kasulik nähtus. Just tänu blokeerimisele garanteerime toimingute teostamise ühes etapis. Ja enamasti ei vii kõige edukam rakendamine negatiivseks tarkvara kui näiteks:

• liiga palju esemeid (piletid, õunad) on blokeeritud;
• blokeerimisaeg pikeneb ebamõistlikult.

TÜÜPILISTES 1C KONFIGURATSIOONIDES LIIGA SUURED LUKUSTUSED

Peal suuremad projektid Reeglina kasutame 1C:Enterprise. Sellepärast praktilisi nõuandeid Püüame kirjeldada blokeerimisprobleemide lahendusi 1C: Enterprise + MS-SQL kimbu näitel.

1C:Enterprise'i 8. põlvkond tagab väga-väga hea paralleelsuse. Samaaegselt ühe konfiguratsiooniga (st ühel alusel), tavaliste serverite ja sidekanalitega võib see töötada suur summa kasutajad. Näiteks sajad laopidajad töötlevad kauba väljastamist või vastuvõtmist, majandusteadlased arvutavad korraga erinevate osakondade palgakulu, raamatupidajad arvutavad ja arvestavad palkasid jne.

Kuid on põhjus, miks on olemas vastupidine arvamus - müüt, et intensiivse samaaegse kasutamise korral on 1C: Enterprise'il põhinevate lahendustega töötamine ebamugav või võimatu. Lõppude lõpuks, niipea kui sajad kasutajad hakkavad tööstuslikus mastaabis 1C: Enterprise jaoks standardlahendusi kasutama, ilmub ekraanile üha sagedamini aken uhke kirjaga: “Viga kontekstimeetodi helistamisel (salvestamine): Lukusta konflikt tehingu täitmisel: ...” ja edasi, sõltuvalt kasutatava SQL-serveri tüübist, näiteks „Microsoft OLE DB Provider for SQL Server: Lukupäringu ajalõpu periood on ületatud. ...".

Peaaegu kõik pakutud "kastist välja" teostuse standardlahendused on konfigureeritud automaatseks lukuhalduseks. "Automaatne" siin võib võtta kui "paranoiline". Igaks juhuks blokeerime mõne dokumendi läbiviimisel kõik, mis sellega kuidagi seotud on. Seega selgub, et kui üks kasutaja midagi kulutab (ja mõnikord lihtsalt kirjutab), jäävad ülejäänud ainult ootama.

Avaldan oma arvamust, miks 1C otsustas mitte kohandada oma standardlahendusi kasutamise suure paralleelsuse jaoks. Tööjõukulud selliseks viimistlemiseks ei ole suured - paar "inimesekuud", mis pole 1C skaala seisukohalt märkimisväärne. Arvan, et põhjus on erinev.

Esiteks muudab selline viimistlemine töötlejatele kõigi dokumentide postitamise märkimisväärselt keerulisemaks. See tähendab, et nende tarbijate jaoks, kes kasutavad 1C-d väikeste ülesannete jaoks, on ilma igasuguse kasuta ainult puudus - tüüpilise konfiguratsiooni lõpuleviimise keerukus muutub keerulisemaks. Samal ajal näitab statistika, milline klientide kategooria on 1C peamine söötja ...

Teine põhjus peitub SQL-serverite tüüpilistes põhiseadetes, näiteks MS-SQL, mida kasutatakse endiselt sagedamini kui teisi. Juhtus nii, et seadistustes seatakse prioriteedid salvestamisele muutmälu serverid, mitte plokkide vähendamine. See toob kaasa asjaolu, et kui on vaja lukustada mitu rida, teeb SQL-server mälu ja protsessori jaoks "ökonoomse" otsuse - lukustada kogu tabel korraga!

Just neid standardlahenduste puudujääke või kasutatavate andmebaasiserveri sätete spetsiifikat tuvastatakse sageli blokeerimisest tingitud probleemidega. Selle tulemusena toovad tehnilised puudused kaasa väga olulisi organisatsioonilisi probleeme. Lõppude lõpuks, kui töötajale antakse põhjus töölt kõrvale juhtida või põhjendatakse, miks tööd ei saanud teha, töötab vähemus tõhusalt. Noh, teade tehingute blokeerimise või "aeglustamise" programmi kohta on ideaalne põhjendus, miks midagi teha ei saa.

SOOVITUSED LIIGSE BLOKEERIMISE KÕRVALDAMISEKS 1C:ENTERPRISE'i jaoks

Mida teha, kui liigse blokeerimisega seotud probleemide lahendamine on nii oluline?

Kõigi rakendamise viimases etapis suured kompleksid tuleb täpsustada, et kõrvaldada mittevajalikud tehingulukud. Oluline on lahendada probleemid, mis võivad tuleneda ebapiisavalt välja töötatud blokeerimistingimustest või rakendamismetoodikast.

Sest See operatsioon on äärmiselt oluline, seda tuleb teha pidevalt. Seetõttu oleme sellise täpsustuse rakendamise lihtsustamiseks välja töötanud mitmeid põhisoovitusi, millest püüame kinni pidada. Märkimisväärse hulga suuremahuliste juurutuste kogemuste põhjal saadi soovitusi ja testiti neid.

1. Kui teie DBMS või arendussüsteem (nt 1C:Enterprise) kasutab vaikimisi automaatset andmete lukustamist, keelake automaatne lukuhaldus. Seadistage ise blokeerimisreeglid, kirjeldage tervete tabelite või üksikute ridade blokeerimiskriteeriume.
2. Programmi arendamisel vaadake võimaluse korral tabeleid samas järjekorras.
3. Püüdke mitte kirjutada samasse tabelisse sama tehingu jooksul mitu korda. Kui see on keeruline, minimeerige vähemalt esimese ja viimase kirjutamistoimingu vaheline aeg.
4. Analüüsige võimalust keelata luku eskalatsioon SQL-serveri tasemel.
5. Teavitage kasutajaid selgelt põhjustest, miks mis tahes toiminguid ei saa teha, kui need on tingitud blokeerimisest. Andke juurdepääsetavaid ja arusaadavaid soovitusi, mida edasi teha.

Kui vaatate soovitusi tähelepanelikult, saab selgeks selline arendus sobib mitte ainult 1C:Enterprise'i, vaid kõigi süsteemide jaoks. Pole tähtis, mis keeles need on kirjutatud ja millise andmebaasiserveriga nad töötavad. Enamik soovitusi on universaalse iseloomuga ja seetõttu kehtivad võrdselt nii 1C: Enterprise kasutamisel kui ka "isekirjutatud" programmide või muude "kastiga" ERP-süsteemide puhul.

P.S. Kas teadsite, et pakume professionaalset abi 1C tarkvara uuendamisel parim hind?

Otsi silte:

• Tehingu lukud
• Ummistuste eemaldamine
• 1C blokeerimine
• blokeerimine
• Lukustuskonflikt
• Lukusta konflikt tehingu sooritamise ajal

Mitme kasutajaga süsteemides mängib olulist rolli korralik korraldus konstruktsioonid ja seadistuslukud. Vastasel juhul kogevad kasutajad sageli tõrkeid, mis on põhjustatud konkurentsist teatud süsteemiressursside pärast. Kuid on lukukonflikti probleem, millega paljud kasutajad on tuttavad. Miks tekib 1C luku konflikt ja kuidas seda parandada?

Lukukonflikt punktis 1C 8.3 ja selle tähendus

Enamiku kasutajate jaoks tähendab 1C luku konflikti teade ainult viga, mis takistab neil oma tööd teha. Nad tahavad sellest probleemist võimalikult kiiresti lahti saada ja piirata IT-osakonda kaebustega, et "1C ei tööta".

Kuid süsteemiadministraatorite ja arendajate jaoks viitab selline teade võimalikule probleemile konfiguratsioonistruktuuris. Enne kui proovite kasutajatele meeldida ja plokke eemaldada, peate olukorda analüüsima ja mõistma veateate põhjust.

Blokeerimisvigade põhjused 1C-s

Demonstratiivsed koormustestid näitavad, et 1C server talub enam kui viie tuhande kasutaja paralleelset tööd. Kuid ideaalsed tingimused sellisteks katseteks on suurte ja keskmise suurusega ettevõtete igapäevastes tingimustes saavutamatud. Sarnase jõudluse ja veavaba jõudluse saavutamiseks peab konfiguratsioon olema ideaalselt kavandatud ja kohandatud ettevõtte konkreetsetele äriprotsessidele.

Kui te ei kasuta ideaalseid valikuid, tekivad 1C-luku konfliktid järgmistel põhjustel:

Suure andmemahuga kasutajate samaaegne töö. Selle algpõhjuse dikteerivad 1C sisemised mehhanismid. Need hõlmavad keeldu muuta teise kasutaja nimel algatatud tehinguga seotud andmeid;

Konfiguratsiooni vead ja puudused. Ettevõtte "1C" standardlahenduste struktuur võtab arvesse soovitusi tootlikkuse maksimeerimiseks. Kuid kolmanda osapoole arendajad ei järgi alati kõrgeid standardeid ja nende koodis võib sageli leida järgmisi puudusi:

• Suboptimaalsed taotlused;
• Saldode taotlemine toimingute alguses;
• Konfiguratsiooniobjektide otstarbest arusaamatus ja nende ebaõige kasutamine;
• Süsteemile omane koondamine või täiendavalt arendatud lukud.

Lukustuskonflikti parandamine jaotises 1C 8.3

Süsteemiteade "lukukonflikt tehingu 1C 8.3 täitmise ajal" ei iseloomusta konfiguratsiooni kui valesti kavandatud. Aga kui selliseid signaale eiratakse, siis on võimalus kõige otsustavamal hetkel, näiteks esitades kvartali- või raamatupidamise aastaaruanne saada suuri probleeme. Parimal juhul aeglustuv süsteem ja rahulolematud kasutajad. Halvimal juhul valed väljundandmed, mis võivad kaasa tuua reguleerivad asutused karistused.

1C 8.3 lukkude konflikti probleemi lahenduseks võib olla konfiguratsiooni ülekandmine hallatud (käsitsi) lukuhaldusrežiimi. Versioonis 8.1 rakendatud mehhanism lahendab pädevate spetsialistide käes olev mehhanism lukukonfliktide probleemi 1C tehingute ajal.

Kuid tuleb meeles pidada, et see toiming vähendab andmete kaitse taset teiste kasutajate lugemisprotsessi muutuste eest. Seetõttu, kui te pole valmis kõiki süsteemi lukke iseseisvalt juhtima, ärge kiirustage konfiguratsiooniseadeid muutma.

1C luku konflikti kiire lahendamine

Administraatori või arendaja töös võib tekkida olukord, kus pole aega vea kontrollimiseks ja probleemi algpõhjuste leidmiseks. Näiteks tuleb teatud ajaks esitada aruanne või andmed ning 1C blokeerimisvead takistavad seda.

Probleemi kiireks lahendamiseks on kaks võimalust:

• Otsige üles ja lõpetage seanss, mis lukustas vajalikud andmed. AT väikeettevõtted, kus 1C kasutajate arv ei ületa paarikümmet inimest, on see parim lahendus;
• Kui juhite sadade töötajatega süsteemi, võib õige seansi leidmine ilma spetsiaalse tarkvarata võtta kaua aega. Sel juhul on serveri taaskäivitamine palju tõhusam.

Need lahendused on radikaalsed ja suunatud vaid probleemi kiirele lahendamisele ja andmete väljastamisele kiireloomuliseks teatamiseks. Seda saab likvideerida ainult siis, kui mõistate 1C tehingu sooritamisel lukukonflikti tekkimise põhjust. Pärast selliseid toiminguid on vaja leida süsteemi haavatavused, optimeerida töötajate konfiguratsiooni või tööd. Selliseid meetmeid ei soovitata pidevalt kasutada, kui tehingud on lukustatud regulaarsed konfliktid.