2. უერთდება ვირტუალური ცხრილებით

თუ მოთხოვნა იყენებს კავშირს 1C: Enterprise შეკითხვის ენის ვირტუალურ ცხრილთან (მაგალითად, " RegisterAccumulations.Products.Remains() ”) და მოთხოვნა შესრულებულია არადამაკმაყოფილებელი შესრულებით, რეკომენდებულია ვირტუალური ცხრილის გამოძახება ცალკე მოთხოვნად და შედეგების შენახვა დროებით ცხრილში. ანუ, თქვენ უნდა გამოიყენოთ იგივე რეკომენდაცია, რაც ქვემოთხოვნით შეერთების შემთხვევაში (იხ. პუნქტი 1).

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

3. შეუსაბამობა ინდექსებსა და შეკითხვის პირობებს შორის

პირობები გამოიყენება მოთხოვნის შემდეგ განყოფილებებში:

• აირჩიეთ... FROM... სად<условие>
• კავშირი...BY<условие>
• ᲐᲘᲠᲩᲘᲔ<ВиртуальнаяТаблица>(, <условие>)
• ქონა<условие>

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

• მოთხოვნა 1. ინდექსი შეიცავს პირობაში ჩამოთვლილ ყველა ველს;
• მოთხოვნა 2. ეს ველები არის ინდექსის დასაწყისში;
• მოთხოვნა 3. ეს ველები ზედიზედ არის, ანუ ველები, რომლებიც არ არის ჩართული მოთხოვნის პირობაში, არ არის „ჩამოკიდებული“ მათ შორის;

1C:Enterprise-ის მიერ შექმნილი ძირითადი ინდექსები:

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

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

კონფიგურაცია აღწერს დაგროვების რეგისტრს პროდუქტები საწყობებში:

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

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

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

მოთხოვნა 1

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

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

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

მოთხოვნა 2

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

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

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

მოთხოვნა 3

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

4. ლოგიკური OR-ის გამოყენება პირობებში

4.1 ლოგიკური OR-ის გამოყენება მოთხოვნის WHERE განყოფილებაში

თქვენ არ უნდა გამოიყენოთ OR მოთხოვნის WHERE განყოფილებაში. ამან შეიძლება გამოიწვიოს DBMS-მა ვერ გამოიყენოს ცხრილის ინდექსები და განახორციელოს სკანირება, რაც გაზრდის მოთხოვნის შესრულების დროს და დაბლოკვის ალბათობას. ამის ნაცვლად, თქვენ უნდა გაყოთ ერთი შეკითხვა რამდენიმე ნაწილად და დააკავშიროთ შედეგები.

მაგალითად, მოთხოვნა

აირჩიეთ პროდუქტი . სახელი FROMდირექტორია . პროდუქტები HOW Product WHERE სტატია = "001" ანგამყიდველი კოდი = "002"

უნდა შეიცვალოს მოთხოვნით

აირჩიეთ პროდუქტი . სახელი FROMდირექტორია . პროდუქტები HOW Product WHERE სტატია = "001" |COMBINE ALL |პროდუქტის შერჩევა . სახელი FROMდირექტორია . პროდუქტები HOW Product WHERE სტატია = "002"

4.2. მომხმარებლების დარეგისტრირება მრავალ როლში, თითოეულს აქვს RLS

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

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

ამის ნაცვლად, თქვენ უნდა შექმნათ „შერეული“ როლი - „ბუღალტერი-HR ოფიცერი“ და დაარეგისტრიროთ მისი RLS ისე, რომ თავიდან აიცილოთ OR-ის გამოყენება ამ მდგომარეობაში და ჩართოთ მომხმარებელი ამ ერთ როლში.

4.3 OR-ის გამოყენება კავშირის პირობებში

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

5. Subqueries-ის გამოყენება შეერთების მდგომარეობაში

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

მოთხოვნა . ტექსტი = "აირჩიე |საიდან | ფასები B პერიოდი. | SELECT MAXIMUM(Prices LastMonth.Period) | სარეგისტრაციო ინფორმაცია ფასი გასული თვის ფასების მიხედვით | WHERE ფასები გასულ თვეში.პერიოდი< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | და გასული თვის ფასები.ნომენკლატურა = დარჩენილი საქონელი.ნომენკლატურა |) | სად არის დარჩენილი საქონელი.საწყობი = &საწყობი";

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

მოთხოვნა . ტექსტი = " // ამ ნივთებისთვის წინა პერიოდში ფასების დადგენის მაქსიმალური თარიღები |არჩევა | დარჩენილი პროდუქტების ნომენკლატურა AS ნომენკლატურა, | MAXIMUM(Prices.Period) AS პერიოდი |ადგილის თარიღები ნომენკლატურების მიხედვით |საიდან | RegisterAccumulations.GoodsInWarehouses.Remainings(...) AS RemainingProducts | მარცხნივ კავშირი რეგისტრაციაInformation.Price AS ფასები | პროგრამული უზრუნველყოფის ფასები.ნომენკლატურა = დარჩენილი პროდუქტები.ნომენკლატურა და | ფასები.პერიოდი< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | ჯგუფი დარჩენილი პროდუქტების მიხედვით.ნომენკლატურა | WHERERemainingItems.Warehouse = &Warehouse; // აირჩიეთ მონაცემები ფასის მიხედვით ნაპოვნი პერიოდისთვის |არჩევა | Dates By Nomenclatures.Nomenclature AS Nomenclature, | ფასები.ფასი გასული თვის ფასი |FROM DateBy ნომენკლატურებიდან | მარცხნივ კავშირი რეგისტრაციაInformation.Price AS ფასები | პროგრამული უზრუნველყოფის ფასები.ნომენკლატურა = დარჩენილი პროდუქტები.ნომენკლატურა და | ფასები.პერიოდი = თარიღები ნომენკლატურების მიხედვით.პერიოდი " ;

6. მონაცემების მიღება წერტილის მეშვეობით კომპოზიტური ტიპის ველებიდან

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

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

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

მაგალითი

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

მოთხოვნა . ტექსტი = "აირჩიე | გაყიდვები.რეგისტრატორი.ნომერი, | გაყიდვები.რეგისტრატორი.თარიღი, | გაყიდვები. | გაყიდვები, რაოდენობა, | გაყიდვები.ღირებულება |საიდან |სად...

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

მოთხოვნა . ტექსტი = "აირჩიე | არჩევანი | შემდეგ EXPRESS (გაყიდვები. რეგისტრატორი AS დოკუმენტი. საქონლისა და მომსახურების გაყიდვები). ნომერი | შემდეგ EXPRESS (გაყიდვები. რეგისტრატორი, როგორც დოკუმენტი. მყიდველის შეკვეთა). ნომერი | END SELECTION AS ნომერი, | არჩევანი | საქონლისა და სერვისების გაყიდვების ლინკი | შემდეგ EXPRESS (გაყიდვები. რეგისტრატორი AS დოკუმენტი. საქონლისა და მომსახურების გაყიდვები). თარიღი | WHEN Sales.რეგისტრატორის ლინკი Document.Buyer Order | შემდეგ EXPRESS (გაყიდვები. რეგისტრაცია როგორც დოკუმენტი. მყიდველის შეკვეთა). თარიღი | შერჩევის დასრულება თარიღის მიხედვით, | გაყიდვები. | გაყიდვები, რაოდენობა, | გაყიდვები.ღირებულება |საიდან | RegisterAccumulations.Sales HOW გაყიდვები |სად | გაყიდვები.რეგისტრატორის ლინკი დოკუმენტი.საქონლისა და მომსახურების გაყიდვები | ან გაყიდვები. რეგისტრატორის ბმული დოკუმენტი. მყიდველის შეკვეთები";

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

7. ვირტუალური ცხრილების გაფილტვრა პარამეტრების გამოყენების გარეშე

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

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

მოთხოვნა . ტექსტი = "აირჩიე | ნომენკლატურა |საიდან | RegisterAccumulations.GoodsInWarehouses.Remains() |სად | საწყობი = &საწყობი";

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

მოთხოვნა . ტექსტი = "აირჩიე | ნომენკლატურა |საიდან | RegisterAccumulations.GoodsInWarehouses.Remains(, Warehouse = &Warehouse)";