Uska grla baze podataka - kako izbjeći (iz nedavnog iskustva). Uska grla baze podataka - kako izbjeći (iz nedavnog iskustva) Neuspješno zaključavanje konfiguracijske tablice
Cijena 8,1 set za 5 korisnika.
Koristimo standardno računovodstvo.
Rade uglavnom preko terminala, ponekad i bez njega.
Opcija baze podataka - datoteka
Pogreške koje su primijetili oni u terminalu
nešto kao ovo. Preturao sam po mreži, Yandex - općenito, sve je nekako nejasno.
Pronađene ključne preporuke:
1) Iskrcaj/Učitaj bazu - u smislu kreiranja nove iz konfiguratora
2) pokrenite \Program Files\1cv81\bin\chdbfl.exe - provjera fizičkog integriteta baze podataka
3) Testirajte i ispravite informacijsku bazu
4) ažuriranje na najnovije izdanje 8.1
Zna li netko nešto konkretnije?
13.5.2010, 10:05
Sve što vam je potrebno već vam je predloženo; prvo pokušajte. Postoje li fizičke pogreške na mediju?
Mislim da nitko ne može biti konkretniji.
13.5.2010, 10:56
Dakle ovo... ako uzmemo u obzir bez obzira na 1C, ali općenito, onda glupo netko s dva mjesta pokušava blokirati jednu tablicu, prvi uspije, a ostali se šalju. Pogledajte koje se operacije/transakcije/obrade (ili kako god to zovu u 1C) izvode u ovom trenutku. Vrlo je moguće da problem nije u platformi, već u krivo napisanim konfiguracijama ili načinu na koji te konfiguracije rade na vašim podacima.
p.s. A baze datoteka u višekorisničkom načinu su perverzija.
13.5.2010, 10:58
Iako tko dovraga zna kako se radi baza podataka u 1C-v, može biti da negdje u bazi postoji problem i svakakvi popravci će pomoći.
13.5.2010, 11:06
Da, čini mi se da je oktogon poput platforme - još je vlažan. Negdje su napisali da se testiranje i korekcija moraju raditi PERIODIČNO
13.5.2010, 11:10
malo vjerojatno. Za osmicu je kupljen novi server s licenciranim Windowsima
Suština je da jedan zaključava stol, a ostali čekaju do timeouta.
Zašto nemaju vremena veliko je pitanje. Pogledaj fizičke medije, možda je glupo. Dnevnik sustava MHDD. I sve one radnje koje su napisane u prvom postu su obavezne.
p.s. Novo ne znači da 100% radi.
13.5.2010, 11:38
Sve što vam je potrebno već vam je predloženo, prvo pokušajte
pa da, moramo čekati do večeri.
Bilo je malo nade da ću čuti nešto novo
Ne pričaj čuda. Ima tu dosta nevolja, ali ovo nisu one.
gdje su čuda? Ne razumijem, netko će tvrditi da je 8.1 cool, besprijekorna platforma?
napisao da se testiranje i korekcija moraju obavljati PERIODIČNO
Izgleda da imamo takav slučaj.
Anketa korisnika pojedinačno (da ne lažemo zajedno) pokazala je da se ova situacija događa SAMO među korisnicima koji rade na terminalu. A oni koji ne prolaze kroz terminal gdje
Windows Server 2003 R2 Standart 64, ili se ne sjećaju ove situacije, ili im jednostavno nije pala na pamet.
Štoviše, dvoje posebno pažljivih primijetilo je da je prije 1,5-2 mjeseca ova pojava uočena PUNO rjeđe
13.5.2010, 12:42
Rođeni ubojica, Je li na poslužitelju instaliran antivirusni program? Ako da, pokušajte ga onemogućiti ili dodati bazu podataka u iznimke
13.5.2010, 13:14
Je li na serveru instaliran neki antivirus?
Idk, morat ću pogledati. Ovo je neprijateljski poslužitelj
pametni franci su uzeli jednu od naših baza podataka na održavanje, osigurali njihov poslužitelj i čini se da nadziru naš rad
omogućen je pristup njihovom serveru, ali u ogoljenoj verziji.
pogledat ću.
Čini se da nema antivirusa...
13.5.2010, 13:23
Ne razumijem, netko će tvrditi da je 8.1 cool, besprijekorna platforma?
da, jebi ga. 7.7 je još mjestimično sranje, ali oko 8 vrijeme je da se o njegovim kvarovima ispišu legende
Kolika je baza podataka i koliko korisnika?
Zbrojite. Navedite konkretan primjer.
Kolika je baza podataka i koliko korisnika?
Noću sam napravio test i popravio ga. Prije ovoga, 1cv8.1CD je imao 2GB, sada je 1.5GB.
Ima 5 korisnika, kao i sama licenca.
Što se tiče legendi o greškama, bio je jedan slučaj. E sad, ako uzmeš 7.7 i jednostavno kopiraš 1 bazu preko Totala na drugo mjesto - kopija bez problema.
Jednom sam pokušao učiniti istu stvar s osmerostrukom bazom podataka, kopirao direktorij baze podataka na drugo mjesto,
registriran, otvorio obje baze istovremeno, jedna je bila namijenjena perverzijama.
U kopiji sam označio nekoliko dokumenata za brisanje, prebacio se na prozor s pravom bazom podataka i nisam mogao vjerovati svojim očima: isti dokumenti su i tamo označeni za brisanje
Ash panj, 1C ima odgovor na sve: napravite dnevnu kopiju baze podataka.
Da, ali ovo je loš odgovor
MMMarina
Rođeni ubojica,
Bok prijatelju...
Mit!
Ovako se rađaju legende...
Bok prijatelju...
Bok prijatelju. Pa ste se zanijeli
A onda su ikone na radnoj površini utihnule
Mit!
Ovako se rađaju legende...
Vidjela sam to. Nije mi bilo smiješno razlikovati objavljene dokumente od nepostavljenih nakon uklanjanja oznake za brisanje, svi postaju nepostavljeni.
Ne sjećam se koja je platforma tada bila.
pokušajte učiniti isto. Možda i ti to možeš
Ovako se rađaju legende...
Reći ću više: kada sam ručno uklonio oznaku nekoliko dokumenata za brisanje,
Ista se stvar dogodila u stvarnoj bazi podataka. Tada nisam imao vremena nekako dokumentirati ovu senzaciju.
Tako da sam jednostavno sve vratio kako je bilo i nisam to ponovio.
uklanjanje rupa u informatičkom znanju...
Stvarno mislim da sam beznadan...
Ova konkretna tema uopće nije za tebe draga (c)
općenito, sve je razumljivo
Nađi prijatelja s računalnim štreberom, kao opciju)))
Označio sam nekoliko dokumenata za brisanje u kopiji, prebacio se na prozor s pravom bazom podataka i nisam mogao vjerovati svojim očima: isti dokumenti su označeni za brisanje i tamo shok.gif
Nikada nisam kopirao bazu podataka datoteka s osmom
To nikako nije bila senzacija.
Možda nećete jebeno vjerovati, ali DOGODILO SE.
Činjenica je da sam nekoliko godina vrlo blisko surađivao s 8. Čim nisu kopirani. Pa ne mogu vjerovati
Ali mogu pretpostaviti da je, kad je čovjek premoran, puno toga moguće. Znam to od sebe.
Ne brinite, baza podataka datoteka može se jednostavno kopirati i podići na bilo koji drugi način. Ne bi trebalo biti nikakvih grešaka.
14.5.2010, 10:52
14.5.2010, 11:28
Pretpostavljam: dvaput sam registrirao istu bazu podataka kad sam bio parkiran.
8 ponuda za zamjenu
14.5.2010, 11:31
ne... 7.7, kad pokušam ovo napraviti, glupo šuti i ne dodaje bazu podataka na popis (jednostavno uopće ne reagira)
8 ponuda za zamjenu
Možda sam samo promašio mišem i lansirao isti... Čuda se ne događaju
14.5.2010, 11:47
Možda sam samo promašio mišem i pokrenuo isti...
Pokušat ću napraviti nešto slično kod kuće. pisat ću kasnije.
Obično, prije bilo kakve opasne akcije, u 1C (7.7. ili 8) kliknem na upitnik (tamo je prikazan put do baze podataka).
Tada su se ljudi smijali mojoj legendi tako jednoglasno da sam počeo sumnjati u nju.
Iako u osmici ima više kvarova nego u sedmici.
Oh, kakva glupa greška, nisam bio jedini koji je ovo vidio.
Općenito, rugali su se jednoj osmoj bazi kod klijenta dok sam još radio u franšizi.
Jednog dana jedna osoba, druga - druga, trećeg sam otišao. Pitao sam ih - jesu li napravili sigurnosnu kopiju prije exploita? Kao odgovor - njišu ko konji, zabili su ukratko, samo su uzeli bazu na tom autu
14.5.2010, 12:35
- njišu ko konji, zabili su kraće, samo su bazu uzeli lokalno,
a imao sam je priliku pojebati s neta. Po uzoru na prethodni Tavarischi, odlučio sam ne napraviti sigurnosnu kopiju,
Bio je mlad i glup - bilo je dosta razmetanja.
Općenito, napravio sam izmjene u conf-u, spremim conf, dok sam spremio conf dogodila se neka nezgoda i baza je pala, navečer. Šok. Ujutro su tamo otišla 3 specijalista, uključujući i mene.
Nesreća je bila u tome što je broj izdanja istrgnut iz baze podataka, tj. u konfiguraciji, kad ste kliknuli na pitanje, ono je bilo prazno, a nedostajao je i naziv same conf. a kad se ušlo u bazu nije se vidjelo ništa, uključujući sučelje. odletio, nije bilo moguće ući u zapisnike dokumenata.
Riješili smo problem ažuriranjem ubijene baze podataka s relativno svježom konfiguracijskom datotekom, sve je funkcioniralo.
Sve se preporodilo.
Ovo je primjer prave legende. 3 osobe ne bi trebale griješiti u isto vrijeme
14.5.2010, 13:53
prilikom spremanja confa dogodila se neka nezgoda i baza je pala
Pa, ako je to bio hardverski kvar, onda ništa ne čudi.
Ali ako ste pronašli bug koji se stalno pojavljuje nakon izvođenja određenih radnji, onda je to druga priča.
14.5.2010, 14:39
Pa, ako je to bio hardverski kvar, onda ništa ne čudi
Idk, što se dogodilo. željezo, mreža ili platforma sada nije toliko važno.
Čini mi se da se softver ne bi trebao ponašati tako očaravajuće
Ovo je isto kao pustiti Vistu i priznati da je sranje. Nekako su brzo s 8.0 skočili na 8.1
p.s. Razumijem značenje riječi buba, hvala na brizi)))
14.5.2010, 19:37
Recimo, ako se prilikom ubacivanja servisnih paketa ili nečeg važnog na Vistu dogodi sličan “glitch”, onda je vjerojatno da će sustav, čak i ako se podigne, raditi krajnje nestabilno.
Ili, recimo, u trenutku uzimanja inzulina dogodi se potres, tada dijabetičar može umrijeti, jer. šprica se tresući otkotrljala ispod sofe.
14.5.2010, 22:32
Rođeni ubojica, ima li antivirusni program instaliran na poslužitelju? Ako da, pokušajte ga onemogućiti ili dodati bazu podataka u iznimke
Kako antivirus može utjecati na zaključavanje tablice? baza podataka 8.x je jedna datoteka.
Označio sam nekoliko dokumenata za brisanje u kopiji, prebacio se na prozor s pravom bazom podataka i nisam mogao vjerovati svojim očima: isti dokumenti su označeni za brisanje i tamo shok.gif
Općenito, nije mi se sviđao ovaj jebeni vrh, od tada sam napravio kopiju baze podataka samo putem Upload/Load.
Kako vam se sviđa ova tužna legenda, gospodine?
Što ako sam se zanio i napravio ozbiljnije stvari u kopiji (npr. izbrisao dokumente označene za brisanje), a na neki nejasan način iste radnje su izvršene u glavnoj bazi?
Ne, to ne može biti, čuda se ne događaju. Vjerojatno si se ulogirao u istu bazu... U 8 se bez problema možeš ulogirati u bazu 2 puta pod istim imenom.
S vremena na vrijeme javljali su se problemi kod vođenja/snimanja dokumenata s greškom obrasca
"Sukob zaključavanja tijekom transakcije: nije moguće zaključati tablicu '_DOCUMENT158'
Dakle, prva stvar koju trebate učiniti je odrediti kojem dokumentu metapodataka odgovara tablica “_DOCUMENT158”. U tu svrhu postoji metoda globalnog konteksta “GetDatabaseStorageStructure”. Tako ćete barem točno shvatiti koji je dokument "buggy".
Zatim morate razumjeti je li netko promijenio modul provođenja u njemu i pokucati po glavi ako ga je promijenio na jednom mjestu. Najvjerojatnije su skupovi zapisa registara eksplicitno zapisani korištenjem metode Write umjesto da se platformi omogući da to učini ispravno. A redoslijed im je zbrkan...
Zar nema zastoja?
Općenito, 5 osoba ne bi trebalo držati u načinu rada datoteke. Možete uzeti besplatni subd, kupiti samo ključ za cluster server i to je to. Ili je preskupo za ured?
Ne sjećam se može li se tehnološki dnevnik snimati u načinu rada datoteke ili ne.....
14.5.2010, 22:53
=========================================================
http://odines.ru/thread1386.html - je li ovo vaša tema?
Odnosno transakcija ne prolazi ni kad jedan korisnik radi?? Onda problem vjerojatno nije u krivom kodu kod snimanja pokreta. Jer ne može biti zaključavanja u jednokorisničkom načinu rada. Snimanje se vrši sekvencijalno.
Tada se čini da problem leži u kršenjima u strukturi same baze podataka.
Bolje je prvo izvršiti Testiranje i ispravak baze podataka s uključenom zastavom "Restrukturiranje tablica infobaze".
Učitavanje u dt pa učitavanje također ima smisla...
chdbfl.exe vjerojatno neće pomoći u ovom slučaju... iako naravno vrijedi pokušati ako sve ostalo ne pomaže.
Bože, upravo sam pogledao datum postova u temi http://odines.ru/thread1386.html A razvoj standardnih u novom kontroliranom načinu nije daleko.
A razlika između 8.2 i 8.1 puno je veća nego između 8.1 i 7.7, posebno za programere, njihovi mozgovi moraju biti potpuno obnovljeni kako bi se razvili za "kontrolirani" način rada
Simptomi i povijest bolesnika:
Rad više korisnika preko mreže s istom datotekom (bazom podataka) uključuje mehanizam mrežnog blokiranja. To tjera sustav da gubi dragocjeno vrijeme na identifikaciju otvorene sjednice evidenciju, te, sukladno tome, rješavanje sukoba.
Glavni znakovi rada blokiranja:
- brz rad korisnika s bazom podataka preko mreže u ekskluzivnom načinu rada i izrazito spor kada više korisnika radi istovremeno
- brzo korisničko iskustvo s lokalnom bazom podataka na poslužitelju i spor rad preko mreže
- odnosi se na sustav datoteka malo ispod 10 MB/s
Dakle, dobio sam zadatak pobrinuti se da čak tri korisnika mogu raditi u 1C u isto vrijeme! Smiješno, zar ne?
Zaboravio sam sve šale kad sam vidio s čime se moram suočiti: "poslužitelj" kojeg predstavlja obični uredsko računalo i dva laptopa.
Sreća bi bila nepotpuna da nije prekrasnog OS- na računalu i na jednom Windows prijenosno računalo 7, s druge strane - Windows 8.
Prilikom pokušaja istovremenog postavljanja dokumenata na prijenosna računala, jedan je zapeo oko minutu, a drugi se srušio iz 1C s tekstom pogreške "nije moguće zaključati stol...".
Pokretanje 1C na prijenosnom računalu zasebna je emisija koja je trajala otprilike 3 minute!
Na mnogim sam resursima naišao na savjete da se prebacim na rad u terminalskom pristupu. Nažalost, Windows 7 to ne dopušta redovnim sredstvima pretvoriti u terminalski poslužitelj - najviše jedna aktivna veza. U tom slučaju, preostale sesije se ne prekidaju; možete se ponovno povezati pod drugim korisnikom - "izbacivanjem" prethodnog korisnika, ali bez prekida njegove sesije. Stoga biste trebali prenijeti 1C na OS poslužitelja, gdje nema takvih ograničenja. Klijent je, na vlastitu odgovornost, riješio problem pomoću uslužnog programa treće strane Windows7_SP1_RDPhack.
Ali avanturama tu nije bio kraj. Čak je iu terminalnoj vezi bilo značajnih kašnjenja. Još jednom su mi pomogle svemoguće tražilice. Ispod su savjeti za ubrzavanje datoteke 1C koje sam slijedio:
1. Onemogući korištenje mrežnog protokola IPv6, konfigurirajte adresiranje na “starom” IPv4.
2. Dodajte 1C procese iznimkama Vatrozid za Windows, kao i u antivirusnim iznimkama, ili ih potpuno onemogućiti (riskantnije, ali jednostavan test je pokazao povećanje brzine ponovni prijenos dokumenata kada je Avast antivirus onemogućen faktor od!)
3. Pokrenite indeksiranje pretraživanja cijelog teksta u 1C ili ga potpuno isključite
4. Pokrenite Testiranje i popravljanje baze podataka, provjeravajući pomoćnim programom ChDbfl
5. Pokrenite stavku Provjeri konfiguraciju u konfiguraciji (ako konfiguracija nije standardna, ovo može biti korisno). Na temelju rezultata provjere konfiguracije, magično se smanjio u veličini za gotovo trećinu. Nisam baš ulazio u to što su novi programeri prije mene ažurirali, ali činjenica je očita.
6. Onemogućite nepotrebne funkcionalne opcije.
7. Postavite korisnička prava. (Ovaj i prethodni savjet činili su mi se glupi dok nisam pogledao crtež upravljani oblici prilikom otvaranja popisa dokumenata. Što je manje nepotrebnih stvari u upravljanom sučelju, to u pravilu brže radi)
8. Počnite ponovno izračunavati ukupne iznose i obnavljati niz (značajno povećanje može se dogoditi samo ako dugo vremena rezultati nisu vraćeni)
9. Navedite "Brzina veze - niska" u postavkama popisa baze podataka (ovo nije dalo puno rezultata, osim što su slike podsustava bile isključene :))
Nakon dovršetka svih ovih koraka, baza podataka datoteka 1C počela je raditi mnogo brže. Počeo se pokretati za najviše 10 sekundi, a brzina prijenosa dokumenata porasla je u prosjeku 12 puta.
Možda će vam ovaj kratki članak biti koristan ako iznenada trebate ubrzati svoju bazu podataka datoteka 1C.
P.S: I pokrenite datoteku 1C pomoću pristup mreži u zajedničku mapu - još uvijek nerealno, jer Daša je najbrža SSD disk, radna memorija i procesor će zapeti u mrežnim blokadama, te će rad više od jednog korisnika biti praktički nemoguć. Govorimo konkretno o konfiguraciji UT 11.1. Samostalno napisano male konfiguracije Mogu raditi prilično brzo čak iu verziji datoteke.
Dodaci iz komentara za objavu:
Defragmentator diska s bazom datoteka
Konvolucija baza podataka (može biti korisno ako je baza podataka velika, npr. za nekoliko godina). Klijentova baza podataka bila je prilično mlada, pa je smanjenje bilo nepraktično.
Nadogradnja hardvera - brži tvrdi disk, novi prekidač, procesor itd.
Instalirajte na web poslužitelju, pristup pomoću tanak klijent. Ovdje su mišljenja podijeljena. Neki kažu da je višestruko brži, drugi kažu da nema zabilježenog ubrzanja.
U višekorisničkim sustavima pravilna organizacija strukture i postavljanje brava igra važnu ulogu. Ako ga nema, korisnici će se često morati nositi s pogreškama uzrokovanim konkurencijom za određene resurse sustava. Ali postoji problem sukoba zaključavanja koji je poznat mnogim korisnicima. Zašto dolazi do sukoba zaključavanja 1C i kako ga riješiti?
Sukob zaključavanja u 1C 8.3 i njegovo značenje
Za većinu korisnika poruka o sukobu zaključavanja 1C znači samo pogrešku koja ih sprječava u obavljanju posla. Žele se riješiti ovog problema što je prije moguće i opsjedaju IT odjel pritužbama da "1C ne radi".
Ali za administratori sustava i programeri, takva poruka ukazuje na moguću prisutnost problema u strukturi konfiguracije. Prije nego što pokušate zadovoljiti korisnike i ukloniti blokade, morate analizirati situaciju i razumjeti razlog poruke o pogrešci.
Razlozi za blokiranje pogrešaka u 1C
Demonstrativno testiranje opterećenja pokazuje da 1C poslužitelj može izdržati paralelni rad više od pet tisuća korisnika. Ali idealni uvjeti za takve eksperimente nedostižni su u svakodnevnim uvjetima velikih i srednjih poduzeća. Za postizanje sličnih performansi i rada bez grešaka, konfiguracija mora biti idealno dizajnirana i prilagođena specifičnim poslovnim procesima poduzeća.
Ako ne uzmemo idealne opcije, tada dolazi do sukoba zaključavanja 1C iz sljedećih razloga:
Istovremeni rad korisnika s velikom količinom podataka. Ovaj temeljni uzrok diktiraju unutarnji mehanizmi 1C. One uključuju zabranu promjena podataka uključenih u transakciju pokrenutu u ime drugog korisnika;
Greške i propusti u konfiguraciji. Struktura standardnih rješenja tvrtke 1C uzima u obzir preporuke za maksimiziranje produktivnosti. Ali programeri trećih strana ne pridržavaju se uvijek visokih standarda, au njihovom se kodu često mogu pronaći sljedeći nedostaci:
- Neoptimalni upiti;
- Zahtjev za stanja na početku akcija;
- Nerazumijevanje namjene konfiguracijskih objekata i njihova nepravilna uporaba;
- Redundancija blokada ugrađenih u sustav ili dodatno razvijenih.
Kako popraviti sukob zaključavanja u 1C 8.3
Poruka sustava "sukob zaključavanja prilikom izvršavanja transakcije 1C 8.3" ne karakterizira konfiguraciju kao pogrešno dizajniranu. Ali ako se takvi signali ignoriraju, postoji mogućnost upadanja u velike probleme u najvažnijem trenutku, na primjer, pri podnošenju tromjesečnih ili godišnjih izvješća. U najboljem slučaju, trom sustav i nezadovoljni korisnici. U najgorem slučaju, izlazni podaci su netočni, što može dovesti do kazni od strane regulatornih tijela.
Rješenje problema sukoba zaključavanja u 1C 8.3 može biti prijenos konfiguracije u upravljani (ručni) način upravljanja zaključavanjem. Implementiran u verziji 8.1, mehanizam u rukama kompetentnih stručnjaka rješava problem sukoba zaključavanja tijekom transakcije u 1C.
Ali vrijedi imati na umu da će ova radnja smanjiti razinu zaštite podataka od promjena dok ih čitaju drugi korisnici. Stoga, ako niste spremni samostalno kontrolirati sve brave u sustavu, nemojte žuriti s promjenom konfiguracijskih postavki.
Brzo rješenje za sukob zaključavanja 1C
U radu administratora ili programera može doći do situacije kada nema vremena za provjeru pogreške i traženje uzroka problema. Na primjer, potrebno je podnijeti izvješće ili dostaviti podatke do određenog vremena, ali pogreške blokiranja 1C to sprječavaju.
Postoje dva načina za brzo rješavanje problema:
- Pronađite i završite sesiju koja blokira potrebne podatke. U malim tvrtkama gdje broj korisnika 1C ne prelazi nekoliko desetaka ljudi, ovo najbolja opcija rješenja;
- Ako kontrolirate sustav sa stotinama zaposlenika, pronalaženje prave sesije bez specijaliziranih softver može potrajati dugo. U ovom slučaju bit će puno učinkovitije ponovno pokrenuti poslužitelj.
Ove odluke su radikalne i usmjerene samo na brza odluka problema i objavljivanje podataka za hitno podnošenje izvješća. Može se iskorijeniti samo razumijevanjem razloga zašto je došlo do sukoba zaključavanja prilikom izvršavanja 1C transakcije. Nakon takvih radnji potrebno je pronaći ranjivosti u sustavu, optimizirati konfiguraciju ili rad zaposlenika. Ne preporučuje se kontinuirano korištenje takvih mjera u slučaju redovitih sukoba zaključavanja transakcija.
Nije neuobičajeno kada radite u 1C da dobijete pogrešku "Sukob zaključavanja prilikom izvršavanja transakcija: prekoračeno je maksimalno vrijeme čekanja za dodjelu zaključavanja." Njegova bit leži u činjenici da nekoliko sesija pokušava istovremeno izvršiti slične akcije, utječući na isti resurs. Danas ćemo otkriti kako popraviti ovu grešku.
Urađen veliki broj operacija
Prvi korak u traženju razloga je razjasniti koliko ima istodobnih korisnika u informacijskoj bazi u kojoj se takva greška generira. Kao što znamo, njihov najveći broj može biti prilično velik. Ovo je i tisuću i pet tisuća.
Mehanizam zaključavanja i transakcija opisan je u vodiču za programere. Koriste se kada više sesija istovremeno pristupa istim podacima. Logično je da se isti podaci ne mogu mijenjati od strane različitih korisnika u istom trenutku.
Također biste trebali provjeriti pokreće li neki od korisnika obradu masovnih promjena podataka. To može biti kao kraj mjeseca i slično. U tom slučaju, nakon završetka obrade, greška će nestati sama od sebe.
Planirani zadaci
Nije neuobičajeno da uzrok greške leži u sustavu koji obrađuje velike količine podataka. Preporuča se takve stvari raditi noću. Odredite raspored za obavljanje takvih rutinskih zadataka izvan radnog vremena.
Tako će oba korisnika raditi u stabilnom sustavu i oni sami rutinski posloviće se uspješno završiti, jer će se smanjiti vjerojatnost sukoba s korisničkim sesijama.
"Zaustavljene sesije"
Problem "zaglavljenih sesija" korisnika poznat je gotovo svima koji su se susreli s uslugom 1C. Korisnik je mogao davno izaći iz programa ili zatvoriti dokument, ali njegova sesija i dalje ostaje u sustavu. Problem je najčešće izoliran i dovoljno je prekinuti takvu sesiju preko administratorske konzole. Isti problemi mogu nastati s pozadinskim poslovima.
Prema brojnim komentarima na internetu, ovakve situacije su češće kod korištenja mrežnih sigurnosnih ključeva. Ako se situacija sa "zamrzavanjem sesija" sustavno ponavlja, to je razlog za temeljitu provjeru i održavanje sustava i poslužitelja (ako je baza podataka klijent-poslužitelj).
Greške prilikom pisanja konfiguracije
Sve standardne konfiguracije razvijaju kvalificirani stručnjaci i stručnjaci. Svaki sustav je temeljito ispitan i optimiziran za brži i ispravniji rad.
U tom smislu, uzrok pogreške može ležati u neoptimalnom kodu koji je napisao programer treće strane. Ovo bi mogao biti "težak" zahtjev koji će blokirati podatke na dulje vrijeme. Također su česti slučajevi konstruiranja algoritama s niskim performansama i kršenjem logike.
Postoji velika vjerojatnost da je sukob zaključavanja nastao upravo zbog pogrešaka programera ako je nastao nakon ažuriranja programa. Da biste provjerili, možete jednostavno "vratiti" poboljšanja ili refaktorirati kod.
Koliko često vidite ovu poruku? Mislim da su se svi koji imaju dugogodišnje iskustvo s 1C barem jednom susreli s takvom pogreškom. Zašto program proizvodi takvu grešku? "Sukob zaključavanja tijekom transakcije: Zaključavanje tablice nije uspjelo"?
Pa, najčešće se to događa zbog činjenice da jedan od korisnika već provodi neku vrstu operacije koja je blokirala ovaj stol. Da biste riješili ovaj problem, svi korisnici samo trebaju izaći iz programa. Ali također se događa da korisnik izađe iz programa, ali se programski proces ne istovaruje iz memorije. Ne paničarite! Ako su svi korisnici napustili program, ali se poruka i dalje pojavljuje, morate otvoriti izbornik Alati -> Aktivni korisnici.
I vidi tko je još unutra ovaj trenutak radi s programom. Ako su se svi korisnici odjavili, a vi i dalje vidite da postoji još netko osim vas, ne brinite. Događa se. Proces je zapeo. Ponovno pokrenite računalo korisnika koje je u aktivnom načinu rada.
Ali ponekad ni to ne rješava problem. Dešava se da dok se transakcija izvršava lampica treperi ili npr HDD na posljednjim nogama. I što je također vjerojatno, netko je izvadio kabel mrežnog čvorišta i umjesto njega uključio kuhalo za vodu, a vi ste u tom trenutku obračunavali amortizaciju. Stoga se u takvim trenucima baza podataka može oštetiti ili podaci mogu biti zabilježeni s greškom.
U ovom slučaju i gotovo uvijek, ako gornji recepti nisu pomogli, uslužni program chdbfl.exe pomaže. Nalazi se u mapi sa izvršna datoteka 1C. Put do datoteke bit će otprilike "C:\Program Files\1Cv82\platform_version_number\bin\chdbfl.exe". Imajte na umu da ovaj uslužni program s jedne verzije platforme možda neće raditi za drugu.
Stoga morate otvoriti mapu s brojem trenutne platforme na kojoj radite.
Kako mogu vidjeti broj perona? Jako jednostavno. Idite na izbornik Alati -> O programu. A zatim slika pokazuje gdje treba tražiti broj perona.
Označite potvrdni okvir "popravi otkrivene pogreške". I kliknite gumb za izvršenje. Ovaj uslužni program ispravlja 90% svih grešaka koje se pojave. Toplo preporučujem da prije korištenja ovog uslužnog programa učinite sigurnosna kopija baze podataka, ali ako se greška pojavi samo u trenutku istovara, kopirajte cijelu mapu iz informacijska baza podaci.