სახლში ინსტაგრამი

1c ვირტუალური მაგიდის ნაშთები და ბრუნვა. Query Batch ჩანართი

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

1. „IZ“ დიზაინი.

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

აირჩიეთ დირექტორია.ბანკები.*

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

SELECT Banks.* FROM Directory.Banks AS Banks

2. მონაცემთა შეკვეთა საცნობარო ველით

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

ამ შემთხვევაში, დოკუმენტებისთვის შეკვეთა მოხდება თანმიმდევრობით "თარიღი-> ნომერი", საცნობარო წიგნებისთვის "მთავარი ხედი". თუ შეკვეთა არ ხდება საცნობარო ველებით, მაშინ "AUTO ORDER" კონსტრუქციის გამოყენება არ არის რეკომენდებული.

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

3.მინიშნების ტიპის ტექსტური წარმოდგენის მიღება. "PRESENTATION" დიზაინი.

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

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

4. თარგის მიხედვით მონაცემების შერჩევის პირობა.

მაგალითად, თქვენ უნდა მიიღოთ ფორმის თანამშრომლების მობილური ტელეფონები (8 -123- 456-78-912). ამისათვის თქვენ უნდა დააყენოთ შემდეგი პირობა მოთხოვნაში:

SELECT Employee.Name, Employee.Phone AS Phone FROM Directory.Employees AS Employees WHERE Phone LIKE "_-___-___-__-__"

სიმბოლო "_" არის სერვისის სიმბოლო და ცვლის ნებისმიერ სიმბოლოს.

5. ჯამებისა და დაჯგუფებების ერთდროული გამოყენება.

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

SELECT Provision of Services.Organization AS Organization, Provision of Services.Nomenclature AS Nomenclature, SUM(Provision of Services.Document of Document) AS Document of Document.Summ of Document FROM Document.Summ of Document. მომსახურების.ნომენკლატურის შედეგები ზოგადი, ორგანიზაცია, ნომენ კლატურა

ამ შემთხვევაში, მოთხოვნა დაბრუნდება თითქმის იგივე, რაც შემდეგი მოთხოვნა:

SELECT Provision of Services.Organization AS Organization, Provision of Services.Nomenclature AS Nomenclature, Provision of Services.Document AS Amount of Document FROM Document.მომსახურების მიწოდება AS სერვისების მიწოდება RESULTS AMOUNT (დოკუმენტის ოდენობა) BY, ორგანიზაცია, GENERALER ნომენკლატურა

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

6. ველების გამორიცხვა.

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

მოთხოვნა:

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

აირჩიეთ Payment.Link, Payment.Organization, Payment.Organization, Organizations. AdministrativeUnit FROM Document.Payment AS Payment LEFT JOIN Directory.Organizations AS Organizations Software Payment.Organization = Organizations.Link

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

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

აირჩიეთ UnallocatedPayments.Register.Date, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

თქვენ უნდა შეზღუდოთ კომპოზიტური ველის ტიპი ლოგერით:

SELECT EXPRESS(UnallocatedPayments.Register AS Document.Payment).Date, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

7. მშენებლობა "WHERE"

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

მაგალითი. აუცილებელია ყველა კლიენტის არჩევა კლიენტთა დირექტორიადან და იმ კლიენტებს, რომლებსაც აქვთ გადახდის დოკუმენტი ატრიბუტის "Organization" = &Organization მნიშვნელობით, გამოაჩინონ დოკუმენტი "Payment", ვისაც არ აქვს, არ აჩვენოს იგი.

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

აირჩიეთ Payment.Link AS Payment, Payment.Sareholder AS Client PLACE toPayments FROM Document.Payment AS Payment WHERE Payment.Branch = &Branch; //////////////////////////////////////////// ////////////////////////// SELECT Clients.Link AS Client, ISNULL(tPayment.Payment, "") AS Payment FROM Directory .Clients AS კლიენტები LEFT CONNECTION toppayments AS toppayments SOFTWARE Clients.Link = topayments.Client

ამ მდგომარეობის თავიდან აცილება შეგიძლიათ სხვა გზით. აუცილებელია „WHERE“ პირობის დაწესება უშუალოდ ორ ცხრილს შორის ურთიერთობაზე. მაგალითი:

SELECT Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers LEFT CONNECTION Document.Payment AS გადახდის პროგრამული უზრუნველყოფა (Clients.Link = Payment.Client AND Payment.Client.Name LIKE "Sugar Packet", Client.LinkY) Ბმული

8. უერთდება ჩადგმულ და ვირტუალურ ცხრილებს

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

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

SELECT UnallocatedPaymentsRemains.Customer, UnallocatedPaymentsRemains.AmountRemaining FROM (SELECT Clients.Link AS Link FROM Directory.Clients AS Clients WHERE Clients.Link IN(&Clients)) AS NestedQueryInRegistrationAcTedAlocated yments BY Nested Request.Link = UnallocatedPaymentsBalances. დამკვეთი

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

SELECT Clients.Link AS Link PLACE tClients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&Clients) ; //////////////////////////////////////////// ////////////////////////// აირჩიეთ tClients.Link, UnallocatedPaymentsRemains.AmountRemaining, FROM tClients AS tClients LEFT JOIN RegisterAcumulations.UnallocatedPayments,Client.Balances IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

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

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

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

SELECT Clients.Link AS Link PLACE tClients FROM Directory.Clients AS Clients INDEX BY Link WHERE
Clients.Link B (&Clients) ; //////////////////////////////////////////// ////////////////////////// აირჩიეთ UnallocatedPayments.AmountBalance, UnallocatedPayments.Client AS Client PLACE balances FROM RegisterAccululations.UnallocatedPayments.Balances(, კლიენტი B ( აირჩიეთ tClients ბმული tClients-დან)) AS UnallocatedPaymentsBalances; //////////////////////////////////////////// ////////////////////////// SELECT tClients.Link, toRemainders.AmountRemaining AS AmountRemaining FROM tClients AS tClients LEFT JOIN toRemainders AS Remainders BY tC. = tRemainings.კლიენტი

9.მოთხოვნის შედეგის შემოწმება.

შეკითხვის შედეგი შეიძლება ცარიელი იყოს; ცარიელი მნიშვნელობების შესამოწმებლად გამოიყენეთ შემდეგი კონსტრუქცია:

ResRequest = Request.Execute(); თუ resQuery.Empty() მაშინ Return; დაასრულე თუ;

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

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

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

11. კონსტრუქცია „ჰევინგი“.

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

აირჩიეთ Payment.Customer, AMOUNT(Payment.Amount) AS Amount FROM Document.Payment AS Payment WHERE MONTH(Payment.Date) = 9 GROUP BY Payment.Customer HAVING AMOUNT(Payment.Amount) > 13000

კონსტრუქტორში, ამისათვის უბრალოდ გადადით "პირობების" ჩანართზე, დაამატეთ ახალი პირობა და შეამოწმეთ "მორგებული" ჩამრთველი. მაშინ უბრალოდ დაწერე თანხა (გადახდა. თანხა) > 13000

12. NULL მნიშვნელობა

აქ არ აღვწერ მონაცემთა ბაზაში სამ ღირებულების ლოგიკის პრინციპებს, ამ თემაზე ბევრი სტატიაა. მოკლედ როგორ NULLშეიძლება გავლენა იქონიოს მოთხოვნის შედეგზე. მნიშვნელობა NULL რეალურად არ არის მნიშვნელობა და ის ფაქტი, რომ მნიშვნელობა განუსაზღვრელია, უცნობია. ამიტომ, ნებისმიერი ოპერაცია NULL-ით აბრუნებს NULL-ს, იქნება ეს შეკრება, გამოკლება, გაყოფა თუ შედარება. NULL მნიშვნელობა არ შეიძლება შევადაროთ NULL მნიშვნელობას, რადგან არ ვიცით რა შევადაროთ. იმათ. ორივე ეს შედარებაა: NULL = NULL, NULL<>NULL არ არის True ან False, უცნობია.

მოდით შევხედოთ მაგალითს.

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

აირჩიეთ "გადახდების გარეშე" AS ატრიბუტი, NULL AS დოკუმენტი PLACE toppayments; //////////////////////////////////////////// ///////////////////////// SELECT Clients.Link AS Client, Payment.link How Payment PUT tClientPayment Directory.Clients AS Clients LEFT CONNECTION Document. Payment AS Payment Software Clients.Link = Payment.Sareholder; //////////////////////////////////////////// ////////////////////////// აირჩიეთ tClientPayment.Client FROM tClientPayment AS tClientPayment INTERNAL Join tPayment AS tTopay BY tClientPayment.Payment = tPayment.

ყურადღება მიაქციეთ მეორე დროებით ცხრილს tClientPayment. მარცხენა შეერთებით მე ვირჩევ ყველა კლიენტს და ყველა გადახდას ამ კლიენტებისთვის. იმ კლიენტებისთვის, რომლებსაც არ აქვთ გადახდები, "გადახდა" ველი იქნება NULL. ლოგიკის მიხედვით, პირველ დროებით ცხრილში "tPayments" მე დავნიშნე 2 ველი, მათგან ერთი NULL, მეორე ხაზი "არ აქვს გადახდები". მესამე ცხრილში ვაკავშირებ ცხრილებს “tClientPayment” და “tPayment” ველების “Payment” და “Document” გამოყენებით შიდა შეერთებით. ჩვენ ვიცით, რომ პირველ ცხრილში „დოკუმენტის“ ველი არის NULL, ხოლო მეორე ცხრილში, ვისაც არ აქვს გადახდები ველში „გადახდა“ არის ასევე NULL. რას დაგვიბრუნებს ასეთი კავშირი? მაგრამ ის არაფერს დააბრუნებს. იმის გამო, რომ შედარება NULL = NULL არ ფასდება True-მდე.

იმისათვის, რომ მოთხოვნამ დააბრუნოს მოსალოდნელი შედეგი, გადავიწეროთ იგი:

აირჩიეთ "გადახდების გარეშე" AS ატრიბუტი, VALUE(Document.Payment.EmptyLink) AS Document PLACE toPayments; //////////////////////////////////////////// ///////////////////////// SELECT Clients.Link AS Client, ISNULL(Payment.Link, VALUE(Document.Payment.EmptyLink)) HOW გადახდა PUT tClientPayment FROM Directory.Clients AS Clients LEFT CNNECTION Document.Payment AS Payment BY Clients.Link = Payment.Sareholder; //////////////////////////////////////////// ////////////////////////// აირჩიეთ tClientPayment.Client FROM tClientPayment AS tClientPayment INTERNAL Join tPayment AS tTopay BY tClientPayment.Payment = tPayment.

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

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

13. დიზაინის „არჩევა, როცა...მაშინ...დასრულდეს“ დაუსაბუთებელი ფუნქცია.

იმ შემთხვევაში, როდესაც საჭიროა მოთხოვნაში "პირობების" კონსტრუქციის აღწერა, ჩვენ ვიყენებთ სტანდარტულ სინტაქსს:

SELECT SELECTION WHEN Users.Name = "Vasya Pupkin" THEN "ჩვენი საყვარელი თანამშრომელი" ELSE "ჩვენ არ ვიცით ეს" END AS FROM Directory.Users AS Users

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

SELECT MONTH(US_CalculationConsumption_ScheduleTurnover.CalculationPeriod) WHEN 1, შემდეგ "იანვარი" WHEN 2, შემდეგ "თებერვალი" WHEN 3, შემდეგ "მარტი" WHEN 4, მაშინ "აპრილი" WHEN 5, შემდეგ "6 მაისი" THEJNH WHEN 8, მაშინ "აგვისტო", WHEN 9, მაშინ "სექტემბერი" WHEN 10, მაშინ "ოქტომბერი", როდესაც 11, მაშინ "ნოემბერი", როდესაც 12, მაშინ "დეკემბერი" სრულდება როგორც თვე

ახლა დიზაინი ნაკლებად რთული და ადვილად გასაგებია.

14. ჯგუფური შეკითხვის შესრულება.

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

SELECT Users.Link AS სრული სახელი, Users. დაბადების თარიღი, Users.Role PUT vtUsers FROM Directory.Users AS Users; //////////////////////////////////////////// ////////////////////////// აირჩიეთ tueUsers.სრული სახელი, tueUsers.დაბადების თარიღი FROM tueUsers AS tueUsers GROUP BY tueUsers.სრული სახელი, tueUsers . Დაბადების თარიღი; //////////////////////////////////////////// ////////////////////////// აირჩიეთ wUsers.სრული სახელი, wUsers.Role FROM wUsers AS wUsers GROUP BY wUsers.სრული სახელი, wUsers. თარიღი დაბადების

tPackage = Request.ExecutePackage();

TP_BirthDate = tPackage.Upload();
TP_Roles = tPackage.Unload();

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

15. პირობები სერიის მოთხოვნაში

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

SELECT Users.Individual.Name AS Name, Users.Individual.Date of Birth AS დაბადების თარიღი, Users.Individual.Code AS Code PLACE vtUsers FROM Directory.Users AS Users; //////////////////////////////////////////// ///////////////////////// აირჩიეთ ინდივიდები. დააკავშირეთ როგორც ინდივიდუალური დირექტორიადან. ინდივიდები, როგორც ინდივიდები

თქვენ შეგიძლიათ დააწესოთ ასეთი პირობები:

WHERE Individuals.Code IN (SELECT vtUsers.Code FROM vtUsers) AND Individuals.Name IN (SELECT vtUsers.Code FROM vtUsers) AND Individuals.BirthDate IN (SELECT vtUsers.DateBirths FROMtv)

და თქვენ შეგიძლიათ გააკეთოთ ეს ასე:

WHERE (Individuals.Code, Individuals.Name, Individuals.Date of Birth) IN (SELECT tueUsers.Code, tueUsers.Name, tueUsers. დაბადების თარიღი FROM tueUsers)

უფრო მეტიც, აუცილებელია წესრიგის დაცვა.

16. შეკითხვის შემქმნელის გამოძახება „მდგომარეობის“ ჯგუფურ მოთხოვნაში

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

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

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

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

upd1. ქულები 11,12
upd2. ქულები 13,14,15,16

გამოყენებული წიგნები:
შეკითხვის ენა "1C:Enterprise 8" - E.Yu. ხრუსტალევა
პროფესიული განვითარება 1C: Enterprise 8 სისტემაში."

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

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

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

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

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

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

ამრიგად, სისტემა არა მხოლოდ უსარგებლო სამუშაოს, არამედ ორჯერ უსარგებლო სამუშაოს გააკეთებს! პირველ რიგში, რესურსები დაიხარჯება ვირტუალური ცხრილის შექმნაზე, რომელიც დაფუძნებულია არასაჭირო მონაცემებზე (სურათზე ისინი მონიშნულია როგორც „მონაცემთა არეები A და B“), შემდეგ კი მუშაობა გაკეთდება ამ მონაცემების საბოლოო შედეგის გასაფილტრად.

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

რა განსხვავებაა ვირტუალური ცხრილის პარამეტრის "დამატების მეთოდის" მნიშვნელობებს შორის?
როდესაც დამატების მეთოდი დაყენებულია "მოძრაობებზე", მაშინ დაბრუნდება მხოლოდ ის პერიოდები, რომლებშიც იყო მოძრაობები. როდესაც დაყენებულია „მოძრაობები და პერიოდის საზღვრები“, მაშინ ზემოხსენებულ მოძრაობას დაემატება 2 ჩანაწერი: მოძრაობები VT პარამეტრებში მითითებული პერიოდის დასაწყისში და ბოლოს. ველი „რეგისტრატორი“ ცარიელი იქნება ამ 2 ჩანაწერისთვის.

ინფორმაცია აღებულია საიტიდან

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

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

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

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

მოდით გამოვიძახოთ დიალოგი PriceSliceLast ვირტუალური ცხრილის პარამეტრების შესაყვანად და მივუთითოთ, რომ პერიოდი გაივლის ReportDate პარამეტრში. ამისათვის აირჩიეთ ეს ცხრილი ცხრილების სიაში და დააჭირეთ ღილაკს ვირტუალური ცხრილის პარამეტრები. შემდეგ აირჩიეთ ცხრილებიდან შემდეგი ველები:

SprNomenclature. მშობელი,

ფასები ნაჭერი უახლესი.ფასი.

მარცხენა მაგიდის შეერთება

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

ბრინჯი. 13.15. შეკითხვისას ცხრილებს შორის ურთიერთობა

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

ბრინჯი. 13.16. ელემენტების შერჩევის პირობები

- სანიშნეზე გაერთიანებები / მეტსახელები:მიუთითეთ ველის მეტსახელი Parent = Service Group და ველი Link = Service. - დააწკაპუნეთ OK-

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

- სანიშნეზე Პარამეტრებიდააყენეთ Nomenclature Type პარამეტრის მნიშვნელობა - Enumeration.Nomenclature Types.Service. გარდა ამისა, ჩვენ მოვხსნით ხელმისაწვდომობის შეზღუდვას ReportDate პარამეტრისთვის. ამ პარამეტრის ველში დააყენეთ თარიღის შემადგენლობა - თარიღი. პერიოდის პარამეტრისთვის, პირიქით, ჩვენ დავაყენეთ ხელმისაწვდომობის შეზღუდვა:

ბრინჯი. 13.17. განლაგების სქემის პარამეტრები

პარამეტრები

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

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

ბრინჯი. 13.18. ანგარიშის სტრუქტურა და ველები

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

ბრინჯი. 13.19. ზოგადი ჯამების ჩვენების პარამეტრები "სერვისის ჯგუფის" დაჯგუფებისთვის

ბრინჯი. 13.20. გლობალური ანგარიშის შედეგების დაყენება და ჩვენება

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

1C-ში: Enterprise mode

მოდით გავუშვათ 1C:Enterprise გამართვის რეჟიმში და პირველ რიგში გავხსნათ პერიოდული რეგისტრი Prices. შემდეგ ჩვენ ვამოწმებთ ანგარიშს.

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

თუ ჩემი პუბლიკაცია თქვენთვის სასარგებლოა, არ დაგავიწყდეთ მისცეთ პლუსი :-)

აქ არის რუბრიკატორი კრებულის ყველა ამოცანისთვის(გვერდი, რომელიც შეიცავს ბმულებს ფორუმის თემებზე თითოეული ამოცანისთვის)
http://chistov.spb.ru/forum/16-969-1

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

ასე რომ, დავიწყოთ:

თუ მას დისტანციურად იღებთ, გამოცდის ბოლოს უნდა გქონდეთ სამუშაო მაგიდაზე ორი ობიექტი:

1. საინფორმაციო ბაზის საბოლოო ატვირთვა (dt ფაილი)
2. ახსნა-განმარტება

სხვა არაფერი არ უნდა იყოს, შუალედური ასლები და ა.შ.

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

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

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

ზოგჯერ დამატებითი კლავიატურიდან აკრეფა უფრო სწრაფია, ვიდრე განლაგების წინ და უკან შეცვლა, რაც დაზოგავს დროს
& = Alt+38

*************************************************************************************************
TimePoint()-ის გამოყენება შეკითხვებში

აკუმულაციისა და აღრიცხვის რეგისტრების შეკითხვებში აუცილებელია ვირტუალური ცხრილის (პერიოდის) პარამეტრად გამოიყენოს არა დოკუმენტის თარიღი, არამედ Moment პარამეტრი, რომელიც განსაზღვრულია კოდში შემდეგნაირად:

მომენტი = ?(გავლის რეჟიმი = დოკუმენტის განთავსების რეჟიმი. ოპერატიული, განუსაზღვრელი, დროის მომენტი());

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

კოდი არის:

Movement.RegisterName.Write = True; Movements.RegisterName.Clear();

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

Movement.RegisterName.Write();

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

მაგრამ ყველგან მე უბრალოდ მივუთითე ამ სამი ხაზის აგება:

Movement.RegisterName.Write = True; Movements.RegisterName.Clear(); Movement.RegisterName.Write();

*************************************************************************************************
მონაცემთა დაბლოკვის ორი გზა არსებობს, მათ შორის არჩევანი დამოკიდებულია გამოყენებულ მეთოდზე - ძველი ან ახალი:

1) რეგულარული კონტროლირებადი ბლოკირება, დოკუმენტების დამუშავების ძველი მეთოდი (Data Blocking ობიექტი)

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

მაგალითი:

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

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

2) დოკუმენტების დამუშავების ახალი მეთოდოლოგია (LockForChange თვისების გამოყენებით = True)

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

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

ანუ თანმიმდევრობა ასეთია:
1. რეესტრში გადასატანად დააყენეთ BlockForChange თვისება = True
2. ჩვენ ვქმნით მოძრაობებს - ჩამოწერეთ საქონელი
3. ჩაწერეთ მოძრაობები
4. წაიკითხეთ რეესტრი და დარწმუნდით, რომ არ არის უარყოფითი ნაშთები. თუ არის, მაშინ ჩამოწერეს ზედმეტი, თუ არა, მაშინ ყველაფერი კარგადაა.

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

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

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

*************************************************************************************************
მონაცემთა დაბლოკვა (დაბლოკვის მეთოდი No1 ზემოთ აღწერილობიდან)

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

ეს დაახლოებით ასე გამოიყურება:

Lock = NewDataLock; Locking Element = Locking.Add("Accumulation Register.GoodsInWarehouses"); LockElement.Mode = DataLockMode.Exclusive; BlockingElement.DataSource = PM; Locking Element.UseFromDataSource("ნომენკლატურა", "ნომენკლატურა"); Lock.Lock();

*************************************************************************************************
უმჯობესია დოკუმენტების ცხრილის ნაწილს უწოდოთ უბრალოდ "TC"

დოკუმენტების 99%-ში მხოლოდ ერთი ცხრილის ნაწილია. ცხრილის ნაწილების ასეთი ერთიანი სახელწოდება მნიშვნელოვნად შეუწყობს ხელს დროის დაზოგვას, რადგან:
1) ძალიან მოკლე - დაწერეთ სწრაფად
2) ყველა დოკუმენტისთვის იგივეა, კოდის დაწერისას არ უნდა გახსოვდეთ რა ჰქვია მას

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

ზოგადად, ყველა დავალებაზე ვიყენებდი შერჩევას.

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

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

შედეგი = Query.Run(); If Not Result.Empty() შემდეგ Select = Result.Select(TravelQueryResult.ByGrouping); ... Დაასრულე თუ;

და იმ შემთხვევაში, თუ ჩვენ გვჭირდება მხოლოდ ერთი მნიშვნელობის მიღება მოთხოვნიდან
(მაგალითად, მხოლოდ ჩამოწერის მეთოდი ამ წლისთვის დადგენილი სააღრიცხვო პოლიტიკის შესაბამისად):

შედეგი = Query.Run(); If Not Result.Empty() შემდეგ Select = Result.Select(); Selection.Next(); Cost Write-off Method = Sample.Cost Write-Off Method; დაასრულე თუ;

*************************************************************************************************
დოკუმენტი "ოპერაცია" ბუღალტრული ამოცანისთვის

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

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

*************************************************************************************************
დოკუმენტების სწრაფი დამუშავება:

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

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

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

*************************************************************************************************
მოთხოვნის პირობა ფორმის "ან მითითებული ნომენკლატურა ან ნებისმიერი, თუ არ არის მითითებული"

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

ნომენკლატურა = &ნომენკლატურა ან &ნომენკლატურა = მნიშვნელობა (Directory.Nomenclature.EmptyLink)

მაგრამ უფრო ოპტიმალური და სწორი იქნებოდა ამ მდგომარეობის გარდაქმნა (მადლობა yukon):

Request.Text = Request.Text + "WHERE Nomenclature = &Nomenclature";

დაასრულე თუ;

8.3.5-ში მოთხოვნის ობიექტის მოდელის გამოჩენით, შესაძლებელი იქნება მდგომარეობის უფრო უსაფრთხოდ დამატება:

თუ ValueFilled (ნომენკლატურა) მაშინ
Query1.Selection.Add("Item = &Nomenclature");
Request.SetParameter("ნომენკლატურა", ნომენკლატურა);
დაასრულე თუ;

*************************************************************************************************
ცხრილების შეერთება შეკითხვებში:

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

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

*************************************************************************************************
მახასიათებლების ტიპების გეგმის გამოყენება (PVC):

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

1.1. ჩვენ ვქმნით PVC-ს. ეს იქნება მახასიათებლების ტიპები (მაგალითად, ფერი, ზომა, მაქსიმალური სიჩქარე და ა.შ.). პარამეტრებში აირჩიეთ ყველა შესაძლო ტიპის დამახასიათებელი მნიშვნელობები და, საჭიროების შემთხვევაში, შექმენით ობიექტი 1.2 წერტილიდან და ასევე მიუთითეთ იგი პარამეტრებში.

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

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

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

2. PVC-ის გამოყენება ბუღალტრული აღრიცხვის რეესტრის ქვეკონტო მექანიზმის შესაქმნელად .

2.1. ჩვენ ვქმნით PVC TypesSubconto-ს.

2.2. ჩვენ ვქმნით დაქვემდებარებულ დირექტორიას ValuesSubConto (ისევე როგორც მახასიათებლებს, ის შეიცავს ქვეკონტოს მნიშვნელობებს, თუ ასეთი არ არის სხვა დირექტორიაში).

2.3. კომუნიკაცია ხდება ანგარიშთა სქემის გამოყენებით.

*************************************************************************************************
ბუღალტრული აღრიცხვის რესურსები:

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

*************************************************************************************************
ვირტუალური აღრიცხვის რეესტრის ცხრილები:

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

*************************************************************************************************
სავალუტო აღრიცხვა სააღრიცხვო რეესტრებზე - როგორ განვახორციელოთ:

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

ამრიგად, რეესტრის სტრუქტურა არის:

გაზომვები:
- ვალუტა
რესურსები
- რაოდენობა
- თანხა (თანხა რუბლებში)
- CurrencyAmount (თანხა ვალუტაში)

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

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

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

*************************************************************************************************
რესურსის მნიშვნელობა და დეტალები საანგარიშო რეესტრში

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

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

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

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

StartDate of CurrentMonth = Start of Month(TexLineMainAccruals.ActionPeriodStart); CurrentMonthEndDate = EndMonth(TexLineMainAccruals.ActionPeriodStart); CurrentMonth = თარიღი; სანამDateStartCurrentMonth<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;

*************************************************************************************************
განტის დიაგრამის აგება:

ჩვენ ვათავსებთ "Gantt Chart" ტიპის ელემენტს ფორმაზე, ვუწოდებთ მას DG, შემდეგ ვქმნით ბრძანებას "Generate" და ვწერთ შემდეგს ფორმის მოდულში:

&OnClient პროცედურა Generate(Command) GenerateOnServer(); პროცედურის დასასრული &სერვერზე პროცედურა GenerateOn Server() DG.Clear(); DG.Update = False; მოთხოვნა = New Request("SELECT |BasicAccrualsActualActionPeriod.Employee, |BasicAccrualsActualActionPeriod.CalculationType, |BasicAccrualsActualActionPeriod.ActionPeriodStart AS ActionPeriodActionPeriodStart.ActionPeriodStart AS ActionPeriodActionStart. ctionsEnd |FROM |გაანგარიშების რეგისტრაცია.ძირითადი დარიცხვები.ფაქტობრივი პერიოდიქმედებები AS ძირითადი დარიცხვებიფაქტობრივი პერიოდიქმედებები |WHERE |ძირითადი დარიცხვებიფაქტობრივი პერიოდიქმედებები.პერიოდიქმედებები BETWEEN &დაწყების თარიღს შორის AND &EndDate"); Query.SetParameter ("StartDate", Period.StartDate); Request.SetParameter("EndDate", Period.EndDate); Select = Query.Run().Select(); ხოლო Selection.Next() Loop Point = DG.SetPoint(Selection.Employee); სერია = DG.SetSeries(Selection.CalculationType); მნიშვნელობა = DG.GetValue(პუნქტი, სერია); ინტერვალი = Value.Add(); Interval.Start = Sample.PeriodActionStart; Interval.End = Sample.ActionPeriodEnd; საბოლოო ციკლი; DG.Update = True; პროცედურის დასასრული

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

*************************************************************************************************
"შებრუნებული" ჩანაწერების დამუშავება გამოთვლის ამოცანებში:

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

Addition Records = Movements.MainAccruals.GetAddition(); // არ არის საჭირო მოძრაობების ჩაწერა დამატების მისაღებად

თითოეული ტექნიკური ხაზისთვის ჩანაწერების დამატებების ციკლიდან
ჩანაწერი = Movements.MainAccruals.Add();
FillPropertyValues (ჩანაწერი, TechString);
Record.RegistrationPeriod = TechString.RegistrationPeriodReversal;
Record.ActionPeriodStart = TechString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = TechString.ActionPeriodEndReversal;
ციკლის დასასრული

და ჩანაწერების გაანგარიშებისას ჩადეთ ჩეკები:

თუ TechMotion.შებრუნება მაშინ
CurrentMovement.Sum = - CurrentMovement.Amount;
დაასრულე თუ;

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

მაგრამ ეს ყოველთვის არ არის 100% ნათელი; არის უფრო რთული შემთხვევებიც, თუმცა საკმაოდ ბევრია.
(მაგალითად, ბონუსი, რომელიც დამოკიდებულია სამუშაო დღეების რაოდენობაზე თვეში - ეს არის HE).

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

მაგალითი OH:
- ხელფასი
- რაღაც, რაც გამოითვლება სამუშაო დღეების რაოდენობის მიხედვით (და ამისათვის საჭიროა გრაფიკის გამოყენება): ან მოქმედების პერიოდში (როგორიცაა ხელფასი) ან საბაზისო პერიოდში

დამატებითი გადასახადები:
რა ითვლება ან დარიცხული თანხიდან, ან მუშაობის დრო (და არა ნორმა!), ან საერთოდ არ არის დამოკიდებული - ეს არის დამატებითი. დარიცხვები.

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

ან სხვა სიტყვებით რომ ვთქვათ:

თუ VR იყენებს დროის სტანდარტს, მაშინ მოქმედების პერიოდი უნდა იყოს ჩართული VR-სთვის.

*************************************************************************************************
დაამატეთ ჩაშენებული დახმარების განყოფილების "საცნობარო წიგნებთან მუშაობა" გახსნის შესაძლებლობა "ნომენკლატურის" დირექტორიაში სიაში.

გაუშვით ბრძანება ფორმაზე:

&OnClient
პროცედურის დახმარება (ბრძანება)
OpenHelp ("v8help://1cv8/EnterprWorkingWithCatalogs");
პროცედურის დასასრული

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

*************************************************************************************************
ფორმებს შორის ურთიერთქმედების განხორციელება, მაგალითად, შერჩევა:

1. მიმდინარე ფორმიდან გახსენით სასურველი “OpenForm()” მეთოდით, სტრუქტურის გადასვით პარამეტრები მეორე პარამეტრად (საჭიროების შემთხვევაში). მესამე პარამეტრს შეუძლია გადასცეს ბმული ამ ფორმაზე - ThisForm.

2. გახსნილ ფორმაში, “When CreatedOnServer()” დამმუშავებელში შეგვიძლია დავაფიქსიროთ 1-ელ საფეხურზე გადაცემული პარამეტრები “Parameters.[ParameterName]-ის მეშვეობით”. ფორმა, რომელიც ამ ფორმის გახსნის ინიციატორი გახდა, ხელმისაწვდომი იქნება „მფლობელის“ იდენტიფიკატორის მეშვეობით (თუ ეს, რა თქმა უნდა, მითითებული იყო 1-ლ საფეხურში).

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

*************************************************************************************************
ფორმის პარამეტრების სასიცოცხლო ციკლი

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

*************************************************************************************************
ტაქსის ინტერფეისის გამოყენებით

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

*************************************************************************************************

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

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