1c վիրտուալ սեղանի մնացորդներ և շրջանառություն: Հարցման խմբաքանակի ներդիր

Ես որոշեցի իմ ներդրումն ունենալ և նկարագրել լեզվի այն առանձնահատկությունները, որոնք չեն քննարկվել վերը նշված հոդվածներում։ Հոդվածն ուղղված է սկսնակ ծրագրավորողներին:

1. «IZ» դիզայն.

Տվյալների բազայից տվյալներ ստանալու համար ամենևին էլ անհրաժեշտ չէ օգտագործել «FROM» կոնստրուկցիան։
Օրինակ. Մենք պետք է ընտրենք բանկերի մասին բոլոր տեղեկությունները բանկերի գրացուցակից:
Հայց.

SELECT Directory.Banks.*

Բանկերի գրացուցակից ընտրում է բոլոր դաշտերը: Եվ նման է խնդրանքին.

SELECT Banks.* FROM Directory.Banks AS Banks

2. Տվյալների պատվիրում ըստ հղման դաշտի

Երբ մեզ անհրաժեշտ է հարցման տվյալները կազմակերպել ըստ պարզունակ տեսակների՝ «String», «Number», «Date» և այլն, ապա ամեն ինչ լուծվում է «ORDER BY» կառուցվածքի միջոցով, եթե անհրաժեշտ է տվյալները պատվիրել հղումային դաշտով: Հղման դաշտը հղում է, եզակի նույնացուցիչ, այսինքն. Կոպիտ ասած՝ նիշերի որոշ կամայական շարք և սովորական պատվերներ կարող են հանգեցնել ոչ ամբողջությամբ սպասելի արդյունքի: Հղման դաշտերը պատվիրելու համար օգտագործվում է «AUTO ORDER» կոնստրուկցիան: Դա անելու համար նախ պետք է տվյալներն ուղղակիորեն պատվիրել ըստ հղման տեսակի՝ օգտագործելով «ORDER BY» կառուցվածքը, այնուհետև «AUTO ORDER» կառուցվածքը:

Այս դեպքում փաստաթղթերի համար պատվերը կկատարվի «Ամսաթիվ->Համար» կարգով, տեղեկատուների համար՝ «Հիմնական տեսքում»: Եթե ​​պատվերը չի կատարվում հղման դաշտերով, ապա խորհուրդ չի տրվում օգտագործել «AUTO ORDER» կոնստրուկցիան:

Որոշ դեպքերում «AUTO ORDER» կառուցվածքը կարող է դանդաղեցնել ընտրության գործընթացը: Նմանապես, դուք կարող եք վերաշարադրել առանց փաստաթղթերի ավտոմատ պատվիրման.

3. Հղման տեսակի տեքստային ներկայացում ստանալը: «ՇՆՈՐՀԱՆԴԵՍ» դիզայն.

Երբ ձեզ անհրաժեշտ է ցուցադրել հղման տիպի դաշտ, օրինակ՝ «Բանկ» դաշտը, որը հղում է «Բանկեր» գրացուցակի տարրի, դուք պետք է հասկանաք, որ այս դաշտը ցուցադրելիս «Բանկ» դաշտը « Banks» գրացուցակը ավտոմատ կերպով կկատարվի գրացուցակի տեսք ստանալու համար: Սա կդանդաղեցնի տվյալների ելքը: Սրանից խուսափելու համար անհրաժեշտ է հարցումում օգտագործել «ՆԵՐԿԱՅԱՑՆՈՒՄ» կոնստրուկցիան, որպեսզի անմիջապես ստանաք օբյեկտի ներկայացում, այնուհետև ցուցադրեք այն դիտելու համար:

Տվյալների կազմման համակարգում այս մեխանիզմը օգտագործվում է լռելյայն, բայց բջիջներում դասավորություններ ստեղծելիս պետք է նշեք հղման դաշտի ներկայացումը և, օրինակ, հղումն ինքնին տեղադրեք տառադարձության մեջ:

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.Amount of Document) AS Sum of Document FROM Document.Provision of Services AS Ծառայությունների մատուցում GROUP BY Ծառայությունների մատուցում. Ծառայությունների.Անվանակատուրա ԱՐԴՅՈՒՆՔՆԵՐԸ ԸՍՏ ԸՆԴՀԱՆՈՒՐ, Կազմակերպություն, Անվանական կլատուրա

Այս դեպքում հարցումը կվերադարձնի գրեթե նույնը, ինչ հետևյալ հարցումը.

SELECT Provision of Services.Organization AS Organization, Provision of Services.Nomenclature AS Nomenclature, Provision of Services.Amount of Document AS Amount of Document FROM Document.Provision of Services AS Provision of Services RESULTS AMOUNT (Amount of Document) BY GENERALER. Անվանակարգ

Միայն առաջին հարցումը կփլուզի նույն անվանակարգով գրառումները:

6. Դաշտերի անջատում:

Կետի միջոցով դաշտերին հղում անելը կոչվում է հղման դաշտի անջատման գործողություն: Օրինակ Վճարում.Կազմակերպություն.Վարչական միավոր. Տվյալ դեպքում «Վճարում» փաստաթղթի «Կազմակերպություն» հղման դաշտում այն ​​վերաբերում է մեկ այլ «Կազմակերպություններ» աղյուսակին, որում կստացվի «Վարչական միավոր» հատկանիշի արժեքը։ Կարևոր է հասկանալ, որ կետի միջոցով դաշտեր մուտք գործելիս հարթակը անուղղակիորեն ստեղծում է ենթահարկ և միանում այս աղյուսակներին:

Հայց.

Կարող է ներկայացվել որպես.

SELECT Payment.Link, Payment.Organization, Payment.Organization, Organizations: AdministrativeUnit FROM Document.Payment AS Payment LEFT JOIN Directory.Organizations AS Software Organizations Payment.Organization = Organizations.Link

Կոմպոզիտային տիպի հղման դաշտերը հեռացնելիս, շրջանակը փորձում է ստեղծել անուղղակի միացումներ բոլոր աղյուսակներին, որոնք այդ դաշտի տիպի մաս են կազմում: Այս դեպքում հարցումը օպտիմալ չի լինի, եթե հստակ հայտնի է, թե դա ինչ տեսակի դաշտ է, ապա անհրաժեշտ է սահմանափակել այդպիսի դաշտերը ըստ տեսակի կոնստրուկտով. ԷՔՍՊՐԵՍ().

Օրինակ, կա կուտակային ռեգիստր «Չբաշխված վճարումներ», որտեղ մի քանի փաստաթղթեր կարող են հանդես գալ որպես գրանցող: Այս դեպքում սխալ է գրանցողի մանրամասների արժեքները ստանալ հետևյալ կերպ.

SELECT UnallocatedPayments.Register.Date, ..... FROM RegisterAccumulation.UnallocatedPayments AS UnallocatedPayments

դուք պետք է սահմանափակեք կոմպոզիտային դաշտի տեսակը լոգերի համար.

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

7. Շինարարություն «WHERE».

Երկու աղյուսակների ձախ միացմամբ, երբ աջ սեղանի վրա դնում եք «WHERE» պայմանը, մենք կստանանք արդյունքի նման արդյունք՝ աղյուսակների ներքին միացումով:

Օրինակ. Անհրաժեշտ է Հաճախորդների տեղեկատուից ընտրել բոլոր Հաճախորդներին, իսկ այն հաճախորդների համար, ովքեր ունեն «Կազմակերպություն» = &կազմակերպություն հատկանիշի արժեքով վճարային փաստաթուղթ, ցուցադրել «Վճարում» փաստաթուղթը, իսկ չունեցողների համար՝ չցուցադրել այն։

Հարցման արդյունքը կվերադարձնի գրառումներ միայն այն հաճախորդների համար, ովքեր պարամետրում ունեին վճարումներ կազմակերպության կողմից և կզտվեն այլ հաճախորդներ: Հետևաբար, դուք պետք է նախ ստանաք բոլոր վճարումները «այսինչ» կազմակերպության համար ժամանակավոր աղյուսակում, այնուհետև այն միացնեք «Հաճախորդներ» գրացուցակին՝ օգտագործելով ձախ միացում:

SELECT 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 Հաճախորդներ ԼԵՖՏ ՄԻԱՑՈՒՄԸ toppayments AS toppayments SOFTWARE Clients.Link = topayments.Client

Այս պայմանը կարող եք շրջանցել այլ կերպ: Անհրաժեշտ է ուղղակիորեն երկու աղյուսակների փոխհարաբերությունների վրա դնել «ՈՐՏԵՂ» պայման: Օրինակ:

SELECT Clients.Link, Payment.Link FROM Directory.US_Subscribers AS US_Subscribers LEFT CONNECTION Document.Payment AS Payment Software (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 NestedQueryIN LEFUCESSAlocated. yments BY Nested Request.Link = UnallocatedPaymentsBalances: Հաճախորդ

Նման հարցում կատարելիս DBMS օպտիմիզատորը պլան ընտրելիս կարող է սխալներ թույլ տալ, ինչը կհանգեցնի հարցման ոչ օպտիմալ կատարմանը: Երկու աղյուսակներ միացնելիս DBMS օպտիմիզատորը ընտրում է աղյուսակների միացման ալգորիթմ՝ հիմնվելով երկու աղյուսակների գրառումների քանակի վրա: Եթե ​​կա nested հարցում, ապա չափազանց դժվար է որոշել այն գրառումների քանակը, որոնք կվերադարձնի ներդրված հարցումը: Հետևաբար, դուք միշտ պետք է օգտագործեք ժամանակավոր աղյուսակներ՝ տեղադրված հարցումների փոխարեն: Այսպիսով, եկեք վերաշարադրենք խնդրանքը:

SELECT Clients.Link AS Link PLACE tClients FROM Directory.Clients AS Clients WHERE
Clients.Link B (&Clients) ; //////////////////////////////////////////// ////////////////////////// SELECT tClients.Link, UnallocatedPaymentsRemains.AmountRemaining, FROM tClients AS tClients LEFT MJOIN RegisterAcumulations.UnallocatedPayments.Balances IN (SELECT tClients.Link FROM tClients)) AS UnallocatedPaymentsBalances tClients.Link = UnallocatedPaymentsBalances.Clients

Այս դեպքում, օպտիմիզատորը կկարողանա որոշել, թե քանի գրառում է օգտագործում tClients-ի ժամանակավոր աղյուսակը և կկարողանա ընտրել աղյուսակների միացման օպտիմալ ալգորիթմը:

Վիրտուալ սեղաններ , թույլ է տալիս գործնականում պատրաստի տվյալներ ստանալ կիրառվող առաջադրանքների մեծ մասի համար (Առաջինի հատված, Վերջինի հատված, Մնացել է, Շրջանառություններ, Մնացորդներ և Շրջանառություններ) Այստեղ հիմնական բառը վիրտուալ է: Այս աղյուսակները ֆիզիկական չեն, այլ կազմվում են համակարգի կողմից թռիչքի ժամանակ, այսինքն. Վիրտուալ աղյուսակներից տվյալներ ստանալիս համակարգը հավաքում է տվյալներ վերջնական ռեգիստրի աղյուսակներից, հավաքում, խմբավորում և տրամադրում օգտագործողին:

Նրանք. Վիրտուալ աղյուսակին միանալիս կապ է կատարվում ենթհարցման հետ: Այս դեպքում DBMS օպտիմիզատորը կարող է նաև ընտրել կապի ոչ օպտիմալ պլան: Եթե ​​հարցումը բավականաչափ արագ չի ստեղծվում, և հարցումն օգտագործում է միացումներ վիրտուալ աղյուսակներում, ապա խորհուրդ է տրվում վիրտուալ աղյուսակների մուտքը տեղափոխել ժամանակավոր աղյուսակ, այնուհետև կատարել երկու ժամանակավոր աղյուսակների միացում: Վերաշարադրենք նախորդ խնդրանքը.

SELECT Clients.Link AS Link PLACE tClients FROM Directory.Clients AS Clients INDEX BY Link WHERE
Clients.Link B (&Clients) ; //////////////////////////////////////////// ////////////////////////// SELECT UnallocatedPayments.AmountBalance, UnallocatedPayments.Client AS Client PLACE balances FROM RegisterAccumulations.UnallocatedPayments.Balances(, Հաճախորդ B ( Ընտրեք tClients Հղում tClients-ից)) AS UnallocatedPaymentsBalances; //////////////////////////////////////////// ////////////////////////// SELECT tClients.Link, toRemainders.AmountRemaining AS AmountRemaining FROM tClients AS tClients LEFT JOIN toRemainders AS Remainders BY tnkC = tRemainings.Client

9. Հարցման արդյունքի ստուգում.

Հարցման արդյունքը կարող է դատարկ լինել, դատարկ արժեքներ ստուգելու համար օգտագործեք հետևյալ կառուցվածքը.

ResRequest = Request.Execute(); Եթե ​​resQuery.Empty() Ապա Վերադարձեք; վերջԵթե;

Մեթոդ Դատարկ ()պետք է օգտագործվի մեթոդներից առաջ Ընտրել ()կամ Բեռնաթափել (), քանի որ հավաքածուն ետ բերելը ժամանակ է պահանջում։

Որևէ մեկի համար բացահայտում չէ, որ հարցումները մի օղակում օգտագործելը չափազանց անցանկալի է: Սա կարող է խիստ ազդել որոշակի ֆունկցիայի գործառնական ժամանակի վրա: Շատ ցանկալի է ստանալ հարցումի բոլոր տվյալները, իսկ հետո դրանք մշակել օղակաձև: Բայց երբեմն լինում են դեպքեր, երբ հարցումը օղակից դուրս տեղափոխելը դառնում է անհնար։ Այս դեպքում օպտիմալացման համար կարող եք հարցման ստեղծումը տեղափոխել օղակից դուրս, իսկ օղակում փոխարինել անհրաժեշտ պարամետրերը և կատարել հարցումը։

Request = Նոր հարցում; Query.Text = "SELECT | Clients.Link, | Clients.Birthdate |FROM | Directory.Clients AS Clients |WHERE | Clients.Link = &Client"; Յուրաքանչյուր տողի համար՝ FROM TableClients Loop Query.SetParameter("Client", Client); QueryResult = Query.Execute().Select(); End Cycle;

Սա կփրկի համակարգը շարահյուսական հարցումը հանգույցով ստուգելուց:

11. Շինարարություն «ՈՒՆԵՑՈՂ».

Դիզայն, որը բավականին հազվադեպ է խնդրանքների մեջ: Թույլ է տալիս պայմաններ սահմանել ագրեգատ ֆունկցիաների արժեքների վրա (գումար, Նվազագույն, միջին և այլն): Օրինակ, դուք պետք է ընտրեք միայն այն հաճախորդներին, որոնց վճարման գումարը սեպտեմբերին կազմել է ավելի քան 13,000 ռուբլի: Եթե ​​դուք օգտագործում եք «WHERE» պայմանը, նախ պետք է ստեղծեք ժամանակավոր աղյուսակ կամ ներդիր հարցում, խմբավորեք այնտեղ գրառումները ըստ վճարման գումարի և այնուհետև կիրառեք պայմանը: «HAVING» կոնստրուկցիան կօգնի խուսափել դրանից:

SELECT 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-ը ճիշտ կամ կեղծ չէ, անհայտ է:

Դիտարկենք մի օրինակ։

Այն հաճախորդների համար, ովքեր չունեն վճարումներ, մենք պետք է ցուցադրենք «Ստորագրել» դաշտը «Ոչ վճարումներ» արժեքով: Ավելին, մենք հաստատ գիտենք, որ ունենք նման հաճախորդներ։ Եվ որպեսզի արտացոլենք վերևում գրածիս էությունը, եկեք դա անենք այսպես.

Ընտրեք «Ոչ վճարումներ» AS Attribute, NULL AS Document PLACE toppayments; //////////////////////////////////////////// ///////////////////////// SELECT Clients.Link AS Client, Payment.Link HOW Payment PUT tClientPayment FROM Directory.Clients AS Clients LEFT CONNECTION Document. Payment AS Payment Software Clients.Link = Payment.Shareholder; //////////////////////////////////////////// ////////////////////////// ԸՆՏՐԵԼ tClientPayment.Client-ից tClientPayment AS tClientPayment ՆԵՐՔԻՆ ՄԻԱՑԵԼ tPayment AS tՎճարել TClientPayment-ով:Վճարում = tPayment:

Ուշադրություն դարձրեք tClientPayment երկրորդ ժամանակավոր աղյուսակին: Ձախ միանալով ես ընտրում եմ բոլոր հաճախորդներին և բոլոր վճարումները այս հաճախորդների համար: Այն հաճախորդների համար, ովքեր չունեն վճարումներ, «Վճարում» դաշտը կլինի NULL: Հետևելով տրամաբանությանը, առաջին ժամանակավոր աղյուսակում «tPayments» ես նշել եմ 2 դաշտ, որոնցից մեկը NULL, երկրորդ տողը «Չունի վճարումներ»: Երրորդ աղյուսակում ես կապում եմ «tClientPayment» և «tPayment» աղյուսակները՝ օգտագործելով «Վճարում» և «Փաստաթուղթ» դաշտերը ներքին միացումով: Մենք գիտենք, որ առաջին աղյուսակում «Փաստաթուղթ» դաշտը 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)) ԻՆՉՊԵՍ Վճարում PUT tClientPayment FROM Directory-ից.Հաճախորդներ ՈՐՊԵՍ Հաճախորդներ ՁԱԽ ՄԻԱՑՈՒՄ Փաստաթուղթ.Վճարում ՈՐՊԵՍ Վճարում Հաճախորդների ԿՈՂՄԻՑ.Հղում = Վճարում.Բաժնետիրոջ; //////////////////////////////////////////// ////////////////////////// ԸՆՏՐԵԼ tClientPayment.Client-ից tClientPayment AS tClientPayment ՆԵՐՔԻՆ ՄԻԱՑԵԼ tPayment AS tՎճարել TClientPayment-ով:Վճարում = tPayment:

Այժմ, երկրորդ ժամանակավոր աղյուսակում մենք նշել ենք, որ եթե «Վճարում» դաշտը NULL է, ապա այս դաշտը = դատարկ հղում դեպի վճարային փաստաթուղթ: Առաջին աղյուսակում մենք նաև փոխարինեցինք NULL-ը դատարկ հղումով: Այժմ կապը ներառում է ոչ NULL դաշտեր, և հարցումը կվերադարձնի ակնկալվող արդյունքը:

Հոդվածում պարունակվող բոլոր հարցումները արտացոլում են այն իրավիճակները, որոնք ես կցանկանայի դիտարկել և ոչ ավելին: ՄԱՍԻՆ Նրանք չեն կարող լինել զառանցական կամ ոչ օպտիմալ, գլխավորն այն է, որ արտացոլում են օրինակի էությունը:

13. «ԸՆՏՐԵՔ, ԵՐԲ... ԱՊԱ...ՎԵՐՋ» դիզայնի չփաստաթղթավորված հատկանիշը:

Այն դեպքում, երբ անհրաժեշտ է հայտում նկարագրել «Պայմաններ» կառուցվածքը, մենք օգտագործում ենք ստանդարտ շարահյուսությունը.

SELECT SELECTION WHEN Users.Name = "Vasya Pupkin" THEN "Մեր սիրելի աշխատակիցը" ELSE "Մենք չգիտենք սա" END AS Field1 FROM Directory.Users AS Users

Բայց ի՞նչ, եթե, օրինակ, խնդրանքով պետք է ստանանք ամսվա անունը: Հարցման մեջ հսկայական կոնստրուկցիա գրելը տգեղ է և ժամանակատար, ուստի վերևում գրելու այս ձևը կարող է օգնել մեզ.

SELECT MONTH(US_CalculationConsumption_ScheduleTurnover.CalculationPeriod) WHEN 1, ապա «հունվար», WHEN 2, ապա «փետրվար» WHEN 3, ապա «մարտ» WHEN 4, ապա «ապրիլ», ԵՐԲ 5, ԱՊՀ «Մայիս» THE7NH ԵՐԲ 8 ՀԵՏԵ «Օգոստոս» ԵՐԲ 9 ՀԵՏՈ «Սեպտեմբեր» ԵՐԲ 10 ՀԵՏՈ «Հոկտեմբեր» ԵՐԲ 11 ՀԵՏԵ «Նոյեմբեր» ԵՐԲ 12 ՀԵՏՈ «Դեկտեմբեր» ԱՎԱՐՏՎՈՒՄ Է ՈՐՊԵՍ մեկ ամիս.

Այժմ դիզայնը ավելի քիչ դժվար է թվում և հեշտ է հասկանալ:

14. Հարցման խմբաքանակի կատարում:

Հարցումները չբազմապատկելու համար կարող եք ստեղծել մեկ մեծ հարցում, այն բաժանել փաթեթների և աշխատել դրա հետ։
Օրինակ՝ «Users» գրացուցակից պետք է ստանամ հետևյալ դաշտերը՝ «Ծննդյան ամսաթիվ» և յուրաքանչյուր օգտագործողի համար հասանելի դերերը։ վերբեռնեք սա ձևի տարբեր աղյուսակային մասերում: Իհարկե, դուք կարող եք դա անել մեկ հարցումով, այնուհետև ստիպված կլինեք կրկնել գրառումները կամ փլուզել դրանք, կամ կարող եք անել սա.

SELECT Users.Link AS Ամբողջական անուն, Users.Ծննդյան ամսաթիվ, Users.Role PUT vtUsers FROM Directory.Users AS Users; //////////////////////////////////////////// ////////////////////////// SELECT tueUsers.Լրիվ անուն, tueUsers.Ծննդյան ամսաթիվ tueUsers AS tueUsers GROUP BY tueUsers.լրիվ անունը, tueUsers . Ծննդյան ամսաթիվ; //////////////////////////////////////////// ////////////////////////// SELECT wUsers.Լրիվ անունը, wUsers.Դերը FROM օգտվողներից AS wUsers GROUP BY WUsers.Լրիվ անուն, wUsers. Ամսաթիվ Ծննդյան

tPackage = Request.ExecutePackage();

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

Ինչպես տեսնում ենք, հարցումը կարող է կատարվել խմբաքանակով, և արդյունքը կարող է մշակվել որպես զանգված: Որոշ դեպքերում դա շատ հարմար է։

15. Պայմանները խմբաքանակի հարցումով

Օրինակ, մենք ունենք խմբաքանակի հարցում, որտեղ սկզբում ստանում ենք «Անուն, ծննդյան ամսաթիվ, ծածկագիր» դաշտերը «Users» գրացուցակից և ցանկանում ենք այս դաշտերի պայմաններով գրառումներ ստանալ «Individuals» գրացուցակից:

SELECT Users.Individual.Name AS անուն, Users.Individual.Ծննդյան ամսաթիվ AS ծննդյան ամսաթիվ, Users.Individual.Code AS Code PLACE vtUsers FROM Directory.Users AS Users; //////////////////////////////////////////// ////////////////////////// ԸՆՏՐԵՔ Անհատներ: Հղում AS Individual FROM տեղեկատուից: Անհատներ AS Individuals

Դուք կարող եք պարտադրել հետևյալ պայմանները.

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 FROM tv)

Եվ դուք կարող եք դա անել այսպես.

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 կետում և օգտագործելով վիրտուալ աղյուսակի պարամետրերը: Երկու մեթոդներն էլ կհանգեցնեն նույն արդյունքի (բացառությամբ որոշ կոնկրետ դեպքերի), բայց, այնուամենայնիվ, դրանք հեռու են համարժեք լինելուց։

Մենք արդեն գիտենք, որ վիրտուալ աղյուսակները կոչվում են վիրտուալ, քանի որ դրանք իրականում տվյալների բազայում չեն: Դրանք ձևավորվում են միայն այն պահին, երբ նրանց հարցում է արվում։ Չնայած սրան՝ մեզ (այսինքն՝ հարցում գրողներին) հարմար է վիրտուալ աղյուսակները իրական համարել։ Ի՞նչ տեղի կունենա 1C Enterprise 8 համակարգում, երբ մեր կազմած հարցումը դեռ մուտք գործի վիրտուալ աղյուսակ:

Առաջին քայլում համակարգը կկառուցի վիրտուալ աղյուսակ: Երկրորդ քայլում ստացված աղյուսակից կընտրվեն գրառումները, որոնք բավարարում են WHERE կետում նշված պայմանը.


Հստակ երևում է, որ վերջնական նմուշը չի ներառի վիրտուալ աղյուսակից (և հետևաբար, տվյալների բազայից) բոլոր գրառումները, այլ միայն նրանք, որոնք բավարարում են տվյալ պայմանը։ Իսկ մնացած ռեկորդները պարզապես կբացառվեն արդյունքից։

Այսպիսով, համակարգը կկատարի ոչ միայն անօգուտ աշխատանք, այլ կրկնակի անօգուտ աշխատանք: Նախ, ռեսուրսները կծախսվեն ավելորդ տվյալների հիման վրա վիրտուալ աղյուսակ կառուցելու վրա (նկարում դրանք նշված են որպես «տվյալների տարածքներ A և B»), այնուհետև աշխատանք կկատարվի այս տվյալները վերջնական արդյունքից զտելու համար:

Հնարավո՞ր է անմիջապես, վիրտուալ աղյուսակի կառուցման փուլում, դադարեցնել ավելորդ տվյալների օգտագործումը: Պարզվում է՝ դա հնարավոր է։ Սա հենց այն է, ինչի համար նախատեսված են վիրտուալ աղյուսակի պարամետրերը.


Պարամետրավորելով վիրտուալ աղյուսակը՝ մենք անմիջապես սահմանափակում ենք տվյալների քանակը, որոնք կմշակվեն հարցման կողմից:

Ո՞րն է տարբերությունը «Ավելացման մեթոդ» վիրտուալ աղյուսակի պարամետրի արժեքների միջև:
Երբ ավելացման մեթոդը դրված է «շարժումներ», ապա կվերադարձվեն միայն այն ժամանակահատվածները, որոնցում եղել են շարժումներ: Երբ սահմանվում է «Շարժումներ և ժամանակաշրջանի սահմաններ», ապա վերը նշված շարժումներին կավելացվի 2 գրառում՝ շարժումներ VT պարամետրերում նշված ժամանակահատվածի սկզբում և վերջում: «Գրանցող» դաշտը դատարկ կլինի այս 2 գրառումների համար:

Եկեք կանչենք PriceSliceLast վիրտուալ աղյուսակի պարամետրերի մուտքագրման երկխոսությունը և նշենք, որ ժամկետը կփոխանցվի ReportDate պարամետրում: Դա անելու համար ընտրեք այս աղյուսակը «Սեղաններ» ցանկում և սեղմեք «Վիրտուալ աղյուսակի ընտրանքներ» կոճակը: Այնուհետև աղյուսակներից ընտրեք հետևյալ դաշտերը.

SprNomenclature. Ծնող,

ԳներՆերջին հատվածը.Գին.

Ձախ սեղանի միացում

- Էջանիշի վրա ՄիացումներՀղման պայման դաշտում, որ տեղեկատվական ռեգիստրի Nomenclature չափման արժեքը պետք է հավասար լինի Nomenclature գրացուցակի տարրին հղումին: Եվ նաև հանեք գրանցման աղյուսակի բոլոր վանդակը և ստուգեք այն որոնման աղյուսակի համար, դրանով իսկ կապի տեսակը սահմանելով որպես ձախ կապ որոնման աղյուսակի համար.

Բրինձ. 13.15. Աղյուսակների միջև կապը հարցման մեջ

- Էջանիշի վրա Պայմաններեկեք պայման դնենք Nomenclature գրացուցակից տարրեր ընտրելու համար. ընտրված տարրերը պետք է համապատասխանեն անվանացանկի տեսակին, որը փոխանցվել է Nomenclature Type request պարամետրում.

Բրինձ. 13.16. Տարրերի ընտրության պայմանները

- Էջանիշի վրա Միություններ/Անանուններ.նշեք Ծնող = Ծառայության Խումբ դաշտի կեղծանունը և Հղում = Ծառայություն դաշտը: - Սեղմեք OK–

Դրանից հետո դուք պետք է խմբագրեք տվյալների դասավորության սխեման, դա անելու համար ներդիրում Ռեսուրսներ, սեղմեք կոճակի վրա ավելացնելև ընտրել ռեսուրս - Գին

- Էջանիշի վրա Ընտրանքներսահմանել Nomenclature Type պարամետրի արժեքը՝ Enumeration.Nomenclature Types.Service: Բացի այդ, մենք կհեռացնենք ReportDate պարամետրի հասանելիության սահմանափակումը: Այս պարամետրի տեսակ դաշտում սահմանեք ամսաթվի կազմը՝ Ամսաթիվ: «Ժամանակաշրջան» պարամետրի համար, ընդհակառակը, մենք սահմանել ենք հասանելիության սահմանափակում.

Բրինձ. 13.17. Դասավորության սխեմայի ընտրանքներ

Կարգավորումներ

- Եկեք գնանք էջանիշին Կարգավորումներ:Եկեք ստեղծենք խմբավորում՝ հիմնվելով Service Group դաշտի վրա՝ նշելով խմբավորման տեսակը Hierarchy:

Հաշվետվությունների խմբավորման համար գոյություն ունեն հիերարխիայի հետևյալ տեսակները.Առանց հիերարխիայի - խմբավորման մեջ ցուցադրվում են միայն ոչ հիերարխիկ գրառումներ: Հիերարխիա - ինչպես ոչ հիերարխիկ, այնպես էլ հիերարխիկ գրառումները ցուցադրվում են խմբավորման մեջ: Միայն հիերարխիա - խմբավորման մեջ ցուցադրվում են միայն հիերարխիկ (ծնող) գրառումները: Այս խմբի ներսում մենք կստեղծենք ևս մեկը՝ առանց խմբի դաշտը նշելու։ Ենթաներդիրում Ընտրված դաշտեր.նշեք ելքային դաշտերը Ծառայություն և Գին.

Բրինձ. 13.18. Հաշվետվության կառուցվածքը և դաշտերը

Ենթաներդիրում Այլկարգավորումները մենք կկատարենք հետևյալ քայլերը.

Բրինձ. 13.19. «Ծառայությունների խումբ» խմբավորման ընդհանուր գումարները ցուցադրելու կարգավորումներ

Բրինձ. 13.20. Համաշխարհային հաշվետվության արդյունքների կարգավորում և ցուցադրում

Վերջապես, եկեք ներառենք «Հաղորդման ամսաթիվ» պարամետրը օգտվողի կարգավորումներում և դրա խմբագրման ռեժիմը դնենք «Արագ մուտք»: Եկեք փակենք տվյալների կազմի սխեմայի դիզայները և Ծառայությունների ցանկի օբյեկտը խմբագրելու պատուհանում անցնենք Ենթահամակարգեր ներդիր: Կազմաձևման ենթահամակարգերի ցանկում նշեք Ծառայությունների մատուցման և Հաշվապահական հաշվառման ենթահամակարգերը:

1C-ում՝ Ձեռնարկությունների ռեժիմ

Եկեք գործարկենք 1C:Enterprise-ը վրիպազերծման ռեժիմում և առաջին հերթին բացենք Prices պարբերական ռեգիստրը։ Այնուհետև մենք կփորձարկենք զեկույցը:

Օգտագործելով այս զեկույցը որպես օրինակ, մենք ուսումնասիրեցինք, թե ինչպես է տվյալների կազմի համակարգը ստանում վերջին արժեքները պարբերական տեղեկատվական ռեգիստրից և ինչպես են ցուցադրվում խմբավորումները ըստ գրացուցակի հիերարխիայի:

Եթե ​​իմ հրապարակումը օգտակար է ձեզ համար, մի մոռացեք դրան գումարած տալ :-)

Ահա հավաքածուի բոլոր առաջադրանքների ռուբիկատորը(յուրաքանչյուր առաջադրանքի համար ֆորումի թեմաների հղումներ պարունակող էջ)
http://chistov.spb.ru/forum/16-969-1

Դե, հիմա իմ մշակումներն ու գրառումները, որոնք ստեղծել եմ նախապատրաստման ընթացքում։
Վերը նշված երկուսի հետ կփորձեմ հնարավորինս քիչ կրկնել վերջինհրապարակումներ։

Այսպիսով, եկեք սկսենք.

Եթե ​​հեռակա կարգով վերցնեք, ապա քննության վերջում պետք է ունենաք երկու օբյեկտ ձեր աշխատասեղանին.

1. Տեղեկատվական բազայի վերջնական վերբեռնում (dt ֆայլ)
2. Բացատրական նշում

Ուրիշ բան չպետք է լինի, միջանկյալ պատճեններ և այլն։

Համոզվեք, որ գրեք բացատրական նշում:
Անորոշ ձևակերպված առաջադրանքի դեպքում անպայման այնտեղ գրեք, որ ընտրել եք հենց այսպիսի և այս լուծման տարբերակը։
Նաև օրենսգրքի առանցքային տեղերում ավելի լավ է թողնել կարճ մեկնաբանություններ՝ առանց ֆանատիզմի, բայց որտեղ քննողը կարող է հարցեր ունենալ, ավելի լավ է գրել։

Բայց այս մասին ձեզ կպատմեն ցուցումներում, որոնք ձեզ կտրամադրեն կարդալ քննությունից առաջ։
Պարզապես ավելի լավ է նախապես իմանալ)

Օգտագործելով ամպերսանդ նիշը հարցումներում:

Երբեմն լրացուցիչ ստեղնաշարից մուտքագրելն ավելի արագ է, քան դասավորությունը ետ ու առաջ փոխելը՝ խնայելով ժամանակը
& = Alt+38

*************************************************************************************************
Օգտագործելով TimePoint() հարցումներում

Կուտակման և հաշվառման ռեգիստրների հարցումներում անհրաժեշտ է օգտագործել ոչ թե փաստաթղթի ամսաթիվը որպես վիրտուալ աղյուսակի (ժամկետի) պարամետր, այլ Moment պարամետրը, որը կոդում սահմանված է հետևյալ կերպ.

Moment = ?(Passing Mode = Document Posting Mode. Operational, Undefined, Moment of Time());

*************************************************************************************************
Փաստաթղթերի տեղաշարժերը գրանցամատյանով առաջացնելիս, տեղադրման մշակման ընթացակարգի հենց սկզբում անհրաժեշտ է ռեգիստրով մաքրել ընթացիկ փաստաթղթի շարժումները:

Կոդն է.

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

Հնարավոր է, որ գործընթացի ընթացքում անհրաժեշտ լինի վերլուծել այս ռեգիստրի գրառումները։
Այսպիսով, որպեսզի ընթացիկ գրառումները (հինները, նախքան փաստաթղթի փոփոխությունը) վերլուծելիս դրանք հաստատ չներառվեն նմուշում, կարող եք ևս մեկ տող ավելացնել վերը նշված երկու տողերին.

Movement.RegisterName.Write();

Կամ, գրառումները վերլուծելիս, հստակ նշեք այն սահմանը, որը չի ներառում ընթացիկ փաստաթղթի ժամանակային կետը:

Բայց ամենուր ես պարզապես նշել էի այս երեք տողերի կառուցումը.

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

*************************************************************************************************
Տվյալները արգելափակելու երկու եղանակ կա, դրանց միջև ընտրությունը կախված է օգտագործվող մեթոդից՝ հին կամ նոր.

1) կանոնավոր վերահսկվող արգելափակում, փաստաթղթերի մշակման հին մեթոդ (Տվյալների արգելափակման օբյեկտ)

Սահմանեք, եթե մնացորդները նախ ստուգվեն, ապա դուրս գրվեն:
Այն դեպքում, երբ մենք պետք է ինչ-որ տեղեկություն ունենանք գրանցամատյանից՝ շարժում ձևավորելու համար։

Օրինակ:

Փաստաթղթում` քանակ, գրանցամատյանում` քանակ և գումար (արժեքը)
Այսպիսով, մենք փաստաթղթից գիտենք ապրանքի քանակը՝ որքան ենք դուրս գրում, իսկ արժեքը՝ ոչ։
Մենք դա կարող ենք պարզել միայն գրանցամատյանից, բայց որպեսզի համոզվենք, որ մնացորդների ստացման և շարժումների գրանցման պահի միջև ոչ ոք գրանցամատյանը չփոխի, պետք է կողպենք գրանցամատյանը նույնիսկ մնացորդները կարդալուց առաջ։
Այսպիսով, այս դեպքում օգտագործվում է Data Locking օբյեկտը: Եվ այն ստեղծելիս ավելի ճիշտ է նշել, թե ինչ չափերով ենք արգելափակում գրանցամատյանը (օրինակ, մեր դեպքում՝ միայն փաստաթղթում նշված կետով), որպեսզի ավելորդ կողպեքներ չլինեն, և մեկ այլ օգտատեր կարողանա վաճառել մեկ ուրիշը։ կետ.


1. Սահմանեք կողպեք՝ օգտագործելով Data Lock օբյեկտը
2. Կարդացեք մնացածը
3. Ստուգում ենք դուրսգրման հնարավորությունը
4. Շարժումներ ենք ստեղծում, օրինակ՝ ապրանքներ դուրս գրում
5. Փաստաթղթի տեղադրումից հետո արգելափակումն ավտոմատ կերպով հանվում է (արգելափակումը վավեր է որպես տեղադրման գործարքի մաս և ավտոմատ կերպով հեռացվում է համակարգի կողմից): Այսինքն՝ օբյեկտը հատուկ բացելու կարիք չկա։

2) փաստաթղթերի մշակման նոր մեթոդաբանություն (օգտագործելով LockForChange հատկությունը = True)

Այն օգտագործվում է, եթե մեզ անհրաժեշտ չէ տեղեկատվություն գրանցամատյաններից՝ շարժումներ ձևավորելու համար, և մենք կարող ենք ստուգել, ​​թե արդյոք դուրս գրելիս գնացել ենք նեգատիվի, եթե գրանցելուց հետո դիտարկենք ռեգիստրի մնացորդները և տեսնենք, որ կան բացասականներ։ . Այս դեպքում մենք կհասկանանք, որ չափից դուրս շատ ենք դուրս գրել և կչեղարկենք դուրսգրման գործողությունը։

Օրինակ:
Դիտարկենք ապրանքի վաճառքի գործողությունը։
Փաստաթղթում` քանակ, գրանցամատյանում` միայն քանակ
Այսպիսով, մենք փաստաթղթից գիտենք ապրանքների քանակը։
Փաստաթղթում նշված քանակով շարժումներ ենք կազմում և գրանցում։ Այնուհետև մենք կարդում ենք գրանցամատյանը, նայում մնացորդներին և վերլուծում, թե արդյոք կան բացասականներ։ Եթե ​​կա, ցուցադրեք սխալ և դրեք Refusal = True:

Այսինքն, հաջորդականությունը այսպիսին է.
1. Ռեգիստրում տեղաշարժվելու համար սահմանեք BlockForChange հատկությունը = True
2. Շարժումներ ենք ստեղծում՝ ապրանքները դուրս գրել
3. Գրանցեք շարժումները
4. Կարդացեք գրանցամատյանը և համոզվեք, որ բացասական մնացորդներ չկան: Եթե ​​կա, ուրեմն ավելցուկը դուրս են գրել, եթե ոչ, ուրեմն ամեն ինչ լավ է։

Այսպիսով, այս դեպքում կարիք չկա նշելու, թե որ չափերով պետք է արգելափակենք ռեգիստրը։
Մենք պարզապես BlockForChange հատկությունը դնում ենք True-ի, նախքան մեր շարժումները գրանցելը, ձևավորում ենք շարժումները և գրանցում:
Համակարգն ինքն է արգելափակելու գրանցամատյանը ձայնագրման պահին՝ ըստ անհրաժեշտ չափումների՝ վերլուծելով այն, ինչ մենք արձանագրել ենք։
Ավարտելուց հետո արգելափակումը կհեռացվի:

Այս տարբերակը (երկրորդը) ավելի պարզ է, այն կոչվում է «փաստաթղթերի մշակման նոր մեթոդաբանություն», և 1C-ն խորհուրդ է տալիս հնարավորության դեպքում օգտագործել այն և հանել միավորները, եթե օգտագործվում է առաջին տարբերակը, բայց որոշ դեպքերում այն ​​պարզապես չի կարող կիրառվել, և առաջին տարբերակը օգտագործվում է Data Locking օբյեկտը (տես վերևի օրինակը):

Նաև նշում եմ, որ անկախ ընտրված մեթոդից, շարժումները պետք է մաքրվեն դրանց հետ աշխատելուց առաջ (տե՛ս նախորդ խորհուրդը)

*************************************************************************************************
Տվյալների արգելափակում (արգելափակման մեթոդ թիվ 1 վերը նշված նկարագրությունից)

Պահանջվում է վերահսկվող կողպում, որտեղ տվյալները ընթերցվում են և շարժումները կատարվում են այս տվյալների հիման վրա
Կառավարվող կողպման կոդը ստանալու ամենաարագ ճանապարհն է մուտքագրել «Տվյալների կողպում», զանգահարել Սինտաքսի օգնականին և պարզապես պատճենել օրինակի կոդը այնտեղից: Այնուհետև պարզապես փոխեք այն ձեր ռեգիստրի անունով և չափսերով:

Դա նման բան է թվում.

Կողպեք = NewDataLock; Locking Element = Locking.Add("Accumulation Register.GoodsInWarehouses"); LockElement.Mode = DataLockMode.Exclusive; BlockingElement.DataSource = PM; Locking Element.UseFromDataSource ("Nomenclature", "Nomenclature"); Lock.Lock();

*************************************************************************************************
Փաստաթղթերի աղյուսակային մասը ավելի լավ է անվանել պարզապես «TC»

Փաստաթղթերի 99%-ում կա միայն մեկ աղյուսակային մաս: Աղյուսակային մասերի նման միասնական անվանումը մեծապես կօգնի խնայել ժամանակը, քանի որ.
1) Շատ կարճ - արագ գրել
2) Նույնը բոլոր փաստաթղթերի համար, ծածկագիր գրելիս պետք չէ հիշել, թե ինչպես է այն կոչվում

*************************************************************************************************
Հարցման արդյունքը պետք է ստուգվի դատարկության համար՝ նախքան տեխնիկական բնութագրում բեռնելը կամ վերբեռնելը:

Ընդհանրապես, ես նմուշառում էի օգտագործում բոլոր առաջադրանքներում։

Նմուշառումը համակարգի համար արդյունավետության առումով ավելի օպտիմալ է, քանի որ այն «սրված» է միայն տվյալների ընթերցման համար (ի տարբերություն TK-ի):

Բայց ամեն դեպքում, Select() մեթոդից առաջ ավելի լավ է ստուգել հարցման արդյունքը դատարկության համար, դա էլ ավելի կնվազեցնի բեռը համակարգի վրա:

Արդյունք = Query.Run(); Եթե ​​Not Result.Empty() Ապա Ընտրեք = Result.Select(TravelQueryResult.ByGrouping); ... Վերջ Եթե;

Իսկ այն դեպքում, երբ մենք պետք է խնդրանքից ստանանք միայն մեկ արժեք
(օրինակ՝ միայն դուրսգրման մեթոդը՝ այս տարվա համար սահմանված հաշվապահական հաշվառման քաղաքականության համաձայն).

Արդյունք = Query.Run(); If Not Result.Empty() Ապա Ընտրեք = Result.Select(); Selection.Next(); Cost Write-off Method = Sample.Cost Write-Off Method; վերջԵթե;

*************************************************************************************************
Փաստաթուղթ «Գործողություն» հաշվապահական առաջադրանքի համար

Հաշվապահական առաջադրանքների համար անհրաժեշտ է ստեղծել Գործառնական փաստաթուղթ:

Մենք ընդհանրապես անջատում ենք դրա տեղադրումը («Փակցում = Մերժում» հատկություններում), նշում ենք, որ այն շարժումներ է կատարում հաշվապահական գրանցամատյանում և շարժումները քաշում ենք ձևի վրա:

*************************************************************************************************
Փաստաթղթերի արագ մշակում.

Պետք է լինի ներառված:
Գործառնական և հաշվապահական հաշվառման մեջ: փաստաթղթերի հաշվառումը պետք է միացված լինի (բացառությամբ «Շահագործման» փաստաթղթի, տես ստորև):

Պետք է լինի անջատված:
հաշվարկային առաջադրանքներում իմաստ չունի աշխատավարձի փաստաթղթի համար:

«Գործողություն» փաստաթղթի համար հրապարակումը պետք է ընդհանրապես անջատված լինի (փաստաթղթի հատկություններում «Փակցնել = Արգելել»),
քանի որ նա գրում է ուղղակի տվյալներ գրում է ռեգիստրում գրելիս:

*************************************************************************************************
«Կամ նշված անվանացանկը կամ որևէ մեկը, եթե նշված չէ» ձևի պայմանը.

Հարցումներում կատարվում է հետևյալ առաջադրանքը. օրինակ, դուք պետք է ընտրեք փաստաթղթերը նշված անվանացանկով կամ բոլոր փաստաթղթերը, եթե նոմենկլատուրան նշված չէ:
Հարցման մեջ այն լուծվում է հետևյալ պայմանով.

Անվանակարգ = &Անվանակարգ ԿԱՄ &Անվանակարգ = Արժեք (Directory.Nomenclature.EmptyLink)

Բայց ավելի օպտիմալ և ճիշտ կլինի փոխակերպել այս պայմանը (շնորհակալություն yukon).

Request.Text = Request.Text + "WHERE Անվանակարգ = &Անվանակարգ";

վերջԵթե;

Հարցման օբյեկտի մոդելի հայտնվելով 8.3.5-ում, հնարավոր կլինի ավելի ապահով կերպով ավելացնել պայման.

Եթե ​​ValueFilled (Անվանակատուրա) Ապա
Query1.Selection.Add("Item = &Nomenclature");
Request.SetParameter ("Nomenclature", Nomenclature);
վերջԵթե;

*************************************************************************************************
Աղյուսակների միացում հարցումներում.

Ընդհանուր գրառումների քանակը կախված չէ նրանից, թե արդյոք ցուցադրվում է միացված աղյուսակի դաշտը, դա կախված է միայն կազմաձևված հարաբերություններից:
Այսինքն՝ կցված աղյուսակի դաշտը կարող է չցուցադրվել։

Եթե ​​ցանկանում եք առանց որևէ պայմանի աղյուսակ կցել, ապա պայմանների ներդիրում պարզապես գրեք «ՃԻՇՏ» պայմանը:
Այս դեպքում աղյուսակը ճշգրտորեն կմիանա:

*************************************************************************************************
Օգտագործելով բնութագրերի տեսակների պլանը (PVC).

1. Օգտագործեք որպես առարկաների բնութագրերը նկարագրելու մեխանիզմ:

1.1. Մենք ստեղծում ենք PVC: Դրանք կլինեն բնութագրերի տեսակները (օրինակ՝ գույնը, չափը, առավելագույն արագությունը և այլն): Պարամետրերում ընտրեք բոլոր հնարավոր տեսակի բնութագրիչ արժեքները և, անհրաժեշտության դեպքում, ստեղծեք օբյեկտը 1.2 կետից և նաև նշեք այն պարամետրերում:

1.2. 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); Ընթացիկ ամիս = Ամսաթիվ; whileDateStartCurrentMonth<= НачалоМесяца(ТекСтрокаОсновныеНачисления.ПериодДействияКонец) Цикл Движение = Движения.ОсновныеНачисления.Добавить(); Движение.Сторно = Ложь; Движение.ВидРасчета = ТекСтрокаОсновныеНачисления.ВидРасчета; Движение.ПериодДействияНачало = Макс(ДатаНачалаТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияНачало); Движение.ПериодДействияКонец = КонецДня(Мин(ДатаОкончанияТекМесяца, ТекСтрокаОсновныеНачисления.ПериодДействияКонец)); Движение.ПериодРегистрации = Дата; Движение.Сотрудник = ТекСтрокаОсновныеНачисления.Сотрудник; Движение.Подразделение = ТекСтрокаОсновныеНачисления.Подразделение; Движение.Сумма = 0; Движение.КоличествоДней = 0; Движение.График = ТекСтрокаОсновныеНачисления.График; Движение.Параметр = ТекСтрокаОсновныеНачисления.Параметр; Движение.БазовыйПериодНачало = НачалоМесяца(ДобавитьМесяц(Дата, -3)); Движение.БазовыйПериодКонец = КонецДня(КонецМесяца(ДобавитьМесяц(Дата, -1))); ДатаНачалаТекМесяца = НачалоМесяца(ДобавитьМесяц(ДатаНачалаТекМесяца, 1)); ДатаОкончанияТекМесяца = КонецМесяца(ДатаНачалаТекМесяца); КонецЦикла; КонецЕсли;

*************************************************************************************************
Gantt աղյուսակի կառուցում.

Մենք ձևի վրա տեղադրում ենք «Gantt Chart» տեսակի տարր, այն անվանում ենք DG, այնուհետև ստեղծում ենք «Generate» հրամանը և ձևի մոդուլում գրում ենք հետևյալը.

&OnClient Procedure Generate(Command) GenerateOnServer(); Ընթացակարգի ավարտ &Սերվերի վրա Գործընթաց GenerateOn Server() DG.Clear(); DG.Update = False; Request = New Request(«SELECT |BasicAccrualsActualActionPeriod.Employee, |BasicAccrualsActualActionPeriod.CalculationType, |BasicAccrualsActualActionPeriod.ActionPeriodStart AS ActionActionPeriodStart, |BasicAccrualsPeriodActionPeriod. ctionsՎերջ |FROM |Հաշվարկի գրանցում.Հիմնական հաշվեգրում.Փաստացի ժամանակաշրջանԳործողություններ AS Basic AccrualsActualPeriodActions |ՈՐՏԵՂ |Հիմնական հաշվեգրումԱկտուալ ժամանակաշրջանԳործողություններ.ԺամանակահատվածԳործողություններ ԲԵՏՎԵ &Սկիզբ ամսաթվի միջև AND &EndDate»); Query.SetParameter ("StartDate", Period.StartDate); Request.SetParameter ("EndDate", Period.EndDate); Ընտրել = Query.Run().Select(); Մինչ Selection.Next() Loop Point = DG.SetPoint(Selection.Employee); Series = DG.SetSeries (Selection.CalculationType); Արժեք = DG.GetValue(Point, Series); Interval = Value.Add(); Interval.Start = Sample.PeriodActionStart; Interval.End = Sample.ActionPeriodEnd; End Cycle; DG.Update = Ճշմարիտ; Ընթացակարգի ավարտը

Իրականում, մեզ համար այստեղ կարևոր է միայն օղակի կոդը, մնացած բաները օժանդակ են, ես պարզապես տվել եմ այս ենթաառաջադրանքի ամբողջ իրականացումը։
Հարցման մեջ մեզ համար կարևոր է աշխատողի առկայությունը, վճարման տեսակը, ժամկետի մեկնարկի և ավարտի ամսաթիվը:
Կոդն իրականում շատ պարզ է, հեշտ է հիշել, մի անհանգստացեք, եթե այն դժվար է թվում

*************************************************************************************************
Հաշվարկային առաջադրանքներում «հետադարձ» գրառումների մշակում.

Գործարքների մշակման ընթացակարգում (օբյեկտի մոդուլ) մենք ձևավորում ենք բոլոր շարժումները, այնուհետև, եթե այլ ժամանակահատվածներում գրառումներ կան, մենք դրանք ստանում ենք այսպես.
(համակարգը դրանք ստեղծում է ավտոմատ կերպով. օգնում է մեզ).

Addition Records = Movements.MainAccruals.GetAddition(); // Հավելումը ստանալու համար շարժումները գրանցելու կարիք չկա

Գրառումների հավելումների ցիկլի յուրաքանչյուր տեխնիկական տողի համար
Record = Movements.MainAccruals.Add();
FillPropertyValues ​​(Record, TechString);
Record.RegistrationPeriod = TechString.RegistrationPeriodReversal;
Record.ActionPeriodStart = TechString.ActionPeriodStartReverse;
Record.ActionPeriodEnd = TechString.ActionPeriodEndReversal;
Ցիկլի ավարտ

Իսկ գրառումները հաշվարկելիս մուտքագրեք չեկեր.

Եթե ​​TechMotion.Reversal Այնուհետեւ
CurrentMovement.Sum = - CurrentMovement.Amount;
վերջԵթե;

*************************************************************************************************
Ինչպես որոշել, թե ինչն է ներառված հիմնական հաշվեգրումների մեջ և ինչն է ներառված լրացուցիչ հաշվեգրումների մեջ՝ հաշվարկային առաջադրանքներում:

Բայց սա միշտ չէ, որ 100%-ով պարզ է, կան նաև ավելի բարդ դեպքեր, թեև դրանք բավականին քիչ են.
(օրինակ, բոնուս, որը կախված է մեկ ամսվա աշխատանքային օրերի քանակից. սա ՆԱ է):

Հիմնական վճարներ.
Եթե ​​հաշվարկի տեսակը կախված է ժամանակացույցից (նկատի ունի տեղեկատվության գրանցամատյան՝ օրացուցային ամսաթվերով), ապա դա վերաբերում է հիմնական վճարներին:

Օրինակ 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» ընթացակարգում:
Ստեղծվելուց հետո բոլոր պարամետրերը ոչնչացվում են և այլևս հասանելի չեն ձևաթղթում:
Բացառություն են կազմում այն ​​պարամետրերը, որոնք հայտարարագրված են ձևաթղթի խմբագրիչում «Հիմնական պարամետր» հատկանիշով:
Նրանք որոշում են ձևի յուրահատկությունը:
Այս պարամետրը գոյություն կունենա այնքան ժամանակ, քանի դեռ կա ձևը:

*************************************************************************************************
Օգտագործելով տաքսի ինտերֆեյսը

Մշակման ընթացքում դուք կարող եք սահմանել սովորական կառավարվող ինտերֆեյսը 8.2-ը կազմաձևման հատկություններում. սա ամեն ինչ զգալիորեն ավելի կոմպակտ և ծանոթ է դարձնում:
Սա հատկապես ճիշտ է, եթե դուք հեռավար վարձակալում եք. էկրանի լուծաչափը շատ փոքր է, և անհնար է որևէ բան անել «տաքսի» ինտերֆեյսի հետ:
Պարզապես մի մոռացեք տեղադրել «Տաքսի» կրկին, երբ ավարտեք:Հակառակ դեպքում քննիչը միավորներ կհանի:

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

Հ.Գ.: Է Կան առանձին ստանդարտ ենթաառաջադրանքներ, որոնք օգտագործվում են բոլոր առաջադրանքների համար, և հենց դրանք պետք է կարողանաք լուծել (օրինակ, խմբաքանակներով դուրս գրելը, PVC- ի օգտագործումը (դե, սա իսկապես հազվադեպ է) և այլն): Իսկ բոլոր առաջադրանքներում դրանք ուղղակի կրկնվում են (մի տեղ կան ենթախնդիրներ, մի տեղ՝ այլ, ուղղակի տարբեր համակցություններով)։ Ավելին, նրանք վաղուց խոստացել են թողարկել նոր հավաքածու (եթե արդեն չեն թողել), որում պետք է շատ ավելի շատ խնդիրներ լինեն, այսինքն՝ իմաստ չունի անգիր անել առանձին խնդիրների լուծումները, իմաստ ունի սովորել, թե ինչպես լուծեք անհատական ​​ստանդարտ ենթաառաջադրանքները, ապա դուք կլուծեք ցանկացած խնդիր:

PSS. Գործընկերներ, եթե որևէ մեկը ունի որևէ այլ օգտակար տեղեկություն քննությանը պատրաստվելու և այն հանձնելու վերաբերյալ, խնդրում ենք գրել մեկնաբանություններում, և մենք կավելացնենք հոդվածը: