ჩვენი დღევანდელი სტატია შექმნილია იმისთვის, რომ დამწყები დუმებს გაეგოთ ელექტრონული ფოსტის სერვისების ლაბირინთები, რომელთაგან ბევრია ინტერნეტში. ჩვენ გადავხედავთ საკმაოდ ტრივიალურ, მაგრამ ბევრისთვის შემაშფოთებელ კითხვას - როგორ დავურთოთ ფაილი გამავალ წერილს Gmail, Yandex, Rambler და Mail.Ru სერვისებში.

(mosloadposition გამართვა)

Gmail

Gmail-ში ახალი ელფოსტის შექმნისას დან Googleუბრალოდ დააწკაპუნეთ ბმულზე „ფაილის მიმაგრება“ და შემდეგ იპოვეთ სასურველი ფაილი ან არქივი თქვენს კომპიუტერში და ორჯერ დააწკაპუნეთ მასზე.

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

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

ფაილის ასოზე მიმაგრების მიზნით, უბრალოდ მოხსენით ველი მის გვერდით.

TO Gmail ელფოსტაშეგიძლიათ დაურთოთ იმდენი ფაილი, რამდენიც გსურთ. თქვენ უბრალოდ უნდა გახსოვდეთ, რომ წერილის მთლიანი ზომა, ყველა თანდართული ფაილის ჩათვლით, არ უნდა აღემატებოდეს 25 მბ-ს.
ასევე გაითვალისწინეთ, რომ გადაზიდვა შესრულებადი ფაილებიმაგალითად, EXE ფორმატში, Gmail სერვისიაკრძალულია. თუმცა, ფაილების არქივში შეფუთვა ასევე არ უწყობს ხელს. თუმცა, არსებობს გამოსავალი ნებისმიერი სიტუაციიდან: შეგიძლიათ შეცვალოთ ფაილის გაფართოება, მაგალითად, EXE-დან EX-ზე და აცნობოთ წერილის მიმღებს, რომ კომპიუტერში შენახვის შემდეგ, ფაილს უნდა დაერქვას სახელი.

ფოსტა Yandex-ზე

ფაილების მიმაგრება ასოებზე Yandex საფოსტო სერვისში ისეთივე მარტივია. უბრალოდ დააწკაპუნეთ ღილაკზე „ფაილის მიმაგრება...“ და აირჩიეთ სასურველი ფაილი ან არქივი თქვენს კომპიუტერში და შემდეგ ორჯერ დააწკაპუნეთ მასზე.

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

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

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

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

ფოსტა Rambler-ზე

Rambler ფოსტის სერვისი უზრუნველყოფს ფაილების გამავალ წერილებზე მიმაგრების მსგავს სტანდარტს: თქვენ უნდა დააჭიროთ ღილაკს „ფაილების მიმაგრება“, იპოვოთ და აირჩიოთ საჭირო ფაილებიკომპიუტერის დისკზე.

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

Mail.Ru

და ბოლოს, ბოლო ელ.ფოსტის სერვისი, რომელსაც დღეს განვიხილავთ, არის საფოსტო მომსახურება Mail.Ru. ის, Yandex-ის მსგავსად, გაძლევთ საშუალებას გააგზავნოთ ფაილები ორი გზით - დაურთოთ პირდაპირ წერილს ან ატვირთოთ [email protected]ზე. ამ უკანასკნელ შემთხვევაში, თქვენი შეტყობინების მიმღებს გაეგზავნება ბმული ფაილის გადმოსაწერად.

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

წერილზე დართული ყველა ფაილის ჯამური ზომა არ უნდა აღემატებოდეს 22 მბ-ს. თუ გასაგზავნად მომზადებული ფაილები 30 მბ-ზე მეტია, მაშინ ისინი უნდა აიტვირთოთ [email protected] სერვერზე. ამისათვის დააჭირეთ ბმულს "შეცვლა" და აირჩიეთ ფაილების მიმაგრების ეს მეთოდი - "ატვირთეთ ყველა ფაილი [email protected]ზე და მიამაგრეთ წერილს ბმულების სახით." ამ შემთხვევაში, მიმღები მიიღებს წერილს ავტომატურად გენერირებული ბმულებით სერვერიდან ფაილების ჩამოსატვირთად.

20 ფაილზე მეტი არ შეიძლება დაერთოს თითოეულ გამავალ წერილს. ამ შემთხვევაში, თითოეული ფაილის ზომა არ უნდა აღემატებოდეს 1 გბ-ს.

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

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

განსაკუთრებით იაჩაინიკისთვის, ელენა კარლტონისთვის

(mosloadposition cpanel)

ინფობაზების ფაილური ვერსიის გამოყენებისას ხშირად ჩნდება შეცდომა „მაქსიმალური ლიმიტის გადაჭარბება“. დასაშვები ზომა შიდა ფაილი“, უპირველეს ყოვლისა, განხორციელების თავისებურებებთან ფაილის რეჟიმი. იგი შეიცავს 4 ფაილს:

• ცხრილის სტრუქტურის აღწერილობის ფაილი
• ინდექსის ფაილი (გადატანილია ძირითადი ფაილიდან)
• ღირებულებების ფაილი
• ჩამწერი ფაილი

ასევე დაწესებულია შეზღუდვები, როგორიცაა: შიდა ფაილის მაქსიმალური ზომა არ უნდა აღემატებოდეს 4 გბ-ს, გასაღების სიგრძე ინდექსში არ უნდა აღემატებოდეს 1920 ბაიტს და ბოლოს, ინდექსაციის ველების რაოდენობა არ უნდა აღემატებოდეს 256 ველს. ჩვენთვის ყველაზე მნიშვნელოვანი არის 4 GB ფაილის ზომის ლიმიტი. როგორ შეიძლება ეს? თქვენ ამბობთ. არსებობს მონაცემთა ბაზის ფაილები 10 და 12 GB. დიახ, ასეა - ეს ნიშნავს, რომ არც ერთი შიდა ფაილი არ აღემატებოდა 4 გბ-ს. ვბედავ იმედები გაგიცრუო. და მაინც, მონაცემთა ბაზის მაქსიმალური ზომა, თავად 1Cv8.CD ფაილი, ნაგულისხმევად მაინც შემოიფარგლება 16 გბ-ით (მაგრამ ამის გვერდის ავლითაც კი შესაძლებელია), რადგან ეს არის ჟურნალის მისამართის შეზღუდვა. ფაილური სისტემა NTFS (16 GB ფაილები არ არის კოპირებული Windows-ში, რადგან თუ კითხვა/ჩაწერა ვერ მოხერხდა ფრაგმენტზე, რომელიც აღემატება ამ 16 გბ-ს, OS ვერ აკონტროლებს ფაილური სისტემის მთლიანობას.)

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

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

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

• ჩართეთ ტექნოლოგიური ჟურნალი
• ჩვენ ვქმნით ცარიელი ფაილი ogcfg.xml შემდეგი შინაარსით, მაგალითად

და ჩადეთ conf დირექტორიაში, მაგალითად C:\Program Files\1cv82\8.2.19.130\bin\conf

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

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

"შეცდომა საინფორმაციო ბაზის ჩატვირთვისას. ყველა მონაცემი არ ჩაიტვირთა საინფორმაციო ბაზაში: DBMS შეცდომის გამო: შიდა ფაილის მაქსიმალური დაშვებული ზომა გადააჭარბა"D:\1CBASES\NewDB/1Cv8.1CD" "

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

ამრიგად, ამ შეცდომის რამდენიმე მიზეზი შეიძლება იყოს:

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

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

დაგროვების რეგისტრები - ცალკე თემა. ჯამების ცხრილების ზომა შეიძლება აღემატებოდეს რეგისტრში შესვლის ცხრილების ზომას, ხშირად მნიშვნელოვნად. ზოგჯერ შედეგების მარტივი ხელახალი გაანგარიშებაც კი დაგეხმარებათ.

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

რა უნდა გააკეთოს, თუ თქვენს მონაცემთა ბაზაში თითოეული ცხრილი 4 გბ-ზე ნაკლებია, მაგრამ შეცდომა მაინც ხდება?

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

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

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

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

ჩვენ ვდებთ ტექნოლოგიურ ჟურნალს - საქაღალდეში " C:\Program Files (x86)\1cv82\__PlatformVersionNumber__\bin\conf\(ან მსგავსი __PlatformVersionNumber__ჩადეთ თქვენი) ჩადეთ ფაილი logcfg.xmlდაახლოებით შემდეგნაირად:

ჩვენ ყურადღებით ვუზრუნველყოფთ, რომ ნაგავსაყრელისა და ჟურნალების დირექტორიებია:

1. იყვნენ
2. განსხვავდებოდა
3. იკითხება და დასაწერი იყო ვინდოუსის მომხმარებელი, რომლის სახელით თქვენ აწარმოებთ კონფიგურატორს.

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

EXCPCNTX-ის პირველი გამოჩენა ჟურნალში ჩემს შემთხვევაში მიუთითებს ბრძანებაზე, რომელმაც გამოიწვია შეცდომა: შექმენით ინდექსი _Accum27148_ByDims_TRRRRRRRRRSSR(თქვენი ინდექსის სახელი განსხვავებული იქნება).

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

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

"თუ გასაღების სიგრძე აღმოჩნდება 2K-თან ახლოს, მაშინ ინდექსების ზომის მკვეთრი ზრდა იწყება მთელი რიგი უსიამოვნო შედეგებით."

და მართლაც, არაფერი შეცვლილა 2013 წელს - წელს მსგავსი შემთხვევებიინდექსის ზომაში არის ზვავის მსგავსი ზრდა ფაილის მონაცემთა ბაზა. და როდესაც ინდექსის ცხრილი აჭარბებს 4 გბ ლიმიტს, loading.DT ჩერდება შეცდომით.

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

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

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

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

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

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

"შეცდომა საინფორმაციო ბაზის ჩატვირთვისას. ყველა მონაცემი არ ჩაიტვირთა საინფორმაციო ბაზაში: DBMS შეცდომის გამო: შიდა ფაილის მაქსიმალური დაშვებული ზომა გადააჭარბა"D:\1CBASES\NewDB/1Cv8.1CD" "

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

ამრიგად, ამ შეცდომის რამდენიმე მიზეზი შეიძლება იყოს:

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

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

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

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

რა უნდა გააკეთოს, თუ თქვენს მონაცემთა ბაზაში თითოეული ცხრილი 4 გბ-ზე ნაკლებია, მაგრამ შეცდომა მაინც ხდება?

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

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

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

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

ჩვენ ვდებთ ტექნოლოგიურ ჟურნალს - საქაღალდეში " C:\Program Files (x86)\1cv82\__PlatformVersionNumber__\bin\conf\(ან მსგავსი __PlatformVersionNumber__ჩადეთ თქვენი) ჩადეთ ფაილი logcfg.xmlდაახლოებით შემდეგნაირად:

ჩვენ ყურადღებით ვუზრუნველყოფთ, რომ ნაგავსაყრელისა და ჟურნალების დირექტორიებია:

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

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

EXCPCNTX-ის პირველი გამოჩენა ჟურნალში ჩემს შემთხვევაში მიუთითებს ბრძანებაზე, რომელმაც გამოიწვია შეცდომა: შექმენით ინდექსი _Accum27148_ByDims_TRRRRRRRRRSSR(თქვენი ინდექსის სახელი განსხვავებული იქნება).

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

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

"თუ გასაღების სიგრძე აღმოჩნდება 2K-თან ახლოს, მაშინ ინდექსების ზომის მკვეთრი ზრდა იწყება მთელი რიგი უსიამოვნო შედეგებით."

და მართლაც, 2013 წელს არაფერი შეცვლილა - ასეთ შემთხვევებში შეინიშნება ზვავის მსგავსი ზრდა ფაილის ბაზაზე ინდექსის ზომაში. და როდესაც ინდექსის ცხრილი აჭარბებს 4 გბ ლიმიტს, loading.DT ჩერდება შეცდომით.

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

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

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

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

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