აქტიური მომხმარებლების ცხრილის ჩაკეტვა ვერ მოხერხდა. ფაილების მონაცემთა ბაზის შეფერხებები - როგორ ავიცილოთ თავიდან (უახლესი გამოცდილებიდან). შესრულებული ოპერაციების დიდი რაოდენობა

25.08.2020

ღირებულება 8.1 კომპლექტი 5 მომხმარებლისთვის.
ჩვენ ვიყენებთ სტანდარტულ აღრიცხვას.
ისინი ძირითადად მუშაობენ ტერმინალის მეშვეობით, ზოგჯერ მის გარეშე.
მონაცემთა ბაზის ვარიანტი - ფაილი
შეცდომები, რომლებიც შენიშნეს ტერმინალში

რაღაც მსგავსი. მე გამოვძვერი ქსელს, Yandex - ზოგადად, ყველაფერი რატომღაც ბუნდოვანია.
ნაპოვნია ძირითადი რეკომენდაციები:
1) მონაცემთა ბაზის გადმოტვირთვა/ჩატვირთვა - კონფიგურატორიდან ახლის შექმნის გაგებით
2) გაუშვით \Program Files\1cv81\bin\chdbfl.exe - შეამოწმეთ მონაცემთა ბაზის ფიზიკური მთლიანობა
3) შეამოწმეთ და შეასწორეთ საინფორმაციო ბაზა
4) განახლება უახლესი გამოშვებით 8.1

ვინმემ რამე უფრო კონკრეტულად ხომ არ იცით?

13.5.2010, 10:05

ყველაფერი რაც თქვენ გჭირდებათ უკვე შემოგთავაზეს, ჯერ სცადეთ. არის თუ არა რაიმე ფიზიკური შეცდომები მედიაზე?
არამგონია ვინმემ უფრო კონკრეტული იყოს.

13.5.2010, 10:56

ასე რომ... თუ განვიხილავთ 1C-ს გაუთვალისწინებლად, მაგრამ ზოგადად, მაშინ სულელურად ვიღაც ორი ადგილიდან ცდილობს ერთი მაგიდის დაბლოკვას, პირველი ახერხებს, დანარჩენები კი იგზავნება. შეხედეთ რა ოპერაციები/ტრანზაქცია/დამუშავება (ან რასაც ეძახიან 1C-ში) მიმდინარეობს ამ დროს. შესაძლოა, პრობლემა არ არის პლატფორმა, არამედ არასწორად დაწერილი კონფიგურაციები ან როგორ მუშაობს ეს კონფიგურაციები თქვენს მონაცემებზე.

P.S. და ფაილების მონაცემთა ბაზები მრავალ მომხმარებლის რეჟიმში არის გაუკუღმართება.

13.5.2010, 10:58

მიუხედავად იმისა, რომ ვინ ჯანდაბამ იცის, როგორ მზადდება მონაცემთა ბაზა 1C-v-ში, შეიძლება იყოს პრობლემა სადღაც მონაცემთა ბაზაში და ყველა სახის შეკეთება დაგეხმარებათ.

13.5.2010, 11:06

დიახ, მეჩვენება, რომ რვაკუთხედი პლატფორმას ჰგავს - ის ჯერ კიდევ ნესტიანია. სადღაც დაწერეს, რომ ტესტირება და კორექტირება უნდა მოხდეს პერიოდულად

13.5.2010, 11:10

ნაკლებად სავარაუდოა. რვასთვის შეიძინეს ახალი სერვერი ლიცენზირებული Windows-ით

დასკვნა ის არის, რომ ერთი კეტავს მაგიდას, დანარჩენები ელოდებიან ტაიმაუტს.
რატომ არ აქვთ დრო, დიდი კითხვაა. შეხედეთ ფიზიკურ მედიას, ეს შეიძლება სულელური იყოს. Syslog, MHDD. და ყველა ის მოქმედება რაც წერია პირველ პოსტში სავალდებულოა.

P.S. ახალი არ ნიშნავს 100% მუშაობას.

13.5.2010, 11:38

ყველაფერი, რაც გჭირდებათ, უკვე შემოგთავაზეს, ჯერ სცადეთ

დიახ, საღამომდე უნდა დაველოდოთ.
რაღაც ახლის მოსმენის მცირე იმედი იყო

ნუ ყვები სასწაულებს. იქ უამრავი უბედურებაა, მაგრამ ეს არ არის.

სად არის სასწაულები? არ მესმის, ვინმე აპირებს თქვას, რომ 8.1 მაგარი, უნაკლო პლატფორმაა?

წერდა, რომ ტესტირება და კორექტირება უნდა მოხდეს პერიოდულად

როგორც ჩანს, ასეთი შემთხვევა გვაქვს.
მომხმარებელთა ინდივიდუალურად გამოკითხვამ (ისე, რომ ერთად არ იტყუებოდეს) აჩვენა, რომ ეს სიტუაცია, როგორც ჩანს, მხოლოდ ტერმინალში მომუშავე მომხმარებლებს შორის ხდება. და ვინც არ გადის ტერმინალში სად
Windows Server 2003 R2 Standart 64, ან არ გახსოვთ ეს სიტუაცია, ან უბრალოდ არ მოსვლიათ მათ.
უფრო მეტიც, ორმა განსაკუთრებით დაკვირვებულმა აღნიშნა, რომ 1,5-2 თვის წინ ეს ფენომენი გაცილებით ნაკლებად შეინიშნებოდა.

13.5.2010, 12:42

დაბადებული მკვლელისერვერზე რამე ანტივირუსია დაყენებული? თუ კი, სცადეთ მისი გამორთვა ან მონაცემთა ბაზის დამატება გამონაკლისებში

13.5.2010, 13:14

სერვერზე რამე ანტივირუსია დაყენებული?

არადა, უნდა შევხედო. ეს არის მტრის სერვერი
ჭკვიანმა ფრანკებმა აიღო ჩვენი ერთ-ერთი მონაცემთა ბაზა შენარჩუნებისთვის, უზრუნველყო მათი სერვერი და, როგორც ჩანს, ზედამხედველობას უწევს ჩვენს მუშაობას
მათ სერვერზე წვდომა უზრუნველყოფილი იყო, მაგრამ გაშიშვლებული ვერსიით.
გადავხედავ.

ანტივირუსი არ არის როგორც ჩანს...

13.5.2010, 13:23

არ მესმის, ვინმე აპირებს თქვას, რომ 8.1 მაგარი, უნაკლო პლატფორმაა?
ჰო, ჯანდაბა. 7.7 ჯერ კიდევ სისულელეა, მაგრამ დაახლოებით 8 დროა დავწეროთ ლეგენდები მის ხარვეზებზე

რამდენად დიდია მონაცემთა ბაზა და რამდენი მომხმარებელი?

დაამატეთ იგი. მიეცი კონკრეტული მაგალითი.
რამდენად დიდია მონაცემთა ბაზა და რამდენი მომხმარებელი?

ღამით გავიკეთე ტესტი და გავასწორე. აქამდე 1cv8.1CD იყო 2GB, ახლა არის 1.5GB.
არის 5 მომხმარებელი, ასევე თავად ლიცენზია.
რაც შეეხება ლეგენდებს ხარვეზების შესახებ, იყო ერთი შემთხვევა. ახლა, თუ აიღებთ 7.7-ს და უბრალოდ დააკოპირებთ 1 მონაცემთა ბაზას Total-ის მეშვეობით სხვა ადგილას - ასლი უპრობლემოდ.
ერთხელ მე ვცადე იგივე გამეკეთებინა რვაჯერადი მონაცემთა ბაზის საშუალებით, დავაკოპირე მონაცემთა ბაზის დირექტორია სხვა ადგილას,
დარეგისტრირდა, ერთდროულად გახსნა ორივე მონაცემთა ბაზა, ერთი გამიზნული იყო პერვერსიებისთვის.
ასლში მოვნიშნე რამდენიმე დოკუმენტი წასაშლელად, გადავედი ფანჯარაში რეალური მონაცემთა ბაზაში და თვალებს არ დავუჯერე: იგივე დოკუმენტები იქაც იყო მონიშნული წასაშლელად.

Ash stump, 1C აქვს პასუხი ყველაფერზე: გააკეთეთ მონაცემთა ბაზის ყოველდღიური ასლი.
დიახ, მაგრამ ეს ცუდი პასუხია

MMMarina

დაბადებული მკვლელი,

Გამარჯობა მეგობარო...

მითი!
ასე იბადება ლეგენდები...

Გამარჯობა მეგობარო...

Გამარჯობა მეგობარო. ასე რომ თქვენ გაიტაცეს

შემდეგ კი დესკტოპის ხატები გაჩუმდა

მითი!
ასე იბადება ლეგენდები...

Დავინახე. სასაცილო არ იყო ჩემთვის გამოქვეყნებული და გამოუქვეყნებელი დოკუმენტების გარჩევა წაშლის ნიშნის მოხსნის შემდეგ, ისინი ყველა გამოუქვეყნებელი ხდება.

არ მახსოვს რა პლატფორმა იყო მაშინ.

შეეცადეთ იგივე გააკეთოთ. იქნებ შენც მოახერხო

ასე იბადება ლეგენდები...

მეტსაც ვიტყვი: როცა ხელით მოვხსნი რამდენიმე დოკუმენტს წასაშლელად,
იგივე მოხდა რეალურ მონაცემთა ბაზაში. მაშინ არ მქონდა დრო, რომ როგორმე დამეფიქსირებინა ეს სენსაცია.
ასე რომ, მე უბრალოდ დავაბრუნე ყველაფერი ისე, როგორც იყო და აღარ გავიმეორე.

კომპიუტერის ცოდნაში არსებული ხვრელების აღმოფხვრა...
მართლა უიმედო მგონია...

ეს კონკრეტული თემა საერთოდ არ არის თქვენთვის, ძვირფასო (c)
ზოგადად, ყველაფერი გასაგებია
შექმენი კომპიუტერის მეგობარი, როგორც ვარიანტი)))

მე არასოდეს დამიკოპირებია ფაილის მონაცემთა ბაზა მე-8-ით
ეს სულაც არ იყო სენსაცია.

შეიძლება არ გჯეროდეს, მაგრამ ეს მოხდა.

ფაქტია, რომ 8-თან ძალიან მჭიდროდ ვმუშაობდი რამდენიმე წლის განმავლობაში. როგორც კი არ გადაიწერა. ასე რომ არ მჯერა
მაგრამ შემიძლია ვივარაუდო, რომ როცა ადამიანი ზედმეტად გადაღლილია, ბევრი რამ არის შესაძლებელი. მე თვითონ ვიცი.

არ ინერვიულოთ, ფაილების მონაცემთა ბაზის ადვილად კოპირება და ამაღლება შესაძლებელია სხვა გზით. არანაირი ხარვეზი არ უნდა იყოს.

14.5.2010, 10:52

14.5.2010, 11:28

ვარაუდი მაქვს: გაჩერებისას ერთი და იგივე მონაცემთა ბაზა ორჯერ დავრეგისტრირდი.

8 შეთავაზება ჩანაცვლება

14.5.2010, 11:31

არა... 7.7, როცა ამის გაკეთებას ვცდილობ, სულელურად დუმს და არ ამატებს მონაცემთა ბაზას სიაში (უბრალოდ საერთოდ არ რეაგირებს)
8 შეთავაზება ჩანაცვლება

შეიძლება უბრალოდ მაუსით გამომრჩა და იგივე გავუშვი... სასწაულები არ ხდება

14.5.2010, 11:47

შეიძლება უბრალოდ მაუსის ნიშანი გამომრჩა და იგივე გავუშვი...

ვეცდები მსგავსი მოდელის გაკეთება სახლში. მოგვიანებით დავწერ.
ჩვეულებრივ, რაიმე სახიფათო ქმედების წინ, 1C-ში (7.7. ან 8) ვაწკაპუნებ კითხვის ნიშანზე (აქ ნაჩვენებია მონაცემთა ბაზის გზა).

მერე ხალხი ისე ერთხმად იცინოდა ჩემს ლეგენდაზე, რომ ეჭვი მეპარებოდა.
მიუხედავად იმისა, რომ რვაში უფრო მეტი ხარვეზია, ვიდრე შვიდში.

ოჰ, რა სულელური შეცდომაა, მე არ ვიყავი ერთადერთი ვინც ეს დავინახე.
ზოგადად, ისინი დამცინოდნენ ერთ მე-8 ბაზაზე კლიენტთან, როდესაც მე ჯერ კიდევ ფრენჩაიზში ვმუშაობდი.
ერთ დღეს ერთი ადამიანი, მეორე - მეორე, მესამეზე წავედი. მე მათ ვკითხე - მათ გააკეთეს სარეზერვო ასლი ექსპლოიტებამდე? საპასუხოდ - ცხენებივით ღრიალებენ, მოკლედ გაიტანეს, მხოლოდ იმ მანქანაზე აიღეს ბაზა

14.5.2010, 12:35

- ცხენებივით ღრიალებენ, უფრო მოკლედ გაიტანა, მხოლოდ ბაზა აიღეს ადგილობრივად,
და მე მქონდა შესაძლებლობა გამეგდო იგი ქსელიდან. წინა ტავარიშის მაგალითზე გადავწყვიტე არ გამეკეთებინა სარეზერვო ასლი,
ის ახალგაზრდა და სულელი იყო - ბევრი ჩვენება იყო.
ზოგადად conf-ში შევიტანე ცვლილებები, conf-ს ვინახავ, conf-ის შენახვისას მოხდა რაღაც ავარია და მონაცემთა ბაზა დაეცა, საღამოს. შოკი. დილით 3 სპეციალისტი წავედით, მათ შორის მეც.
უბედური შემთხვევა ის იყო, რომ გამოშვების ნომერი ამოიღეს მონაცემთა ბაზიდან, ე.ი. კონფიგურაციაში, როდესაც თქვენ დააწკაპუნეთ კითხვაზე, ის ცარიელი იყო და თავად conf-ის სახელი აკლია. და მონაცემთა ბაზაში შესვლისას არაფერი ჩანდა, ინტერფეისის ჩათვლით. გაფრინდა, შეუძლებელი იყო დოკუმენტების ჟურნალებში შესვლა.
ჩვენ პრობლემა მოვაგვარეთ მოკლული მონაცემთა ბაზის განახლებით შედარებით ახალი კონფიგურაციის ფაილით, ყველაფერი დამუშავდა.
ყველაფერი ხელახლა დაიბადა.
ეს არის ნამდვილი ლეგენდის მაგალითი. 3 ადამიანმა არ უნდა შეაფერხოს ერთდროულად

14.5.2010, 13:53

conf-ის შენახვისას მოხდა რაღაც ავარია და მონაცემთა ბაზა დაეცა

ისე, თუ ეს იყო ტექნიკის გაუმართაობა, მაშინ გასაკვირი არაფერია.
მაგრამ თუ იპოვეთ შეცდომა, რომელიც მუდმივად ჩნდება გარკვეული მოქმედებების შესრულების შემდეგ, მაშინ ეს სხვა ამბავია.

14.5.2010, 14:39

ისე, თუ ეს იყო ტექნიკის გაუმართაობა, მაშინ გასაკვირი არაფერია

არა, რა მოხდა. რკინა, ბადე ან პლატფორმა ახლა არც ისე მნიშვნელოვანია.
მეჩვენება, რომ პროგრამული უზრუნველყოფა არ უნდა მოიქცეს ასე მომხიბვლელად
ეს იგივეა, რაც Vista-ს გამოშვება და იმის აღიარება, რომ სისულელეა. რატომღაც ისინი სწრაფად გადახტეს 8.0-დან 8.1-მდე
P.S. მე მესმის სიტყვა bug-ის მნიშვნელობა, მადლობა შეშფოთებისთვის)))

14.5.2010, 19:37

ვთქვათ, თუ Vista-ზე სერვის-პაკეტების ან რაიმე მნიშვნელოვანი გადაადგილებისას მსგავსი „შეფერხება“ მოხდა, მაშინ სავარაუდოა, რომ სისტემა, თუნდაც ჩატვირთვის შემთხვევაში, უკიდურესად არასტაბილურად იმუშაოს.
ან, ვთქვათ, ინსულინის მიღების მომენტში მიწისძვრა ხდება, მერე შეიძლება დიაბეტი მოკვდეს, იმიტომ. რხევისას შპრიცი დივნის ქვეშ შემოვიდა.

14.5.2010, 22:32

Born Killer, არის თუ არა სერვერზე დაყენებული რაიმე ანტივირუსი? თუ კი, სცადეთ მისი გამორთვა ან მონაცემთა ბაზის დამატება გამონაკლისებში

როგორ შეიძლება ანტივირუსმა იმოქმედოს მაგიდის ჩაკეტვაზე? მონაცემთა ბაზა 8.x არის ერთი ფაილი.

ასლში მოვნიშნე რამდენიმე დოკუმენტი წასაშლელად, გადავედი ფანჯარაში რეალური მონაცემთა ბაზაში და თვალებს არ დავუჯერე: იგივე დოკუმენტები იყო მონიშნული წასაშლელად და იქ shok.gif
ზოგადად, მე არ მომეწონა ეს გაფუჭებული ტოპები, მას შემდეგ მონაცემთა ბაზის ასლი მხოლოდ Upload/Load-ის საშუალებით გავაკეთე.
როგორ მოგწონთ ეს სევდიანი ლეგენდა, ბატონო?
რა მოხდება, თუ გავიტაცე და ასლში უფრო სერიოზული რამ გავაკეთო (მაგალითად, წაშლილი დოკუმენტები, რომლებიც მონიშნულია წასაშლელად), და რაღაც გაუგებარი სახით, იგივე ქმედებები განხორციელდეს მთავარ მონაცემთა ბაზაში?

არა, ასე არ შეიძლება, სასწაულები არ ხდება. თქვენ ალბათ შეხვედით იმავე მონაცემთა ბაზაში... 8-ში შეგიძლიათ 2-ჯერ შეხვიდეთ მონაცემთა ბაზაში იმავე სახელით უპრობლემოდ.

დროდადრო ჩნდებოდა პრობლემები დოკუმენტების წარმართვის/ჩაწერისას ფორმის შეცდომით
"ჩაკეტვის კონფლიქტი ტრანზაქციის დროს: ცხრილის "_DOCUMENT158" ჩაკეტვა ვერ მოხერხდა

ასე რომ, პირველი, რაც უნდა გააკეთოთ, არის იმის განსაზღვრა, რომელ მეტამონაცემთა დოკუმენტს შეესაბამება „_DOCUMENT158“ ცხრილი. ამ მიზნით არსებობს გლობალური კონტექსტის მეთოდი "GetDatabaseStorageStructure". ამ გზით თქვენ მაინც გაიგებთ ზუსტად რომელი დოკუმენტია "ბუგი".

მაშინ უნდა გესმოდეთ ვინმემ შეცვალა თუ არა მასში გამტარობის მოდული და დაარტყა თავზე, თუ ერთ ადგილას შეცვალა. დიდი ალბათობით, რეგისტრის ჩანაწერების ნაკრები ცალსახად იწერება Write მეთოდის გამოყენებით, იმის ნაცვლად, რომ პლატფორმას ეს სწორად გააკეთოს. და მათი თანმიმდევრობა დაბნეულია...
ჩიხები არ არის?

ზოგადად, 5 ადამიანი არ უნდა ინახებოდეს ფაილის რეჟიმში. შეგიძლიათ აიღოთ უფასო subd, იყიდოთ მხოლოდ გასაღები კლასტერული სერვერისთვის და ეს არის ის. ან ძალიან ძვირია ოფისისთვის?
არ მახსოვს ტექნოლოგიური ჟურნალის გადაღება ფაილის რეჟიმში შეიძლება თუ არა.....

14.5.2010, 22:53

=========================================================
http://odines.ru/thread1386.html - ეს თქვენი თემაა?

ანუ ტრანზაქცია არ გადის მაშინაც კი, როცა ერთი მომხმარებელი მუშაობს?? მაშინ პრობლემა ალბათ მოძრაობების ჩაწერის დროს კრუნჩხულ კოდში არ არის. იმის გამო, რომ არ შეიძლება იყოს საკეტები ერთ მომხმარებლის რეჟიმში. ჩაწერა ხდება თანმიმდევრობით.

შემდეგ, როგორც ჩანს, პრობლემა თავად მონაცემთა ბაზის სტრუქტურაში არსებულ დარღვევებშია.
სჯობს, ჯერ ჩავატაროთ მონაცემთა ბაზის ტესტირება და კორექტირება „ინფორმაციული ბაზის ცხრილების რესტრუქტურიზაციის“ დროშით.
dt-ზე ატვირთვა და მერე ჩატვირთვაც აზრი აქვს...
chdbfl.exe ნაკლებად სავარაუდოა, რომ დაგეხმაროთ ამ შემთხვევაში ... თუმცა, რა თქმა უნდა, ღირს სცადოთ, თუ ყველაფერი არ დაეხმარება.

Gee - ახლახან გადავხედე პოსტების თარიღს თემაში http://odines.ru/thread1386.html და სტანდარტულების განვითარება ახალ კონტროლირებად რეჟიმში არ არის შორს.
და სხვაობა 8.2-სა და 8.1-ს შორის გაცილებით მეტია, ვიდრე 8.1-სა და 7.7-ს შორის, განსაკუთრებით დეველოპერებისთვის, მათი ტვინი მთლიანად უნდა იყოს გადაკეთებული, რათა განვითარდეს "კონტროლირებული" მუშაობის რეჟიმისთვის.

მრავალ მომხმარებლის სისტემებში, სტრუქტურის სწორი ორგანიზება და საკეტების დაყენება მნიშვნელოვან როლს ასრულებს. თუ ის იქ არ არის, მომხმარებლებს ხშირად მოუწევთ გაუმკლავდეთ შეცდომებს, რომლებიც გამოწვეულია გარკვეული სისტემის რესურსების კონკურენციით. მაგრამ არსებობს დაბლოკვის კონფლიქტის პრობლემა, რომელიც ნაცნობია ბევრი მომხმარებლისთვის. რატომ ხდება 1C დაბლოკვის კონფლიქტი და როგორ მოვაგვაროთ იგი?

ჩაკეტვის კონფლიქტი 1C 8.3-ში და მისი მნიშვნელობა

მომხმარებლების უმეტესობისთვის შეტყობინება 1C დაბლოკვის კონფლიქტის შესახებ ნიშნავს მხოლოდ შეცდომას, რომელიც ხელს უშლის მათ სამუშაოს შესრულებაში. მათ სურთ რაც შეიძლება სწრაფად მოიცილონ ეს პრობლემა და ალყა შემოარტყონ IT განყოფილებას საჩივრებით, რომ „1C არ მუშაობს“.

მაგრამ სისტემის ადმინისტრატორებისა და დეველოპერებისთვის, ასეთი შეტყობინება მიუთითებს, რომ შეიძლება იყოს პრობლემები კონფიგურაციის სტრუქტურაში. სანამ ცდილობთ მომხმარებლების სიამოვნებას და ბლოკირების მოხსნას, უნდა გაანალიზოთ სიტუაცია და გაიგოთ შეცდომის შეტყობინების მიზეზი.

1C-ში შეცდომების დაბლოკვის მიზეზები

დემონსტრაციული დატვირთვის ტესტირება აჩვენებს, რომ 1C სერვერს შეუძლია გაუძლოს ხუთ ათასზე მეტი მომხმარებლის პარალელურ მუშაობას. მაგრამ ასეთი ექსპერიმენტებისთვის იდეალური პირობები მიუწვდომელია მსხვილი და საშუალო ზომის კომპანიების ყოველდღიურ პირობებში. მსგავსი ეფექტურობისა და შეცდომების გარეშე მუშაობის მისაღწევად, კონფიგურაცია იდეალურად უნდა იყოს შემუშავებული და მორგებული საწარმოს კონკრეტულ ბიზნეს პროცესებზე.

თუ არ მივიღებთ იდეალურ ვარიანტებს, მაშინ 1C ჩაკეტვის კონფლიქტები წარმოიქმნება შემდეგი მიზეზების გამო:

მომხმარებელთა ერთდროული მუშაობა მონაცემთა დიდი რაოდენობით.ეს ძირეული მიზეზი ნაკარნახევია 1C-ის შიდა მექანიზმებით. ისინი გულისხმობს სხვა მომხმარებლის სახელით გაშვებულ ტრანზაქციაში ჩართული მონაცემების ცვლილების აკრძალვას;

შეცდომები და ხარვეზები კონფიგურაციაში. 1C კომპანიის სტანდარტული გადაწყვეტილებების სტრუქტურა ითვალისწინებს პროდუქტიულობის გაზრდის რეკომენდაციებს. მაგრამ მესამე მხარის დეველოპერები ყოველთვის არ იცავენ მაღალ სტანდარტებს და მათ კოდში ხშირად გვხვდება შემდეგი ხარვეზები:

არაოპტიმალური მოთხოვნები;
ნაშთების მოთხოვნა მოქმედებების დასაწყისში;
კონფიგურაციის ობიექტების დანიშნულების გაუგებრობა და მათი არასწორი გამოყენება;
სისტემაში ჩაშენებული ან დამატებით განვითარებული ბლოკირების სიჭარბე.

როგორ მოვაგვაროთ საკეტის კონფლიქტი 1C 8.3-ში

სისტემის შეტყობინება "ჩაკეტვის კონფლიქტი 1C 8.3 ტრანზაქციის შესრულებისას" არ ახასიათებს კონფიგურაციას, როგორც არასწორად შემუშავებულს. მაგრამ თუ ასეთი სიგნალები იგნორირებულია, მაშინ არსებობს შესაძლებლობა, მოხვდეთ დიდ პრობლემებში ყველაზე გადამწყვეტ მომენტში, მაგალითად, კვარტალური ან წლიური ანგარიშების წარდგენისას. საუკეთესო შემთხვევაში, დუნე სისტემა და უკმაყოფილო მომხმარებლები. უარეს შემთხვევაში, გამომავალი მონაცემები არასწორია, რამაც შეიძლება გამოიწვიოს ჯარიმები მარეგულირებელი ორგანოების მხრიდან.

1C 8.3-ში დაბლოკვის კონფლიქტის პრობლემის გადაწყვეტა შეიძლება იყოს კონფიგურაციის გადატანა მართულ (ხელით) დაბლოკვის მართვის რეჟიმში. 8.1 ვერსიაში დანერგილი მექანიზმი კომპეტენტური სპეციალისტების ხელში წყვეტს საკეტის კონფლიქტების პრობლემას 1C-ში გარიგების დროს.

მაგრამ გასათვალისწინებელია, რომ ეს ქმედება შეამცირებს მონაცემების დაცვის დონეს ცვლილებებისგან სხვა მომხმარებლების მიერ წაკითხვისას. ამიტომ, თუ არ ხართ მზად დამოუკიდებლად გააკონტროლოთ სისტემის ყველა საკეტი, ნუ ჩქარობთ კონფიგურაციის პარამეტრების შეცვლას.

1C ჩაკეტვის კონფლიქტის სწრაფი გადაწყვეტა

ადმინისტრატორის ან დეველოპერის მუშაობაში შეიძლება შეიქმნას სიტუაცია, როდესაც არ არის დრო შეცდომის შესამოწმებლად და პრობლემის ძირეული მიზეზების მოსაძებნად. მაგალითად, აუცილებელია მოხსენების წარდგენა ან მონაცემების გაგზავნა გარკვეული დროით, მაგრამ 1C დაბლოკვის შეცდომები ხელს უშლის ამას.

პრობლემის სწრაფად გადაჭრის ორი გზა არსებობს:

იპოვეთ და დაასრულეთ სესია, რომელიც ბლოკავს საჭირო მონაცემებს. მცირე კომპანიებში, სადაც 1C მომხმარებელთა რაოდენობა არ აღემატება რამდენიმე ათეულ ადამიანს, ეს არის ოპტიმალური გადაწყვეტა;
თუ თქვენ აკონტროლებთ სისტემას ასობით თანამშრომლით, შესაბამისი სესიის პოვნა სპეციალიზებული პროგრამული უზრუნველყოფის გარეშე შეიძლება დიდი დრო დასჭირდეს. ამ შემთხვევაში გაცილებით ეფექტური იქნება სერვერის გადატვირთვა.

ეს გადაწყვეტილებები რადიკალურია და მიზნად ისახავს მხოლოდ პრობლემის სწრაფად გადაჭრას და მონაცემების გათავისუფლებას სასწრაფო მოხსენებისთვის. მისი აღმოფხვრა შესაძლებელია მხოლოდ იმ მიზეზის გაგებით, თუ რატომ წარმოიშვა ჩაკეტვის კონფლიქტი 1C ტრანზაქციის შესრულებისას. ასეთი ქმედებების შემდეგ აუცილებელია სისტემაში მოწყვლადობის პოვნა, თანამშრომლების კონფიგურაციის ან მუშაობის ოპტიმიზაცია. არ არის რეკომენდებული ასეთი ზომების მუდმივი გამოყენება ტრანზაქციებზე რეგულარული ჩაკეტვის კონფლიქტების შემთხვევაში.

რამდენად ხშირად ხედავთ ამ შეტყობინებას? ვფიქრობ, ყველას, ვისაც აქვს 1C-ის ხანგრძლივი გამოცდილება, ერთხელ მაინც შეექმნა ასეთი შეცდომა. რატომ უშვებს პროგრამა ასეთ შეცდომას? "ჩაკეტვის კონფლიქტი ტრანზაქციის დროს: ცხრილის ჩაკეტვა ვერ მოხერხდა"?

ისე, ყველაზე ხშირად ეს ხდება იმის გამო, რომ ერთ-ერთი მომხმარებელი უკვე ახორციელებს რაიმე სახის ოპერაციას, რომელმაც დაბლოკა ეს ცხრილი. ამ პრობლემის გადასაჭრელად, ყველა მომხმარებელს უბრალოდ სჭირდება პროგრამიდან გასვლა. მაგრამ ასევე ხდება, რომ მომხმარებელი გადის პროგრამიდან, მაგრამ პროგრამის პროცესი არ იტვირთება მეხსიერებიდან. Არ აჰყვეთ პანიკას! თუ ყველა მომხმარებელმა დატოვა პროგრამა, მაგრამ შეტყობინება მაინც გამოჩნდება, თქვენ უნდა გახსნათ მენიუ Tools -> Active users.

და ნახეთ, თქვენს გარდა ვინ მუშაობს ამჟამად პროგრამაზე. თუ ყველა მომხმარებელი გავიდა სისტემიდან და თქვენ მაინც ხედავთ, რომ თქვენს გარდა არის კიდევ ვინმე, არ ინერვიულოთ. Ხდება ხოლმე. პროცესი ჩაკეტილია. გადატვირთეთ მომხმარებლის კომპიუტერი, რომელიც აქტიურ რეჟიმშია.

მაგრამ ზოგჯერ ეს პრობლემასაც არ წყვეტს. ხდება ისე, რომ ტრანზაქციის მომენტში შუქი ანათებს, ან, მაგალითად, მყარი დისკი ბოლო ფეხებზეა. და რაც ასევე სავარაუდოა, ვიღაცამ ქსელის ჰაბს კაბელი ამოიღო და ჩაიდანი თავის ადგილას ჩართო და შენ იმ მომენტში ამორტიზაციას ითვლიდი. ასე რომ, ასეთ მომენტებში მონაცემთა ბაზა შეიძლება დაზიანდეს ან მონაცემები შეიძლება დაფიქსირდეს შეცდომით.

ამ შემთხვევაში და თითქმის ყოველთვის, თუ ზემოხსენებული რეცეპტები არ დაეხმარა, chdbfl.exe პროგრამა ეხმარება. ის მდებარეობს საქაღალდეში 1C შესრულებადი ფაილით. ფაილისკენ მიმავალი გზა იქნება დაახლოებით "C:\Program Files\1Cv82\platform_version_number\bin\chdbfl.exe". გთხოვთ გაითვალისწინოთ, რომ ეს პროგრამა პლატფორმის ერთი ვერსიიდან შეიძლება არ იმუშაოს მეორეზე.

ამიტომ, თქვენ უნდა გახსნათ საქაღალდე მიმდინარე პლატფორმის ნომრით, რომელზეც მუშაობთ.

როგორ ვნახო პლატფორმის ნომერი? Ძალიან მარტივი. გადადით მენიუში ინსტრუმენტები -> პროგრამის შესახებ. და შემდეგ სურათზე ჩანს, სად უნდა ვეძებოთ პლატფორმის ნომერი.

შეამოწმეთ ყუთი "გამოვლენილი შეცდომების გამოსწორება". და დააჭირეთ შესრულების ღილაკს. ეს პროგრამა ასწორებს ყველა შეცდომის 90%-ს. მე დაჟინებით გირჩევთ, რომ ამ პროგრამის გამოყენებამდე გააკეთოთ მონაცემთა ბაზის სარეზერვო ასლი, მაგრამ თუ შეცდომა მოხდა მხოლოდ გადმოტვირთვის დროს, მაშინ დააკოპირეთ მთელი საქაღალდე საინფორმაციო მონაცემთა ბაზაში.

1C-ში მუშაობისას იშვიათი არ არის შეცდომის მიღება „ჩაკეტვის კონფლიქტი ტრანზაქციის შესრულებისას: დაბლოკვის მინიჭების მაქსიმალური ლოდინის დრო გადაჭარბებულია“. მისი არსი მდგომარეობს იმაში, რომ რამდენიმე სესია ცდილობს ერთდროულად განახორციელოს მსგავსი ქმედებები, რაც გავლენას ახდენს იმავე რესურსზე. დღეს ჩვენ გავარკვევთ, თუ როგორ უნდა გამოვასწოროთ ეს შეცდომა.

შესრულებული ოპერაციების დიდი რაოდენობა

პირველი ნაბიჯი მიზეზების ძიებისას არის იმის გარკვევა, თუ რამდენი კონკურენტი მომხმარებელია იმ საინფორმაციო ბაზაში, რომელშიც წარმოიქმნება ასეთი შეცდომა. როგორც ვიცით, მათი მაქსიმალური რაოდენობა შეიძლება იყოს საკმაოდ დიდი. ეს არის ათასიც და ხუთი ათასიც.

ჩაკეტვისა და ტრანზაქციების მექანიზმი აღწერილია დეველოპერის სახელმძღვანელოში. ისინი გამოიყენება, როდესაც რამდენიმე სესიას ერთსა და იმავე მონაცემებზე წვდომა აქვს ერთდროულად. ლოგიკურია, რომ ერთი და იგივე მონაცემების შეცვლა შეუძლებელია სხვადასხვა მომხმარებლის მიერ ერთდროულად.

თქვენ ასევე უნდა შეამოწმოთ, აწარმოებს თუ არა რომელიმე მომხმარებელი მონაცემთა მასობრივი ცვლილების დამუშავებას. ეს შეიძლება იყოს, თვის ბოლოს და მსგავსი. ამ შემთხვევაში, დამუშავების დასრულების შემდეგ, შეცდომა თავისით გაქრება.

დაგეგმილი დავალებები

იშვიათი არ არის, რომ შეცდომის მიზეზი დევს სისტემაში, რომელიც ამუშავებს დიდი რაოდენობით მონაცემებს. ასეთი საქმის გაკეთება რეკომენდებულია ღამით. ჩამოაყალიბეთ გრაფიკი სამუშაო საათების მიღმა ასეთი რუტინული დავალებების შესასრულებლად.

ამ გზით მომხმარებლები იმუშავებენ სტაბილურ სისტემაში და თავად რუტინული ამოცანები წარმატებით დასრულდება, ვინაიდან შემცირდება მომხმარებლის სესიებთან კონფლიქტის ალბათობა.

"ჩამოკიდებული სესიები"

მომხმარებლების „გაჭედილი სესიების“ პრობლემა თითქმის ყველასთვის ნაცნობია, ვინც 1C სერვისს წააწყდა. მომხმარებელს შეეძლო დიდი ხნის წინ დაეტოვებინა პროგრამა, ან დაეხურა დოკუმენტი, მაგრამ მისი სესია კვლავ რჩება სისტემაში. პრობლემა ყველაზე ხშირად იზოლირებულია და საკმარისია ასეთი სესიის დასრულება ადმინისტრატორის კონსოლის მეშვეობით. იგივე პრობლემები შეიძლება წარმოიშვას ფონურ სამუშაოებთან დაკავშირებით.

ინტერნეტში მრავალი კომენტარის თანახმად, ასეთი სიტუაციები უფრო ხშირია ქსელის უსაფრთხოების გასაღებების გამოყენებისას. თუ „სესიების გაყინვის“ სიტუაცია სისტემატურად მეორდება, ეს არის სისტემის და სერვერების საფუძვლიანად შემოწმებისა და შენარჩუნების მიზეზი (თუ მონაცემთა ბაზა არის კლიენტ-სერვერი).

შეცდომები კონფიგურაციის დაწერისას

ყველა სტანდარტული კონფიგურაცია შემუშავებულია კვალიფიციური სპეციალისტებისა და ექსპერტების მიერ. თითოეული სისტემა საფუძვლიანად არის გამოცდილი და ოპტიმიზირებული უფრო სწრაფი და სწორი მუშაობისთვის.

ამასთან დაკავშირებით, შეცდომის მიზეზი შეიძლება იყოს მესამე მხარის დეველოპერის მიერ დაწერილი არაოპტიმალური კოდი. ეს შეიძლება იყოს "მძიმე" მოთხოვნა, რომელიც დაბლოკავს მონაცემებს დიდი ხნის განმავლობაში. ასევე ხშირია დაბალი წარმადობით და ლოგიკის დარღვევით ალგორითმების აგების შემთხვევები.

დიდია ალბათობა იმისა, რომ ჩაკეტვის კონფლიქტი წარმოიშვა სწორედ დეველოპერის შეცდომების გამო, თუ ის წარმოიშვა პროგრამის განახლების შემდეგ. შესამოწმებლად, შეგიძლიათ უბრალოდ „გააბრუნოთ“ გაუმჯობესებები, ან შეცვალოთ კოდი.

პაციენტის სიმპტომები და ისტორია:

რამდენიმე მომხმარებლის მუშაობა ქსელში ერთი და იგივე ფაილით (მონაცემთა ბაზა) მოიცავს ქსელის დაბლოკვის მექანიზმს. ეს აიძულებს სისტემას დახარჯოს ძვირფასი დრო ღია ჩაწერის სესიების იდენტიფიცირებისთვის და კონფლიქტების შესაბამისად გადაჭრისთვის.

ბლოკირების ოპერაციის ძირითადი ნიშნები:

სწრაფი მომხმარებლის მუშაობა მონაცემთა ბაზასთან ქსელში ექსკლუზიურ რეჟიმში და უკიდურესად ნელი, როდესაც რამდენიმე მომხმარებელი მუშაობს ერთდროულად
სწრაფი მომხმარებლის გამოცდილება სერვერზე ლოკალური მონაცემთა ბაზასთან და ნელი მუშაობა ქსელში
ფაილური სისტემის წვდომა სულ რაღაც 10 მბ/წმ-ზე ნაკლებია

ასე რომ, მე მივეცი დავალება, დავრწმუნდე, რომ სამივე მომხმარებელს შეეძლო ერთდროულად იმუშაოს 1C-ში! სასაცილოა, არა?

ყველა ხუმრობა დამავიწყდა, როცა დავინახე, რასთან მქონდა საქმე: „სერვერი“ ჩვეულებრივი საოფისე კომპიუტერის სახით და ორი ლეპტოპი.

ბედნიერება არასრული იქნებოდა, რომ არა მშვენიერი ოპერაციული სისტემები - Windows 7 კომპიუტერზე და ერთ ლეპტოპზე, Windows 8 მეორეზე.

ლეპტოპებზე დოკუმენტების ერთდროულად განთავსების მცდელობისას, ერთი დარჩა დაახლოებით ერთი წუთის განმავლობაში, ხოლო მეორე ჩამოვარდა 1C-დან შეცდომის ტექსტით "მაგიდა ვერ ჩაკეტა...".

ლეპტოპზე 1C-ის გაშვება ცალკე შოუა, რომელიც დაახლოებით გაგრძელდა 3 წუთი!

ბევრ რესურსზე წავაწყდი რჩევას, გადახვიდე ტერმინალის წვდომაზე მუშაობაზე. სამწუხაროდ, Windows 7 არ გაძლევთ საშუალებას გადაიქცეთ ტერმინალის სერვერად სტანდარტული ხელსაწყოების გამოყენებით - არის მაქსიმუმ ერთი აქტიური კავშირი. ამ შემთხვევაში, დარჩენილი სესიები არ წყდება, შეგიძლიათ ხელახლა დაუკავშირდეთ სხვა მომხმარებლის ქვეშ - წინა მომხმარებლის „გაგდებას“, მაგრამ მისი სესიის შეწყვეტის გარეშე. ამიტომ, თქვენ უნდა გადაიტანოთ 1C სერვერის OS-ზე, სადაც ასეთი შეზღუდვები არ არსებობს. კლიენტმა, საკუთარი რისკის ქვეშ, მოაგვარა პრობლემა მესამე მხარის პროგრამის გამოყენებით Windows7_SP1_RDPhack.

მაგრამ თავგადასავლები ამით არ დასრულებულა. ტერმინალის კავშირშიც კი იყო მნიშვნელოვანი შეფერხებები. კიდევ ერთხელ დამეხმარა ყოვლისშემძლე საძიებო სისტემები. ქვემოთ მოცემულია 1C ფაილის დაჩქარების რჩევები, რომლებსაც მივყევი:

1. გამორთვაქსელის პროტოკოლის გამოყენება IPv6, დააკონფიგურირეთ მისამართები „ძველ“ IPv4-ზე.

2. დაამატეთ 1C პროცესები Windows Firewall-ის გამონაკლისებს, ასევე ანტივირუსულ გამონაკლისებს, ან მთლიანად გამორთეთ ისინი (უფრო სარისკო, მაგრამ უბრალო ტესტმა აჩვენა სიჩქარის გაზრდადოკუმენტების ხელახალი გადაცემა, როდესაც Avast ანტივირუსი გამორთულია ფაქტორი!)

3. დაიწყეთ სრული ტექსტის ძიების ინდექსირება 1C-ში ან მთლიანად გამორთეთ

4. გაუშვით მონაცემთა ბაზის ტესტირება და დაფიქსირება, შეამოწმეთ ChDbfl უტილიტაში

5. გაუშვით Check Configuration პუნქტი კონფიგურაციაში (თუ კონფიგურაცია არ არის სტანდარტული, ეს შეიძლება სასარგებლო იყოს). კონფიგურაციის შემოწმების შედეგების საფუძველზე, ის ჯადოსნურად შემცირდა ზომით თითქმის მესამედით. მე ნამდვილად არ ჩავუღრმავდი ზუსტად იმას, რაც ჩემამდე განაახლეს შემომავალმა პროგრამისტებმა, მაგრამ ფაქტი აშკარაა.

6. გამორთეთ არასაჭირო ფუნქციური პარამეტრები.

7. დააყენეთ მომხმარებლის უფლებები. (ეს და წინა რჩევა სულელურად მეჩვენებოდა მანამ, სანამ დოკუმენტების სიის გახსნისას არ დავაკვირდი მართული ფორმების რენდერირებას. რაც უფრო ნაკლებად არასაჭიროა მართულ ინტერფეისში, მით უფრო სწრაფად მუშაობს ის, როგორც წესი)

8. დაიწყეთ ჯამების ხელახალი გამოთვლა და თანმიმდევრობის აღდგენა (მნიშვნელოვანი ზრდა შეიძლება მოხდეს მხოლოდ იმ შემთხვევაში, თუ ჯამები დიდი ხნის განმავლობაში არ არის აღდგენილი)

9. მონაცემთა ბაზის სიის პარამეტრებში მიუთითეთ "Connection speed - low" (ამან დიდი შედეგი არ გამოიღო, გარდა იმისა, რომ ქვესისტემების სურათები გამორთული იყო :))

ყველა ამ ნაბიჯის დასრულების შემდეგ, 1C ფაილების მონაცემთა ბაზამ ბევრად უფრო სწრაფად დაიწყო მუშაობა. მაქსიმუმ 10 წამში დაიწყო გაშვება, ხოლო დოკუმენტის გადაცემის სიჩქარე საშუალოდ 12-ჯერ გაიზარდა.

შესაძლოა, ეს მოკლე სტატია გამოგადგებათ, თუ მოულოდნელად დაგჭირდებათ თქვენი 1C ფაილების მონაცემთა ბაზის დაჩქარება.

P.S: მაგრამ ფაილის 1C გაშვება ქსელის წვდომის გამოყენებით გაზიარებულ საქაღალდეში ჯერ კიდევ არარეალურია, რადგან... ყველაზე სწრაფი მყარი დისკი, ოპერატიული მეხსიერება და პროცესორიც კი შეექმნება ქსელის ბლოკირებას და ერთზე მეტი მომხმარებლის მუშაობა პრაქტიკულად შეუძლებელი იქნება. ჩვენ ვსაუბრობთ კონკრეტულად UT 11.1-ის კონფიგურაციაზე. საკუთარი ხელით დაწერილი მცირე კონფიგურაციები შეიძლება საკმაოდ სწრაფად იმუშაოს ფაილის ვერსიაშიც კი.

დამატებები კომენტარებიდანგამოსაქვეყნებლად:

დისკის დეფრაგმენტატორიფაილის ბაზით

კონვოლუციამონაცემთა ბაზა (შეიძლება სასარგებლო იყოს, თუ მონაცემთა ბაზა დიდია, მაგალითად, რამდენიმე წლის განმავლობაში). კლიენტის მონაცემთა ბაზა საკმაოდ ახალგაზრდა იყო, ამიტომ შემცირება არაპრაქტიკული იყო.

ტექნიკის განახლება - უფრო სწრაფი მყარი დისკი, ახალი გადამრთველი, პროცესორი და ა.შ.

დააინსტალირეთ ვებ სერვერზე, წვდომა თხელი კლიენტის გამოყენებით. აქ მოსაზრებები იყოფა. ზოგი ამბობს, რომ ეს ბევრჯერ უფრო სწრაფია, ზოგი ამბობს, რომ აჩქარება არ შეინიშნება.