Fájladatbázis szűk keresztmetszetek – hogyan lehet elkerülni (a legutóbbi tapasztalatok alapján). Fájladatbázis szűk keresztmetszetek – hogyan lehet elkerülni (a legutóbbi tapasztalatok alapján) Nem sikerült zárolni a konfigurációs táblát

Ára 8,1, 5 felhasználóra.
Szokásos könyvelést alkalmazunk.
Főleg terminálon keresztül dolgoznak, néha anélkül.
Adatbázis opció - fájl
A terminálban lévők által észlelt hibák

valami ilyesmi. Feltúrtam a neten, a Yandexen - általában minden valahogy homályos.
Legfontosabb ajánlások:
1) Az adatbázis eltávolítása/betöltése - abban az értelemben, hogy újat hoz létre a konfigurátorból
2) futtassa a \Program Files\1cv81\bin\chdbfl.exe fájlt - az adatbázis fizikai integritásának ellenőrzése
3) Tesztelje és javítsa az információs bázist
4) frissítés a legújabb 8.1-es kiadásra

Valaki tud valami konkrétabbat?

13.5.2010, 10:05

Mindent, amire szüksége van, már javasolták Önnek; először próbálja ki. Vannak fizikai hibák az adathordozón?
Szerintem senki sem tud pontosabbat mondani.

13.5.2010, 10:56

Szóval ez... ha az 1C-re való tekintet nélkül tekintjük, hanem úgy általában, akkor hülyeségből valaki két helyről próbál blokkolni egy asztalt, az elsőnek sikerül, a többit meg elküldik. Nézd meg, milyen műveletek/tranzakciók/feldolgozások (vagy minek nevezik az 1C-ben) jelenleg. Könnyen lehet, hogy nem a platform a probléma, hanem a ferdén megírt konfigurációk, vagy az, ahogy ezek a konfigurációk az Ön adatain dolgoznak.

P.S. A többfelhasználós módban lévő fájl adatbázisok pedig perverziót jelentenek.

13.5.2010, 10:58

Bár ki a fene tudja, hogyan készül az adatbázis 1C-v-ben, könnyen lehet, hogy valahol az adatbázisban van valami probléma, és mindenféle javítás segít.

13.5.2010, 11:06

Igen, nekem úgy tűnik, hogy a nyolcszög olyan, mint egy emelvény - még mindig nedves. Valahol azt írták, hogy IDŐSZAKOSAN kell tesztelni, korrigálni

13.5.2010, 11:10

valószínűtlen. A nyolchoz új szervert vásároltak licencelt Windows-szal

A lényeg az, hogy az egyik lezárja az asztalt, a többi megvárja az időtúllépést.
Hogy miért nincs idejük, az nagy kérdés. Vessen egy pillantást a fizikai adathordozóra, lehet, hogy hülyeség. Rendszernapló MHDD. És mindazok a műveletek, amelyek az első bejegyzésben vannak, kötelezőek.

P.S. Az új nem azt jelenti, hogy 100%-ban működik.

13.5.2010, 11:38

Mindent, amire szüksége van, már javasoltak Önnek, először próbálja ki

szóval igen, estig várnunk kell.
Alig volt remény arra, hogy valami újat halljunk

Ne mondj csodákat. Rengeteg baj van, de ez nem az.

hol vannak a csodák? Nem értem, valaki azt fogja állítani, hogy a 8.1 egy menő, hibátlan platform?

azt írta, hogy a tesztelést és a javítást IDŐSZAKOSAN kell elvégezni

Úgy tűnik, nálunk is van ilyen eset.
A felhasználók egyéni felmérése (hogy ne hazudjanak együtt) azt mutatta, hogy ez a helyzet CSAK a terminálon dolgozó felhasználók körében fordul elő. És akik nem mennek át a terminálon, ahol
A Windows Server 2003 R2 Standart 64 vagy nem emlékszik erre a helyzetre, vagy egyszerűen nem jutott eszükbe.
Ráadásul két különösen figyelmes megjegyezte, hogy 1,5-2 hónappal ezelőtt ezt a jelenséget SOKKAL ritkábban észlelték

13.5.2010, 12:42

Gyilkos születésű, Van vírusirtó telepítve a szerverre? Ha igen, próbálja meg letiltani, vagy hozzáadni az adatbázist a kivételekhez

13.5.2010, 13:14

Van valami vírusirtó telepítve a szerverre?

Idk, meg kell néznem. Ez egy ellenséges szerver
smart-ass frank karbantartotta az egyik adatbázisunkat, biztonságossá tette a szerverét, és úgy tűnik, hogy felügyeli a munkánkat
hozzáférést biztosítottak a szerverükhöz, de lecsupaszított változatban.
Megnézem.

Úgy tűnik, nincs vírusirtó...

13.5.2010, 13:23

Nem értem, valaki azt fogja állítani, hogy a 8.1 egy menő, hibátlan platform?
igen, baszd meg. A 7.7 helyenként még baromság, de 8 körül itt az ideje legendákat írni a hibáiról

Mekkora az adatbázis és hány felhasználó?

Add hozzá. Mondj egy konkrét példát.
Mekkora az adatbázis és hány felhasználó?

Este csináltam egy tesztet és javítottam. Ezelőtt az 1cv8.1CD 2 GB volt, most 1,5 GB.
5 felhasználó van, valamint maga a licenc.
A hibákról szóló legendákkal kapcsolatban egy eset volt. Most, ha a 7.7-et veszed, és egyszerűen másolsz 1 adatbázist a Totalon keresztül egy másik helyre - egy másolatot probléma nélkül.
Egyszer megpróbáltam ugyanezt egy nyolcszoros adatbázissal megtenni, és átmásoltam az adatbázis-könyvtárat egy másik helyre,
regisztrált, mindkét adatbázist egyszerre nyitotta meg, az egyiket perverziókra szánták.
Több dokumentumot megjelöltem törlésre a másolatban, átváltottam a valódi adatbázist tartalmazó ablakra, és nem hittem a szememnek: ott is ugyanazok a dokumentumok voltak megjelölve törlésre.


Ash stump, 1C-nek mindenre van válasza: készíts napi másolatot az adatbázisról.
Igen, de ez egy rossz válasz

MMMarina

Gyilkos születésű,

Szia barátom...

Mítosz!
Így születnek a legendák...

Szia barátom...

Szia barátom. Szóval elragadtad magad

Aztán az asztalon lévő ikonok elhallgattak

Mítosz!
Így születnek a legendák...

Láttam. Nem volt vicces, hogy a törlési jel eltávolítása után különbséget tegyek a feladott és a nem feladott dokumentumok között, mindegyik feladatlan lesz.

Nem emlékszem, milyen platform volt akkor.

próbálja meg ugyanezt tenni. Talán te is meg tudod csinálni

Így születnek a legendák...

Még többet mondok: amikor manuálisan eltávolítottam néhány dokumentum jelölését törlésre,
Ugyanez történt a valódi adatbázisban is. Akkor nem volt időm valahogy dokumentálni ezt az érzést.
Szóval mindent visszatettem úgy, ahogy volt, és nem csináltam többet.

a számítógépes tudásban tátongó lyukak megszüntetése...
Azt hiszem, tényleg reménytelen vagyok...

Ez a téma egyáltalán nem neked szól, kedves (c)
általában minden érthető
szerezzen egy számítógépes geek barátot, mint lehetőség)))

Több dokumentumot megjelöltem törlésre a másolatban, átváltottam a valódi adatbázist tartalmazó ablakra, és nem hittem a szememnek: ugyanazok a dokumentumok voltak megjelölve törlésre, és ott a shok.gif

Soha nem másoltam fájl adatbázist nyolcaddal
Semmiképpen sem volt szenzáció.

Lehet, hogy nem hiszi el, de megtörtént.

Az a helyzet, hogy több évig nagyon szorosan együttműködtem a 8-cal. Amint nem másolták le. Szóval nem hiszem el
De feltételezhetem, hogy ha az ember túlfáradt, sok minden lehetséges. magamtól tudom.

Ne aggódjon, a fájl adatbázis könnyen másolható és bármilyen más módon előállítható. Semmiféle hibának nem szabad lennie.

14.5.2010, 10:52

14.5.2010, 11:28

Van egy tippem: kétszer regisztráltam ugyanazt az adatbázist parkoláskor.

8 ajánlat a cserére

14.5.2010, 11:31

nem... a 7.7, amikor ezt próbálom, hülyén hallgat, és nem adja hozzá az adatbázist a listához (egyáltalán nem reagál)
8 ajánlat a cserére

Lehet, hogy csak elvétettem egy egérrel, és elindítottam ugyanazt... Csodák nem történnek

14.5.2010, 11:47

Lehet, hogy csak eltévesztettem a jelet az egérrel, és elindítottam ugyanazt...

Megpróbálok valami hasonlót itthon modellezni. Majd később írok.
Általában minden veszélyes művelet előtt az 1C-ben (7.7. vagy 8.) rákattintok a kérdőjelre (az adatbázis elérési útja ott látható).

Aztán az emberek olyan egyhangúlag nevettek a legendámon, hogy kételkedni kezdtem benne.
Bár a nyolcasban több a hiba, mint a hetesben.

Ó, milyen hülye hiba, nem én voltam az egyetlen, aki ezt látta.
Általában kigúnyoltak egy 8. bázist egy ügyfélnél, amikor még a franchise-ban dolgoztam.
Egyik nap az egyik ember, a másik - a második, a harmadikon én mentem. Megkérdeztem őket – készítettek biztonsági másolatot a kizsákmányolás előtt? Válaszul - nyüszítenek, mint a lovak, röviden gólt szereztek, csak ők vették a bázist azon az autón

14.5.2010, 12:35

- nyögnek, mint a lovak, rövidebbre lőtték, csak helyben vették a bázist,
és lehetőségem volt kiszedni a netről. Az előző Tavarischi példáját követve úgy döntöttem, hogy nem készítek biztonsági másolatot,
Fiatal volt és buta – sok volt a hivalkodás.
Általában változtattam a conf-on, elmentem a conf-ot, a konf mentése közben valami baleset történt, és az adatbázis leesett, este. Sokk. Reggel 3 szakorvos, köztük én mentem oda.
A baleset az volt, hogy a kiadási számot letépték az adatbázisból, i.e. a konfigurációban, amikor rákattintott a kérdésre, az üres volt, és maga a conf neve hiányzott. és amikor bementem az adatbázisba, semmi nem látszott, beleértve a felületet is. elrepült, nem lehetett belépni az okmánynaplókba.
Úgy oldottuk meg a problémát, hogy a megölt adatbázist frissítettük egy viszonylag friss konfigurációs fájllal, minden sikerült.
Minden újjászületett.
Ez egy igazi legenda példa. 3 embernek nem szabad egyszerre hibáznia

14.5.2010, 13:53

a konf mentése közben valami baleset történt és leesett az adatbázis

Nos, ha hardveres hiba volt, akkor semmi meglepő.
De ha olyan hibát talál, amely bizonyos műveletek végrehajtása után következetesen megjelenik, akkor az egy másik történet.

14.5.2010, 14:39

Nos, ha hardveres hiba volt, akkor semmi meglepő

Idk, mi történt. a vas, a háló vagy az emelvény most nem olyan fontos.
Számomra úgy tűnik, hogy a szoftvernek nem kellene ilyen elbűvölően viselkednie
Ez ugyanaz, mint a Vista kiadása és beismerése, hogy ez baromság. Valahogy gyorsan 8,0-ról 8,1-re ugrottak
P.S. Értem a bug szó jelentését, köszönöm az aggódást)))

14.5.2010, 19:37

Tegyük fel, hogy ha szervizcsomagok vagy valami fontos Vista-ra gurításkor hasonló „hiba” történik, akkor valószínű, hogy a rendszer, még ha elindul is, rendkívül instabilan fog működni.
Vagy mondjuk az inzulin bevétele pillanatában földrengés történik, akkor a cukorbeteg meghalhat, mert. a fecskendő remegés közben a kanapé alá gurult.

14.5.2010, 22:32

Born Killer, telepítve van vírusirtó a szerveren? Ha igen, próbálja meg letiltani, vagy hozzáadni az adatbázist a kivételekhez

Hogyan befolyásolhatja egy vírusirtó az asztalzárakat? adatbázis 8.x egy fájl.

Több dokumentumot megjelöltem törlésre a másolatban, átváltottam a valódi adatbázist tartalmazó ablakra, és nem hittem a szememnek: ugyanazok a dokumentumok voltak megjelölve törlésre, és ott a shok.gif
Általában nem szerettem ezt a kibaszott felsőket, azóta csak a Feltöltés/Betöltés segítségével készítettem másolatot az adatbázisról.
Hogy tetszik ez a szomorú legenda, uram?
Mi van, ha elragadtattam és komolyabb dolgokat csináltam a másolatban (például töröltem a törlésre jelölt dokumentumokat), és valamilyen tisztázatlan módon ugyanazokat a műveleteket hajtották végre a fő adatbázisban?

Nem, ez nem lehet, csodák nem történnek. Valószínűleg ugyanabba az adatbázisba jelentkeztél be... 8-ban gond nélkül 2x be tudsz lépni az adatbázisba ugyanazzal a névvel.

A nyomtatványhibás dokumentumok vezetésekor/rögzítésénél időről időre problémák jelentkeztek
"Zárolási ütközés a tranzakció során: A '_DOCUMENT158' tábla nem zárolható

Tehát először meg kell határoznia, hogy a „_DOCUMENT158” tábla melyik metaadat-dokumentumnak felel meg. Erre a célra létezik egy globális kontextus metódus, a „GetDatabaseStorageStructure”. Így legalább pontosan megérti, melyik dokumentum „hibás”.

Aztán meg kell érteni, hogy valaki cserélt-e benne vezetési modult, és fejbe kell kopognia, ha egy helyen cserélte. Valószínűleg a regiszterrekordokat kifejezetten a Write metódussal írják, ahelyett, hogy lehetővé tennék a platform számára, hogy ezt helyesen tegye. És a sorrendjük zavaros...
Nincsenek holtpontok?

Általában 5 embert nem szabad fájl módban tartani. Vehetsz egy ingyenes subd-t, veszel csak egy kulcsot a fürtkiszolgálóhoz, és ennyi. Vagy túl drága az irodának?
Nem emlékszem, hogy a technológiai naplót le lehet-e lőni fájl módban vagy sem.....

14.5.2010, 22:53

=========================================================
http://odines.ru/thread1386.html - ez a te szálad?

Vagyis a tranzakció akkor sem megy át, ha egy felhasználó dolgozik?? Akkor valószínűleg nem a görbe kódban van a probléma a mozgások rögzítésekor. Mert egyfelhasználós módban nem lehetnek zárak. A felvétel szekvenciálisan történik.

Akkor úgy tűnik, hogy a probléma magának az adatbázisnak a szerkezetében rejlik.
Jobb először az adatbázis tesztelését és javítását végrehajtani az "Információsbázis táblák átstrukturálása" jelzővel.
A dt-re feltöltés, majd a betöltés is értelmes...
A chdbfl.exe ebben az esetben valószínűleg nem segít... bár persze egy próbát megér, ha minden más nem segít.

Gee - most néztem meg a bejegyzések dátumát a http://odines.ru/thread1386.html szálban, és a szabványosak fejlesztése új vezérelt módban nincs messze.
A 8.2 és 8.1 között pedig sokkal nagyobb a különbség, mint a 8.1 és 7.7 között, főleg a fejlesztőknek teljesen át kell építeni az agyukat, hogy „vezérelt” üzemmódra fejleszthessenek.

A beteg tünetei és története:

A hálózaton keresztül ugyanazzal a fájllal (adatbázissal) végzett több felhasználó munkája hálózati blokkoló mechanizmust tartalmaz. Ez arra kényszeríti a rendszert, hogy értékes időt veszítsen az azonosításra nyílt ülések nyilvántartások, és ennek megfelelően a konfliktusok megoldása.

A blokkoló működés fő jelei:

• gyors felhasználói munka az adatbázissal a hálózaton keresztül exkluzív módban, és rendkívül lassú, ha több felhasználó dolgozik egyszerre
• gyors felhasználói élmény egy helyi adatbázissal a szerveren és lassú munka a hálózaton keresztül
• apellál fájlrendszer alig 10 MB/sec

Így azt a feladatot kaptam, hogy gondoskodjak arról, hogy akár három felhasználó is dolgozhasson 1C-ben egyszerre! Vicces, nem?

Elfelejtettem az összes viccet, amikor megláttam, hogy mivel kell megküzdenem: egy „szerverrel”, amelyet egy hétköznapi képvisel irodai számítógépés két laptop.

A boldogság hiányos lenne, ha nem lennének a csodálatosak OS- számítógépen és egyben Windows laptop 7, másrészt Windows 8.

Amikor egyidejűleg próbált dokumentumokat feltenni laptopokra, az egyik körülbelül egy percig elakadt, a második pedig kizuhant az 1C-ből a „nem sikerült lezárni az asztalt...” hibaszöveggel.

Az 1C laptopon való elindítása egy külön műsor, ami kb 3 perc!

Számos forrásnál találkoztam tanácsokkal, hogy váltsam át a terminálhozzáférésre. Sajnos a Windows 7 nem teszi lehetővé rendszeres eszközökkel terminálkiszolgálóvá alakul - legfeljebb egy aktív kapcsolat. Ebben az esetben a fennmaradó munkamenetek nem szűnnek meg, újra csatlakozhat egy másik felhasználóhoz - „kidobva” az előző felhasználót, de anélkül, hogy megszakítaná a munkamenetét. Ezért az 1C-t át kell vinnie egy szerver operációs rendszerre, ahol nincsenek ilyen korlátozások. Az ügyfél saját felelősségére egy harmadik féltől származó segédprogram segítségével oldotta meg a problémát Windows7_SP1_RDPhack.

De a kalandok ezzel nem értek véget. Még a terminálkapcsolatban is jelentős késések voltak. A mindenható keresőmotorok ismét segítettek. Az alábbiakban tippeket adunk az 1C fájl felgyorsításához, amelyeket követtem:

1. Letiltás hálózati protokoll használata IPv6, konfigurálja a címzést a „régi” IPv4-en.

2. Adjon hozzá 1C folyamatokat a kivételekhez Windows tűzfal, valamint a vírusirtó kivételek esetén, vagy teljesen letilthatja azokat (kockázatosabb, de egy egyszerű teszt kimutatta sebesség növekedés dokumentumok újraátvitele, ha az Avast antivirus le van tiltva tényezője!)

3. Kezdje el indexelni a teljes szöveges keresést 1C-ben, vagy kapcsolja ki teljesen

4. Futtassa az adatbázis tesztelését és javítását, ellenőrzést a ChDbfl segédprogrammal

5. Futtassa a Konfiguráció ellenőrzése elemet a konfigurációban (ha a konfiguráció nem szabványos, ez hasznos lehet). A konfiguráció ellenőrzésének eredménye alapján varázslatosan csaknem harmadával csökkent a mérete. Nem igazán mélyedtem el abban, hogy a beérkező programozók pontosan mit frissítettek előttem, de a tény nyilvánvaló.

6. Tiltsa le a szükségtelen funkcionális opciókat.

7. Állítsa be a felhasználói jogosultságokat. (Ez és az előző tanács hülyeségnek tűnt, amíg meg nem néztem a rajzot kezelt űrlapok a dokumentumlista megnyitásakor. Minél kevesebb a felesleges dolog egy felügyelt felületen, annál gyorsabban működik, általában)

8. Kezdje el újraszámolni az összegeket és állítsa vissza a sorrendet (jelentős növekedés csak akkor következhet be, ha hosszú ideje az eredményeket nem állították helyre)

9. Adja meg az adatbázis lista beállításainál a "Connection speed - low"-t (ez nem sok eredményt hozott, kivéve, hogy az alrendszerek képei kikapcsolva :))

Mindezen lépések elvégzése után az 1C fájladatbázis sokkal gyorsabban kezdett működni. Maximum 10 másodperc alatt indult el, a dokumentumátvitel sebessége pedig átlagosan 12-szeresére nőtt.

Talán ez a rövid cikk hasznos lesz az Ön számára, ha hirtelen fel kell gyorsítania 1C fájladatbázisát.

Ui.: És futtassa az 1C fájlt a használatával hálózati hozzáférés megosztott mappába – még mindig irreális, mert Dasha a leggyorsabb Solid State Drive, RAM a processzor pedig beszorul a hálózati dugásokba, és több felhasználó munkája gyakorlatilag lehetetlenné válik. Kifejezetten az UT 11.1 konfigurációjáról beszélünk. Saját írás kis konfigurációk Még a fájl verzióban is elég gyorsan működnek.

Kiegészítések a megjegyzésekből közzétételre:

Lemez töredezettségmentesitő fájlbázissal

Konvolúció adatbázis (hasznos lehet, ha az adatbázis nagy, például több éve). Az ügyfél adatbázisa meglehetősen fiatal volt, így a csökkentés nem volt praktikus.

Hardverfrissítés – gyorsabb merevlemez, új kapcsoló, processzor stb.

Telepítés webszerverre, hozzáférés segítségével vékony kliens. Itt megoszlanak a vélemények. Egyesek szerint sokszor gyorsabb, mások szerint nincs gyorsulás.

A többfelhasználós rendszerekben a szerkezet megfelelő szervezése és a zárak felállítása fontos szerepet játszik. Ha nincs ott, akkor a felhasználóknak gyakran meg kell küzdeniük bizonyos rendszererőforrásokért folytatott verseny okozta hibákkal. De van egy zárkonfliktus probléma, amely sok felhasználó számára ismerős. Miért fordul elő 1C zár ütközés, és hogyan lehet megoldani?

Ütközés zárolása az 1C 8.3-ban és annak jelentésében

A legtöbb felhasználó számára az 1C zárkonfliktusról szóló üzenet csak olyan hibát jelent, amely megakadályozza a munkájuk elvégzését. A lehető leggyorsabban meg akarnak szabadulni ettől a problémától, és olyan panaszokkal ostromolni az IT osztályt, hogy „az 1C nem működik”.

De érte rendszergazdákés a fejlesztők számára, egy ilyen üzenet a konfigurációs struktúra esetleges problémáira utal. Mielőtt megpróbálna a felhasználók kedvében járni és megszüntetni az elakadásokat, elemeznie kell a helyzetet, és meg kell értenie a hibaüzenet okát.

A blokkolási hibák okai az 1C-ben

Demonstratív terhelési tesztek bizonyítják, hogy az 1C szerver több mint ötezer felhasználó párhuzamos működését is kibírja. Az ilyen kísérletek ideális feltételei azonban a nagy- és középvállalatok mindennapi körülményei között elérhetetlenek. A hasonló teljesítmény és hibamentes működés érdekében a konfigurációt ideálisan kell megtervezni és a vállalat konkrét üzleti folyamataihoz igazítani.

Ha nem választja az ideális lehetőségeket, akkor az 1C zárolási ütközések a következő okok miatt fordulnak elő:

A felhasználók egyidejű munkája nagy mennyiségű adattal. Ezt a kiváltó okot az 1C belső mechanizmusai diktálják. Ezek magukban foglalják egy másik felhasználó nevében indított tranzakcióban érintett adatok módosításának megtiltását;

Hibák és hiányosságok a konfigurációban. Az 1C vállalat szabványos megoldásainak szerkezete figyelembe veszi a termelékenység maximalizálására vonatkozó ajánlásokat. A harmadik féltől származó fejlesztők azonban nem mindig tartják be a magas szabványokat, és a kódjukban gyakran a következő hibák találhatók:

• Szuboptimális lekérdezések;
• Egyenlegek kérése az akciók kezdetén;
• A konfigurációs objektumok céljának félreértése és helytelen használata;
• A rendszerbe épített vagy kiegészítő fejlesztésű reteszek redundanciája.

A zárolási ütközés kijavítása az 1C 8.3-ban

A „zárolási ütközés 1C 8.3 tranzakció végrehajtásakor” rendszerüzenet nem minősíti a konfigurációt hibásan megtervezettnek. De ha figyelmen kívül hagyják az ilyen jelzéseket, akkor a legdöntőbb pillanatban nagy problémákba kerülhet, például a negyedéves vagy éves jelentések benyújtásakor. Legjobb esetben lomha rendszer és elégedetlen felhasználók. A legrosszabb esetben a kimeneti adatok helytelenek, ami a szabályozó hatóságok szankcióit vonhatja maga után.

A megoldás a zárkonfliktusok problémájára az 1C 8.3-ban a konfiguráció átvitele kezelt (kézi) zárkezelési módba. A 8.1-es verzióban megvalósított mechanizmus az illetékes szakemberek kezében oldja meg a zárkonfliktusok problémáját az 1C tranzakció során.

De érdemes szem előtt tartani, hogy ez a művelet csökkenti az adatok védelmének szintjét a változásokkal szemben, miközben más felhasználók olvassák azokat. Ezért, ha nem áll készen a rendszer összes zárának önálló vezérlésére, ne rohanjon a konfigurációs beállítások megváltoztatásával.

Gyors megoldás az 1C zárolási konfliktusra

Az adminisztrátor vagy fejlesztő munkájában olyan helyzet adódhat, amikor nincs idő a hiba ellenőrzésére és a probléma kiváltó okainak felkutatására. Például egy bizonyos időpontig jelentést vagy adatokat kell benyújtani, de az 1C blokkoló hibák ezt megakadályozzák.

A probléma gyors megoldásának két módja van:

• Keresse meg és fejezze be azt a munkamenetet, amely blokkolja a szükséges adatokat. Kis cégeknél, ahol az 1C felhasználók száma nem haladja meg a pár tucat főt, ez legjobb lehetőség megoldások;
• Ha több száz alkalmazottal vezérel egy rendszert, megtalálja a megfelelő munkamenetet szakember nélkül szoftver sokáig tarthat. Ebben az esetben sokkal hatékonyabb lesz a szerver újraindítása.

Ezek a döntések radikálisak és csak arra irányulnak gyors döntés problémák és a jelentések sürgős benyújtásához szükséges adatok kiadása. Csak úgy lehet felszámolni, ha megértjük, miért alakult ki zárolási konfliktus egy 1C tranzakció végrehajtása során. Az ilyen műveletek után meg kell találni a rendszer sebezhetőségeit, optimalizálni kell az alkalmazottak konfigurációját vagy munkáját. A tranzakciók rendszeres zárolási konfliktusai esetén nem javasolt az ilyen intézkedések folyamatos alkalmazása.

Az 1C-ben végzett munka során nem ritka a „Zárolási ütközés a tranzakciók végrehajtása során: túllépte a zárolás engedélyezésének maximális várakozási idejét” hibaüzenetet. Lényege abban rejlik, hogy több munkamenet próbál egyidejűleg hasonló műveleteket végrehajtani, ugyanazt az erőforrást érintve. Ma kitaláljuk, hogyan lehet ezt a hibát kijavítani.

Nagyszámú végrehajtott művelet

Az okok keresésének első lépése annak tisztázása, hogy hány egyidejű felhasználó van abban az információs bázisban, amelyben egy ilyen hiba keletkezik. Mint tudjuk, maximális számuk meglehetősen nagy lehet. Ez ezer és ötezer is.

A zárolás és a tranzakciók mechanizmusát a fejlesztői útmutató ismerteti. Akkor használatosak, ha több munkamenet egyszerre éri el ugyanazt az adatot. Logikus, hogy ugyanazok az adatok nem változtathatók meg különböző felhasználók által ugyanabban a pillanatban.

Azt is ellenőriznie kell, hogy valamelyik felhasználó futtat-e tömeges adatmódosítási feldolgozást. Ez lehet például hónap vége és hasonlók. Ebben az esetben a feldolgozás befejezése után a hiba magától eltűnik.

Ütemezett feladatok

Nem ritka, hogy a hiba oka egy nagy mennyiségű adatot feldolgozó rendszerben keresendő. Javasoljuk, hogy ilyen dolgokat éjszaka végezzen. Állítson be ütemezést az ilyen rutinfeladatok munkaidőn kívüli elvégzésére.

Így mindkét felhasználó stabil rendszerben fog dolgozni, és ők maguk is rutinfeladatokat sikeresen befejeződik, mivel csökken a felhasználói munkamenetekkel való ütközések valószínűsége.

"Hung sessions"

A felhasználók „elakadt munkameneteinek” problémája szinte mindenki számára ismert, aki találkozott az 1C szolgáltatással. A felhasználó már régen kiléphetett volna a programból, vagy bezárhatott volna egy dokumentumot, de a munkamenete továbbra is a rendszerben marad. A probléma leggyakrabban elszigetelt, és elegendő egy ilyen munkamenetet a rendszergazdai konzolon keresztül befejezni. Ugyanezek a problémák merülhetnek fel a háttérmunkáknál is.

Számos internetes megjegyzés szerint az ilyen helyzetek gyakrabban fordulnak elő hálózati biztonsági kulcsok használatakor. Ha a „lefagyott munkamenetek” szisztematikusan megismétlődnek, ez indokolja a rendszer és a szerverek (ha az adatbázis kliens-szerver) alapos ellenőrzését és karbantartását.

Hibák a konfiguráció írása közben

Minden szabványos konfigurációt képzett szakemberek és szakértők fejlesztenek ki. Minden rendszert alaposan tesztelnek és optimalizálnak a gyorsabb és pontosabb működés érdekében.

Ebben a tekintetben a hiba oka egy külső fejlesztő által írt, szuboptimális kódban keresendő. Ez egy „súlyos” kérés lehet, amely hosszú ideig blokkolja az adatokat. Gyakran előfordulnak olyan esetek is, amikor alacsony teljesítményű és a logikát sértő algoritmusokat készítenek.

Nagy a valószínűsége annak, hogy a zárolási konfliktus éppen a fejlesztői hibák miatt keletkezett, ha az egy programfrissítés után keletkezett. Az ellenőrzéshez egyszerűen „visszagörgetheti” a fejlesztéseket, vagy újrafaktorálhatja a kódot.

Milyen gyakran látja ezt az üzenetet? Szerintem mindenki, akinek hosszú távú tapasztalata van az 1C-vel kapcsolatban, legalább egyszer találkozott ilyen hibával. Miért produkál ilyen hibát a program? "Zárolási ütközés a tranzakció során: A tábla zárolása nem sikerült"?

Nos, ez leggyakrabban annak a ténynek köszönhető, hogy az egyik felhasználó már végez valamilyen műveletet, amely blokkolt ezt a táblázatot. A probléma megoldásához minden felhasználónak ki kell lépnie a programból. De az is előfordul, hogy a felhasználó kilép a programból, de a programfolyamat nem kerül ki a memóriából. Ne essen pánikba! Ha minden felhasználó kilépett a programból, de az üzenet továbbra is megjelenik, akkor meg kell nyitnia az Eszközök menü -> Aktív felhasználók menüpontot.

És nézd meg, hogy rajtad kívül kik vannak benne Ebben a pillanatban működik a programmal. Ha minden felhasználó kijelentkezett, és továbbra is azt látja, hogy rajtad kívül van még valaki, ne ijedjen meg. Megtörténik. A folyamat elakadt. Indítsa újra a felhasználó aktív módban lévő számítógépét.

De néha még ez sem oldja meg a problémát. Előfordul, hogy a tranzakció végrehajtása közben a lámpa villog, vagy pl HDD az utolsó lábán. És ami szintén valószínű, valaki kivette a hálózati hub vezetékét, és a helyére kapcsolta a vízforralót, és abban a pillanatban értékcsökkenést számolt. Így ilyenkor az adatbázis megsérülhet, vagy hibásan rögzíthetők az adatok.

Ebben az esetben és szinte mindig, ha a fenti receptek nem segítettek, a chdbfl.exe segédprogram segít. A következővel rendelkező mappában található futtatható fájl 1C. A fájl elérési útja hozzávetőlegesen a következő lesz: „C:\Program Files\1Cv82\platform_version_number\bin\chdbfl.exe”. Kérjük, vegye figyelembe, hogy ez a segédprogram a platform egyik verziójából nem biztos, hogy egy másik verzióban működik.

Ezért meg kell nyitnia a mappát az aktuális platform számával, amelyen dolgozik.

Hogyan láthatom a platform számát? Nagyon egyszerű. Lépjen az Eszközök -> A programról menübe. És akkor a képen látható, hogy hol kell keresni a platform számát.

Jelölje be az „Az észlelt hibák javítása” jelölőnégyzetet. És kattintson a végrehajtás gombra. Ez a segédprogram kijavítja az összes előforduló hiba 90%-át. Erősen ajánlom, hogy a segédprogram használata előtt tegye meg biztonsági másolat adatbázis, de ha a hiba éppen a kirakodás pillanatában jelentkezik, akkor másolja ki a teljes mappát innen információs bázis adat.