»Konflikt zaklepanja med izvajanjem transakcije: presežena je bila največja časovna omejitev za odobritev zaklepanja« je dokaj pogosta napaka v 1C 8.3 in 8.2, povezana s tekmovanjem za uporabo virov v sistemu.

Sistem 1C omogoča vzporedno delo velikega števila uporabnikov: kot kažejo testi obremenitve, danes to število ni omejeno na pet tisoč uporabnikov, ki hkrati delajo v sistemu. Da pa baza podatkov 1C 8 hkrati podpira veliko število uporabnikov, mora biti konfiguracija pravilno zasnovana.

Pridobite 267 video lekcij 1C brezplačno:

Izvajanje velikega števila operacij

Verjetno je nek uporabnik začel, na primer, za daljše obdobje v eni transakciji. Arhitektura 1C 8.3 predvideva, da sistem ne dovoljuje spreminjanja podatkov, ki jih v eni transakciji uporablja drug uporabnik, in jih blokira.

Morda je to začasna napaka, ki se ne bo več pojavljala, ko bo drug uporabnik dokončal dejanja v sistemu. Če se ta napaka pojavlja pogosto, je najverjetneje nekaj drugega.

Napaka konfiguracije

Poleg napak v kodi so pogosto metodično napačne rešitve. Na primer, - samo po sebi pomeni zaporedno hrambo dokumentov. Paketno računovodstvo lahko nadomestite z RAUS - na ta način boste resno povečali zmogljivost sistema.

Kako popraviti to napako v 1C 8.3?

V vsakem primeru pojav napake »Konflikt zaklepanja med izvajanjem transakcije« nakazuje potrebo po pregledu sistema, še posebej pri srednjih in velikih informacijskih sistemih v načinu odjemalec-strežnik (MS SQL, PostgreSQL itd.). Če se tega ne upošteva v zgodnji fazi, lahko kasneje, ko je delovanje sistema še posebej pomembno (v obdobju poročanja), pride do nepopravljivih posledic.

Za revizijo in odpravljanje napak je najbolje izbrati zanesljivega partnerja. Samo pokličite nas in v najkrajšem možnem času bomo rešili vašo težavo. Podrobnosti na strani.

Nisem mogel zapisati sprememb za prenos v distribuirano bazo, kontaktiral sem podporo 1c in ponudil naslednje. Odločil sem se preprosto znova zagnati aplikacijski strežnik in strežnik s SQL. Na splošno lahko potrdite polje »Blokiranje je načrtovano
vključene naloge"
Pomagalo je tudi brez ponovnega zagona.

Načrtovane operacije na ravni DBMS za MS SQL Server

Navodila za izvajanje rutinskih operacij na ravni DBMS.

Informacije veljajo za različico odjemalec-strežnik 1C:Enterprise 8 pri uporabi DBMS MS SQL Server.

Splošne informacije

Eden najpogostejših vzrokov za neoptimalno delovanje sistema je nepravilno ali nepravočasno izvajanje rutinskih operacij na ravni DBMS. Posebej pomembno je izvajanje teh rutinskih postopkov v velikih informacijskih sistemih, ki delujejo pod velikimi obremenitvami in hkrati služijo velikemu številu uporabnikov. Posebnost takšnih sistemov je, da običajna dejanja, ki jih DBMS izvaja samodejno (na podlagi nastavitev), niso dovolj za učinkovito delovanje.

Če delujoči sistem kaže kakršne koli simptome težav z zmogljivostjo, morate preveriti, ali je sistem pravilno konfiguriran in redno izvaja vsa priporočena rutinska vzdrževanja na ravni DBMS.

Izvajanje rutinskih postopkov bi moralo biti avtomatizirano. Za avtomatizacijo teh operacij je priporočljiva uporaba vgrajenih orodij MS SQL Server: Načrt vzdrževanja. Obstajajo tudi drugi načini za avtomatizacijo teh postopkov. V tem članku je za vsak načrtovani postopek podan primer njegove konfiguracije z uporabo načrta vzdrževanja za MS SQL Server 2005.

Priporočljivo je redno spremljati pravočasnost in pravilnost izvajanja teh rutinskih postopkov.

Posodobitev statistike

MS SQL Server gradi načrt poizvedbe na podlagi statističnih informacij o porazdelitvi vrednosti v indeksih in tabelah. Statistične informacije se zbirajo na podlagi dela (vzorca) podatkov in se samodejno ažurirajo, ko se ti podatki spremenijo. Včasih to ni dovolj, da bi MS SQL Server dosledno zgradil najbolj optimalen načrt za izvajanje vseh poizvedb.

V tem primeru lahko pride do težav z zmogljivostjo poizvedbe. Hkrati se v načrtih poizvedb opazijo značilni znaki neoptimalnega dela (neoptimalne operacije).

Da bi zagotovili čim bolj pravilno delovanje optimizatorja MS SQL Server, je priporočljivo redno posodabljati statistiko podatkovne baze MS SQL.

Če želite posodobiti statistiko za vse tabele zbirke podatkov, morate izvesti naslednjo poizvedbo SQL:

exec sp_msforeachtable N"POSODOBITEV STATISTIKE? S FULLSCAN"

Posodabljanje statistike ne vodi do zaklepanja tabel in ne bo motilo dela drugih uporabnikov. Statistiko je mogoče posodobiti tako pogosto, kot je potrebno. Upoštevajte, da se bo obremenitev strežnika DBMS med posodobitvijo statistike povečala, kar lahko negativno vpliva na splošno delovanje sistema.

Optimalna pogostost posodabljanja statističnih podatkov je odvisna od velikosti in narave obremenitve sistema in se določi eksperimentalno. Priporočljivo je posodobiti statistiko vsaj enkrat na dan.

Zgornja poizvedba posodobi statistiko za vse tabele v bazi podatkov. V resničnem sistemu različne tabele zahtevajo različne stopnje posodabljanja statističnih podatkov. Z analizo načrtov poizvedb lahko ugotovite, katere tabele potrebujejo najpogostejše posodobitve statističnih podatkov, in nastavite dva (ali več) različna rutinska postopka: za pogosto posodobljene tabele in za vse druge tabele. Ta pristop bo znatno skrajšal čas posodabljanja statistike in vpliv procesa posodabljanja statistike na delovanje sistema kot celote.

Konfiguriranje samodejnega posodabljanja statistike (MS SQL 2005)

Zaženite MS SQL Server Management Studio in se povežite s strežnikom DBMS. Odprite mapo Management in ustvarite nov načrt vzdrževanja:

Ustvarite podnačrt (Dodaj podnačrt) in ga poimenujte »Posodobitev statistike«. V opravilno vrstico mu dodajte nalogo Posodobi statistiko:

Nastavite razpored posodabljanja statistike. Statistiko je priporočljivo posodobiti vsaj enkrat na dan. Po potrebi se lahko poveča pogostost posodabljanja statistike.

Nastavite nastavitve naloge. Če želite to narediti, dvokliknite nalogo v spodnjem desnem kotu okna. V obrazcu, ki se prikaže, določite ime baze (ali več baz), za katero se bodo posodobili statistični podatki. Poleg tega lahko določite, za katere tabele želite posodobiti statistiko (če ne veste točno, katere tabele morate podati, nastavite vrednost na Vse).

Posodabljanje statističnih podatkov mora biti izvedeno z omogočeno možnostjo Full Scan.

Shranite izdelan načrt. Ko pride čas, določen v urniku, se statistika samodejno posodobi.

Čiščenje proceduralnega predpomnilnika

Optimizator MS SQL Server predpomni načrte poizvedb za ponovno izvedbo. To naredimo zato, da prihranimo čas, porabljen za sestavljanje poizvedbe, če je bila ista poizvedba že izvedena in je njen načrt znan.

Možno je, da bo MS SQL Server, ki se zanaša na zastarele statistične podatke, zgradil neoptimalen načrt poizvedbe. Ta načrt bo shranjen v proceduralnem predpomnilniku in uporabljen, ko bo ista poizvedba znova priklicana. Če ste posodobili statistiko, vendar niste počistili proceduralnega predpomnilnika, lahko SQL Server iz predpomnilnika izbere stari (neoptimalen) načrt poizvedbe, namesto da bi zgradil nov (boljši) načrt.

Če želite počistiti proceduralni predpomnilnik strežnika MS SQL, morate izvesti naslednjo poizvedbo SQL:

To poizvedbo je treba zagnati takoj po posodobitvi statistike. V skladu s tem se mora pogostost njegovega izvajanja ujemati s pogostostjo posodabljanja statistike.

Konfiguriranje postopkovnega čiščenja predpomnilnika (MS SQL 2005)

Ker je treba proceduralni predpomnilnik počistiti vsakič, ko se statistika posodobi, je priporočljivo, da to operacijo dodate že ustvarjenemu podnačrtu "Posodobi statistiko". To naredite tako, da odprete podnačrt in v njegovo shemo dodate nalogo Execute T-SQL Statement Task. Nato morate nalogo Posodobi statistiko s puščico povezati z novo nalogo.

V besedilu ustvarjene naloge Execute T-SQL Statement morate podati poizvedbo "DBCC FREEPROCCACHE":

Defragmentacija indeksa

Pri intenzivnem delu s tabelami baze podatkov se pojavi učinek razdrobljenosti indeksov, kar lahko privede do zmanjšanja učinkovitosti poizvedb.

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

Defragmentacija indeksa ne blokira tabel in ne bo motila dela drugih uporabnikov, vendar ustvarja dodatno obremenitev SQL Serverja. Optimalno pogostost izvajanja tega rutinskega postopka je treba izbrati v skladu z obremenitvijo sistema in učinkom defragmentacije. Priporočamo, da defragmentirate svoje indekse vsaj enkrat na teden.

Možno je defragmentirati eno ali več tabel, ne vseh tabel v bazi podatkov.

Konfiguracija defragmentacije indeksa (MS SQL 2005)

V predhodno ustvarjenem vzdrževalnem načrtu ustvarite nov podnačrt z imenom "Reindex". Dodajte mu opravilo Rebuild Index:

Nastavite urnik izvajanja za nalogo defragmentacije indeksa. Priporočljivo je, da opravilo izvajate vsaj enkrat na teden, če so podatki v bazi zelo volatilni, pa še pogosteje – do enkrat na dan.

Ponovno indeksiranje tabel baze podatkov

Ponovno indeksiranje tabel vključuje popolno prenovo indeksov tabel baze podatkov, kar vodi do pomembne optimizacije njihovega dela. Priporočljivo je, da izvajate redno ponovno indeksiranje tabel baze podatkov. Če želite ponovno indeksirati vse tabele baze podatkov, morate izvesti naslednjo poizvedbo SQL:

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

Ponovno indeksiranje tabel jih blokira za čas njihovega dela, kar lahko bistveno vpliva na delo uporabnikov. V zvezi s tem je priporočljivo ponovno indeksiranje izvesti med minimalno obremenitvijo sistema.

Po ponovnem indeksiranju indeksov ni treba defragmentirati.

Nastavitev ponovnega indeksiranja tabele (MS SQL 2005)

V predhodno ustvarjenem načrtu vzdrževanja ustvarite nov podnačrt z imenom »Defragmentacija indeksa«. Dodajte mu opravilo za obnovitev indeksa:

Nastavite urnik izvajanja za nalogo ponovnega indeksiranja tabele. Priporočljivo je izvajati nalogo med minimalno obremenitvijo sistema, vsaj enkrat na teden.

Prilagodite nalogo tako, da določite bazo podatkov (ali več baz podatkov) in izberete zahtevane tabele. Če ne veste točno, katere tabele morate določiti, nastavite vrednost na Vse.

Ko na stotine uporabnikov dela s programi in podatki hkrati, pride do težav, ki so značilne samo za rešitve velikega obsega. Govorimo o težavah, ki jih povzročajo zaklepanja podatkov.

Včasih uporabniki izvejo za zaklepanje iz sporočil, ki kažejo na nezmožnost zapisovanja podatkov ali izvajanja kakšne druge operacije. Včasih zaradi zelo velikega padca zmogljivosti programa (na primer, ko se čas, potreben za izvedbo operacije, poveča več deset ali stokrat).

Težave, ki jih povzroča blokada, nimajo splošne rešitve. Zato bomo poskušali analizirati vzroke takšnih težav in sistematizirati možnosti za njihovo rešitev.

RAZLOGI ZA BLOKIRANJE TRANSAKCIJ

Najprej se spomnimo, kaj so ključavnice, in hkrati ugotovimo, ali so potrebne. Poglejmo nekaj klasičnih primerov blokiranja, s katerimi se srečamo v življenju.

Primer 1: Nakup letalske ali železniške vozovnice. Recimo, da smo svoje želje izrazili blagajni. Blagajničarka nam sporoči razpoložljivost sedežev, med katerimi lahko izberemo tistega, ki nam je najbolj všeč (če jih je seveda več). Dokler ne izberemo in potrdimo strinjanja s predlagano možnostjo, teh sedežev ni mogoče prodati nikomur drugemu, t.j. začasno blokiran. Če ne bi bili blokirani, bi do trenutka potrditve lahko prišlo do situacije, ko bi bile vstopnice, ki smo jih izbrali, že prodane. In v tem primeru je izbirni cikel lahko nepredvidljivo število ponovitev. Medtem ko izbiramo kraje, pa so že prodani! .. Medtem ko izbiramo druge, pa jih ni več ...

Primer 2: nakup nečesa v trgovini ali na tržnici. Šli smo do pulta, izmed stotih razpoložljivih jabolk izbrali najlepše. Izbrali so in segli v žep po denar. Kako bo videti, če bo med preštevanjem denarja jabolko, ki smo ga izbrali, prodano kupcu, ki je prišel pozneje kot mi?

Tako je blokada sama po sebi nujen in koristen pojav. Zahvaljujoč blokiranju zagotavljamo izvedbo dejanj v eni fazi. In najpogosteje ne najbolj uspešna implementacija programske opreme vodi do negativnosti, ko na primer:

• blokirano je preveliko število predmetov (vstopnice, jabolka);
• čas blokade se neupravičeno podaljša.

PREKOMERNE BLOKIRANJE V TIPIČNIH KONFIGURACIJAH 1C

Pri velikih projektih praviloma uporabljamo 1C:Enterprise. Zato bomo poskušali opisati praktična priporočila za reševanje težav z blokiranjem na primeru paketa 1C:Enterprise + MS-SQL.

8. generacija 1C:Enterprise zagotavlja zelo, zelo dobro vzporednost uporabe. Hkrati z eno konfiguracijo (to je na eni bazi), z običajnimi strežniki in komunikacijskimi kanali, lahko deluje ogromno uporabnikov. Na primer, na stotine skladiščnikov obdeluje izdajo ali prejem blaga, ekonomisti hkrati izračunajo stroške plač za različne oddelke, računovodje izračunajo in izračunajo plače itd.

Vendar obstaja razlog, zakaj obstaja nasprotno mnenje - mit, da je ob intenzivni hkratni uporabi neprijetno ali nemogoče delati z rešitvami, ki temeljijo na 1C: Enterprise. Konec koncev, takoj ko na stotine uporabnikov začne uporabljati standardne rešitve za 1C:Enterprise v industrijskem obsegu, se na zaslonu vse pogosteje pojavi okno s ponosnim napisom: »Napaka pri klicu kontekstne metode (Record): Zakleni konflikt med izvajanjem transakcije: ...« in nadalje v odvisno od vrste uporabljenega strežnika SQL, nekaj takega kot »Ponudnik Microsoft OLE DB za strežnik SQL: presežena časovna omejitev zahteve za zaklepanje. ...".

Skoraj vse standardne rešitve v predlagani izvedbi "izven škatle" so konfigurirane za samodejno upravljanje zaklepanja. "Samodejno" tukaj lahko razumemo kot "paranoično". Za vsak slučaj, ko vodimo kateri koli dokument, blokiramo vse, kar je lahko kakor koli povezano z njim. Tako se izkaže, da ko en uporabnik nekaj porabi (in včasih samo piše), ostali lahko samo čakajo.

Izrazil bom svoje mnenje, zakaj se je 1C odločil, da svojih standardnih rešitev ne bo prilagodil visoki vzporednosti uporabe. Stroški dela za takšno izpopolnitev niso visoki - nekaj "osebo-mesecev", kar ni pomembno glede na lestvico 1C. Mislim, da je razlog drugačen.

Prvič, takšna izboljšava bistveno oteži procesorje za knjiženje vseh dokumentov. To pomeni, da bo za tiste potrošnike, ki uporabljajo 1C za majhne naloge, brez kakršnega koli dobička le slabost - zapletenost dokončanja tipične konfiguracije bo postala bolj zapletena. Hkrati statistika kaže, katera kategorija strank je glavni podajalnik za 1C ...

Drugi razlog je zakopan v tipičnih osnovnih nastavitvah strežnikov SQL, na primer MS-SQL, ki se še vedno uporablja pogosteje kot drugi. Tako se je zgodilo, da so prednostne naloge v nastavitvah dane varčevanju RAM-a strežnika in ne zmanjšanju blokade. To vodi do dejstva, da če je treba zakleniti več vrstic, strežnik SQL sprejme "ekonomično" odločitev za pomnilnik in procesor - da zaklene celotno tabelo hkrati!..

Prav te pomanjkljivosti v standardnih rešitvah ali posebnosti uporabljenih nastavitev strežnika baz podatkov se pogosto identificirajo s težavami, ki jih povzročajo blokade. Posledično tehnične pomanjkljivosti povzročajo zelo velike organizacijske težave. Navsezadnje, če se zaposlenemu navede razlog, da ga odvrnejo od dela, ali utemelji, zakaj dela ni bilo mogoče opraviti, bo manjšina delala učinkovito. No, sporočilo o blokiranju transakcij ali "upočasnjujočem" programu je idealna utemeljitev, zakaj ni bilo mogoče storiti ničesar.

PRIPOROČILA ZA ODPRAVO PREKOMERNEGA BLOKIRANJA ZA 1C: PODJETJE

Kaj storiti, če je rešitev težav s prekomerno blokado tako pomembna?

V končni fazi izvajanja vseh velikih kompleksov je treba izvesti fino izpopolnitev, da se odpravijo nepotrebne blokade transakcij. Ključnega pomena je reševanje težav, ki lahko nastanejo zaradi premalo razvitih pogojev blokiranja ali metodologije izvajanja.

Ker Ta operacija je izjemno pomembna, izvajati jo je treba nenehno. Zato smo za poenostavitev izvajanja takšne izboljšave razvili številna osnovna priporočila, ki se jih poskušamo držati. Prejeta in preizkušena priporočila na podlagi izkušenj velikega števila obsežnih implementacij.

1. Če vaš DBMS ali razvojni sistem (na primer 1C:Enterprise) privzeto uporablja samodejno zaklepanje podatkov, onemogočite samodejno upravljanje zaklepanja. Sami nastavite pravila blokiranja, opišite kriterije blokiranja za celotne tabele ali posamezne vrstice.
2. Ko razvijate program, se, kadar koli je to mogoče, sklicujte na tabele v enakem vrstnem redu.
3. Poskusite ne pisati v isto tabelo večkrat znotraj iste transakcije. Če je to težko, potem vsaj zmanjšajte časovni interval med prvim in zadnjim zapisovanjem.
4. Analizirajte možnost onemogočanja stopnjevanja zaklepanja na ravni strežnika SQL.
5. Jasno obvestite uporabnike o razlogih za nezmožnost izvajanja kakršnih koli dejanj, če so posledica blokade. Dajte dostopna in razumljiva priporočila, kaj storiti naprej.

Če natančno pogledate priporočila, postane jasno, da takšen razvoj je primeren ne le za 1C:Enterprise, ampak za vse sisteme. Ni pomembno, v katerem jeziku so napisani in s katerim strežnikom baze podatkov delajo. Večina priporočil je univerzalne narave, zato so enako veljavna pri uporabi 1C: Enterprise in za "samonapisane" programe ali druge "škatlaste" sisteme ERP.

P.S. Ali ste vedeli, da nudimo strokovno pomoč pri posodobitvi 1C po najboljši ceni?

Iskanje oznak:

• Transakcijske ključavnice
• Odstranjevanje blokad
• Blokiranje 1C
• blokiranje
• Zakleni konflikt
• Konflikt ključavnic med izvajanjem transakcije

Neredko se pri delu v 1C pojavi napaka »Konflikt zaklepanja pri izvajanju transakcij: presežen je bil najdaljši čakalni čas za odobritev zaklepanja«. Njegovo bistvo je v tem, da poskuša več sej hkrati izvajati podobna dejanja, ki vplivajo na isti vir. Danes bomo ugotovili, kako odpraviti to napako.

Veliko število operacij

Najprej, ko iščete razloge, morate pojasniti, koliko sočasno delujočih uporabnikov je v informacijski bazi, v kateri se generira takšna napaka. Kot vemo, je lahko njihovo največje število precej veliko. Je tisoč in pet tisoč.

Mehanizem zaklepanja in transakcij je opisan v priročniku za razvijalce. Uporabljajo se, ko več sej istočasno dostopa do istih podatkov. Logično je, da istih podatkov različni uporabniki ne morejo spremeniti v istem trenutku.

Preverite tudi, ali je kateri od uporabnikov začel obdelavo za množično spremembo podatkov. Lahko je kot, zaključek meseca in podobno. V tem primeru bo po koncu obdelave napaka izginila sama.

Načrtovane naloge

Ni redkost, da se vzrok za napako skriva v, ki obdeluje veliko količino podatkov. Takšne stvari je priporočljivo početi ponoči. Načrtujte izvedbo takšnih načrtovanih nalog v izven delovnega časa.

Tako bosta oba uporabnika delovala v stabilnem sistemu, sama načrtovana opravila pa bodo uspešno zaključena, saj se bo zmanjšala verjetnost konfliktov z uporabniškimi sejami.

"Zataknjene seje"

Težava "obešenih sej" uporabnikov je znana skoraj vsem, ki so naleteli na storitev 1C. Uporabnik je lahko že zdavnaj zapustil program ali zaprl dokument, vendar njegova seja še vedno ostaja v sistemu. Težava je najpogosteje ena sama in dovolj je, da takšno sejo prekinete prek skrbniške konzole. Enake težave se lahko pojavijo pri opravilih v ozadju.

Po številnih komentarjih na spletu so takšne situacije pogostejše pri uporabi omrežnih varnostnih ključev. Če se situacija z "visečimi sejami" sistematično ponavlja, je to razlog za temeljit pregled in vzdrževanje sistema in strežnikov (če je osnova odjemalec-strežnik).

Napake pri pisanju konfiguracije

Vse tipične konfiguracije so razvili usposobljeni strokovnjaki in strokovnjaki. Vsak sistem je skrbno testiran in optimiziran za hitrejše in pravilnejše delo v njem.

V zvezi s tem je lahko vzrok napake v neoptimalni kodi, ki jo je napisal tretji razvijalec. To je lahko "težka" zahteva, ki bo blokirala podatke za daljše časovno obdobje. Prav tako ni neobičajno graditi algoritme z nizko zmogljivostjo in kršitvijo logike.

Zelo verjetno je, da je do konflikta ključavnice prišlo ravno zaradi napak razvijalca, če je do njega prišlo po posodobitvi programa. Če želite preveriti, lahko preprosto "povrnete" izboljšave ali predelate kodo.

V večuporabniških sistemih imata pomembno vlogo pravilna organizacija strukture in nastavitev ključavnic. V nasprotnem primeru bodo uporabniki pogosto naleteli na napake, ki jih povzroča konkurenca za določene sistemske vire. Obstaja pa težava s konfliktom ključavnic, ki jo poznajo mnogi uporabniki. Zakaj pride do konflikta zaklepanja 1C in kako ga odpraviti?

Konflikt ključavnice v 1C 8.3 in njegov pomen

Za večino uporabnikov sporočilo o konfliktu zaklepanja 1C pomeni le napako, ki jim preprečuje, da bi opravljali svoje delo. Te težave se želijo čim prej znebiti in oblegajo IT oddelek s pritožbami, da "1C ne deluje."

Toda za sistemske skrbnike in razvijalce takšno sporočilo nakazuje možno težavo v konfiguracijski strukturi. Preden poskušate zadovoljiti uporabnike in odstraniti blokade, morate analizirati situacijo in razumeti vzrok sporočila o napaki.

Vzroki za blokiranje napak v 1C

Demonstrativni testi obremenitve kažejo, da lahko strežnik 1C prenese vzporedno delovanje več kot pet tisoč uporabnikov. Toda idealni pogoji za tovrstne poskuse so v vsakodnevnih razmerah velikih in srednje velikih podjetij nedosegljivi. Da bi dosegli podobno zmogljivost in delovanje brez napak, mora biti konfiguracija idealno zasnovana in prilagojena specifičnim poslovnim procesom podjetja.

Če ne izberete idealnih možnosti, pride do konfliktov pri zaklepanju 1C iz naslednjih razlogov:

Sočasno delo uporabnikov z veliko količino podatkov. Ta temeljni vzrok narekujejo notranji mehanizmi 1C. Vključujejo prepoved spreminjanja podatkov, vključenih v transakcijo, sproženo v imenu drugega uporabnika;

Napake in pomanjkljivosti v konfiguraciji. Struktura standardnih rešitev podjetja "1C" upošteva priporočila za povečanje produktivnosti. Toda razvijalci tretjih oseb se ne držijo vedno visokih standardov in v njihovi kodi lahko pogosto najdete naslednje pomanjkljivosti:

• Neoptimalne zahteve;
• Zahteva za stanja na začetku dejanj;
• Nerazumevanje namena konfiguracijskih objektov in njihova nepravilna uporaba;
• Redundanca, ki je lastna sistemu ali dodatno razvite ključavnice.

Kako odpraviti konflikt zaklepanja v 1C 8.3

Sistemsko sporočilo "konflikt zaklepanja med izvajanjem transakcije 1C 8.3" ne označuje konfiguracije kot nepravilno zasnovane. Če pa se takšni signali ne upoštevajo, potem obstaja možnost, da boste v najbolj ključnem trenutku, na primer pri oddaji četrtletnih ali letnih poročil, imeli velike težave. V najboljšem primeru upočasnjen sistem in nezadovoljni uporabniki. V najslabšem primeru napačni izhodni podatki, ki lahko privedejo do kazni regulativnih organov.

Rešitev problema konflikta ključavnic v 1C 8.3 je lahko prenos konfiguracije v upravljani (ročni) način upravljanja ključavnic. Izveden v različici 8.1, mehanizem v rokah pristojnih strokovnjakov rešuje problem konfliktov zaklepanja med transakcijami v 1C.

Vendar je treba upoštevati, da bo to dejanje zmanjšalo raven zaščite podatkov pred spremembami v procesu branja s strani drugih uporabnikov. Če torej niste pripravljeni samostojno nadzorovati vseh ključavnic v sistemu, ne hitite s spreminjanjem konfiguracijskih nastavitev.

Hitra rešitev spora pri zaklepanju 1C

Pri delu skrbnika ali razvijalca lahko pride do situacije, ko ni časa za preverjanje napake in iskanje temeljnih vzrokov težave. Na primer, oddati morate poročilo ali oddati podatke do določenega časa, napake pri blokiranju 1C pa to preprečijo.

Težavo lahko hitro rešite na dva načina:

• Poiščite in končajte sejo, ki je zaklenila zahtevane podatke. V majhnih podjetjih, kjer število uporabnikov 1C ne presega nekaj deset ljudi, je to najboljša rešitev;
• Če nadzorujete sistem, ki ima na stotine zaposlenih, lahko iskanje prave seje brez posebne programske opreme traja dolgo časa. V tem primeru bo veliko bolj učinkovito znova zagnati strežnik.

Te rešitve so radikalne in usmerjene le v hitro rešitev problema in objavo podatkov za nujno prijavo. Odpraviti ga je mogoče le z razumevanjem razloga, zaradi katerega je med izvajanjem transakcije 1C prišlo do konflikta zaklepanja. Po takih dejanjih je treba najti ranljivosti v sistemu, optimizirati konfiguracijo ali delo zaposlenih. Takih ukrepov ni priporočljivo uporabljati trajno z rednimi konflikti zaklepanja transakcij.