Կազմաձևը կառավարվող կողպեքների փոխակերպում: Գործարքներում տվյալների կողպեքների կառավարում, մեխանիզմ (Գործարքի տվյալների կողպման հսկողություն, մեխանիզմ) Կառավարվող կողպեքներին անցնելու հիմնական պատճառները

Կառավարվող կողպեքներին անցնելու հիմնական պատճառները.

Հիմնական պատճառը ցուցմունքների վրա հիմնված 1C:Expert-ի կամ 1C:TsUP-ի առաջարկությունն է:
Խնդիրներ միաժամանակ օգտագործողների հետ ()
Օգտագործելով Oracle, PostgreSQL և.

Աշխատանքի արժեքը.

Կառավարվող կողպեքների էությունը

Ավտոմատ կողպման կառավարման ռեժիմում աշխատելիս 1C:Enterprise-ը DBMS մակարդակում գործարքի ժամանակ սահմանում է տվյալների մեկուսացման բարձր աստիճան: Սա թույլ է տալիս լիովին վերացնել թերի կամ սխալ տվյալներ ստանալու հնարավորությունը՝ առանց հավելվածի մշակողների կողմից հատուկ ջանքեր գործադրելու:

Սա հարմար և ճիշտ մոտեցում է փոքր թվով ակտիվ օգտատերերի համար։ Զարգացման հեշտության գինը DBMS մակարդակում ավելորդ կողպման որոշակի քանակն է: Այս կողպեքները կապված են ինչպես DBMS-ում կողպման մեխանիզմների ներդրման առանձնահատկությունների հետ, այնպես էլ այն փաստի հետ, որ DBMS-ը չի կարող (և չի ընդունում) հաշվի առնել 1C:Enterprise մետատվյալների օբյեկտների ֆիզիկական նշանակությունն ու կառուցվածքը:

Ռեսուրսների (մեծ թվով օգտվողների) հետ աշխատելու ժամանակ ավելորդ կողպեքների ազդեցությունը ինչ-որ պահի նկատելի է դառնում զուգահեռ ռեժիմում կատարման առումով:

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

1C-ից նոր կոնֆիգուրացիաներ իրականացվեցին անմիջապես վերահսկվող ռեժիմով:

Հարց. Հնարավո՞ր է նախ աուդիտ անել, հետո անցնել FM:

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

Հարց՝ UX-ին փոխանցելու համար ինչպիսի՞ մուտք պետք է տրամադրվի՝ RDP, TeamViewer: Կամ կարո՞ղ եմ ձեզ ուղարկել կոնֆիգուրացիայի ֆայլը:

Պատասխան. Մենք փորձում ենք չսահմանափակվել մեկ կոնկրետ հեռահար մուտքի տեխնոլոգիայով, դա կլինի ցանկացած հեռահար մուտքի տեխնոլոգիա. Եթե դա ձեզ համար նշանակություն չունի, ապա RDP-ն ավելի գործնական է:
Մենք կարող ենք կատարել օպտիմիզացում՝ հիմնվելով ուղարկված կազմաձևման ֆայլի վրա, բայց այնուհետև մենք չենք կարողանա վրիպազերծել որոշ իրական տվյալներ, և դուք պետք է ավելի ուշադիր փորձարկեք: Եթե մենք օպտիմիզացիա կատարենք տվյալների բազայի պատճենի վրա, մենք կարող ենք այն ավելի մանրակրկիտ ստուգել՝ նախքան աշխատանքի արդյունքը ձեզ տալը:

Հարց. Մենք ունենք 10 լրիվ դրույքով ծրագրավորող, ովքեր ամեն օր ինչ-որ բան են փոխում համաժողովում: Օգտագործվում է ընդհանուր կոնֆիգուրացիայի խանութ»: Ինչպե՞ս կկազմակերպվի փոխգործակցությունը UX փոխանցման ժամանակ: Թե՞ բոլոր ծրագրավորողներին պետք է արձակուրդ ուղարկել։

Պատասխան. Որպես կանոն, մեր փոփոխությունները կատարվում են մի քանի օրվա ընթացքում։ Մնացած ժամանակը ծախսվում է կատարված փոփոխությունների փորձարկման վրա, այդ թվում՝ բիզնեսի, այլ ոչ թե տեխնիկական նկատառումներով որոշված պահանջվող տրամաբանության տեսանկյունից։ Մենք մենք կարող ենք փոփոխություններ կատարել առանձին կազմաձևման ֆայլում cf, և այնուհետև ձեր ծրագրավորողը այն կհանձնի պահեստին: Ոչ ոք ստիպված չի լինի արձակուրդ գնալ. Փոխազդեցության այլ տարբերակներում դուք պարզապես պետք է համաձայնեք, թե որ օբյեկտները ձեր մշակողները նախատեսում են գրավել, որպեսզի մենք կարողանանք կառուցել աշխատանքային պլան, որը հարմար կլինի երկու կողմերի համար: Որպես կանոն, ձեր մշակողները կարիք չունեն նկարահանելու ամբողջ կոնֆիգուրացիան կամ մեզ տալ օրվա «ղեկը»:

Տվյալների կողպեքի կառավարման մեխանիզմգործարքում թույլ է տալիս կողպել փոփոխվող տվյալները ոչ թե օգտագործված տվյալների բազայի կառավարման համակարգի միջոցով, այլ հարթակի միջոցով: Տվյալների կողպեքի նման կառավարումն իրականացվում է ոչ թե DBMS-ի տվյալների, այլ թեմայի վերաբերյալ: Դրա շնորհիվ կողպեքներն ավելի ճշգրիտ են կիրառվում, և օգտվողների համաժամանակությունը մեծանում է:

Կազմաձևում 1C:Enterprise 8-ը կարող է գործել գործարքում կողպեքները կառավարելու երեք ռեժիմներից մեկով.

ավտո;
կառավարվող - ստանդարտ ռեժիմ նոր կոնֆիգուրացիաների համար;
ավտոմատ և կառավարվող:

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

Կառավարվող ռեժիմթույլ է տալիս մեծացնել օգտատերերի աշխատանքի զուգահեռությունը հաճախորդ-սերվերի աշխատանքի ռեժիմում՝ օգտագործելով տվյալների բազայի գործարքների մեկուսացման ավելի ցածր մակարդակ (Read Committed): Գործարքի վրա տվյալներ գրելիս ներկառուցված լեզվական օբյեկտները ավտոմատ կերպով արգելափակում են պահանջվող տվյալները: Մշակողը պետք է կառավարի տվյալների կողպեքները այն դեպքերում, երբ բիզնես տրամաբանությունը պահանջում է գործարքի տվյալների հետևողական և հետևողական ընթերցում:

Ավտոմատ և կառավարվողռեժիմը թույլ է տալիս օգտագործել գործարքի մեջ կողպեքները կառավարելու հնարավորությունը միայն որոշ կոնֆիգուրացիայի օբյեկտների համար: Այս ռեժիմը կարող է օգտագործվել առանձին հավելվածների օբյեկտների հետ օգտատիրոջ համաժամանակության օպտիմալացման համար (օրինակ՝ ամենաինտենսիվ օգտագործվող փաստաթղթերից մի քանիսը) կամ մեծ կոնֆիգուրացիաները աստիճանաբար անցում կատարել գործարքի կողպման կառավարման ռեժիմին:

Ամփոփելով, ավտոմատ արգելափակման ռեժիմում և վերահսկվող արգելափակման ռեժիմում աշխատելիս տարբերությունները ներկայացված են հետևյալ աղյուսակում.

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

Հատկապես այդ նպատակով սեփականություն ունեն կուտակային մատյանների և հաշվապահական հաշվառման գրանցամատյանների հավաքածուները BlockForChange.

Եթե Ձեզ անհրաժեշտ է վերահսկել մնացորդները և այնուհետև գրանցել շարժումները նույն գրանցամատյանում, ապա այս գույքը պետք է սահմանվի գույքի այս ռեգիստրի գրառումների հավաքածուի համար: Շարժումներ.

Այս հատկության էֆեկտը նույնն է, ինչ եթե մշակողը ինքնուրույն տեղադրի (կոդով նախատեսված) անհրաժեշտ կառավարվող կողպեքները 1C:Enterprise 8-ի համար: Պլատֆորմը ավտոմատ կերպով կտեղադրի անհրաժեշտ կառավարվող կողպեքը՝ գրառումների այս փաթեթը գրելիս: Արդյունքում, նույն կողպեքով օգտագործվող այլ կառավարվող գործարքները չեն կարողանա սկսել կարդալ այս գրանցամատյանը, մինչև ընթացիկ գործարքի ավարտը:

Ստորև բերված է տվյալների կողպեքների «ձեռքով» վերահսկման օրինակ՝ կուտակային ռեգիստրի տվյալները կարդալիս Նյութերի հաշվառումփաստաթղթերի մշակման մեջ Վաճառքի հաշիվ-ապրանքագիր. Այս օրինակում կառավարվող կողպեքները ստեղծվում և տեղադրվում են ամբողջությամբ՝ օգտագործելով ներկառուցված լեզուն:

Մեխանիզմ գործարքի կողպեքներօգտագործվում է DBMS-ին օգտատերերի մրցակցային մուտքի համար:
Գործարքը մի տեսակ շարունակական գործողություն է, որի ընթացքում տվյալների բազայի վիճակը փոխվում է: Սա փոփոխության նվազագույն քանակն է. դուք չեք կարող կես գործարք կատարել. եթե գործարքը չի ավարտվում, տվյալների բազան կվերադառնա իր սկզբնական վիճակին:
Քանի որ գործարքն ընդգրկում է տվյալների զանգված, այս զանգվածին մուտք գործելու մի նրբություն է առաջանում. օրինակ, մի գործարքը փոխում է տվյալները, իսկ մյուսը փորձում է կարդալ դրանք: Ընթերցանության արդյունքը կարող է սխալ լինել, քանի որ չի ներառի վերջին փոփոխությունները: Հետևաբար, գործարքների մեկուսացումն աշխատում է DBMS մակարդակում: Հնարավոր են մեկուսացման հետևյալ մակարդակները.

Կարդացեք առանց պարտավորությունների- մինչ մի գործարք փոխում է զանգվածը, մյուսը չի կարող փոխել այն, բայց կարող է կարդալ: Մեկուսացման ամենացածր մակարդակը.
Կարդացեք հավատարիմ- մինչ մի գործարք փոխում է զանգվածը, մյուսը չի կարող փոխել կամ կարդալ այն
Կրկնվող ընթերցում- մինչ մի գործարք կարդում է զանգվածը, մյուսը չի կարող փոխել այն, բայց կարող է կարդալ
Սերիալիզացվող- մինչ մի գործարք կարդում է զանգվածը, մյուսը չի կարող փոխել կամ կարդալ այն: Բոլոր գործողությունները հաջորդական են: Մեկուսացման առավելագույն մակարդակ:

Եթե 1C:Enterprise կոնֆիգուրացիան սահմանված է ավտոմատ կողպման ռեժիմ, ապա գործարքի մեկուսացման մակարդակը ընտրվում է DBMS-ի կողմից: MS SQL-ի դեպքում սա կլինի Repeatable read կամ Serializable մակարդակներ, այսինքն՝ տվյալների մեկուսացումը մոտ է առավելագույնին: Սա լուծում է տվյալների ճշտության հետ կապված խնդիրները, բայց կարող է հանգեցնել DBMS մակարդակի արգելափակման՝ օգտատերերի ինտենսիվ աշխատանքի ժամանակ: Հետևաբար, 1C:Enterprise-ն ունի կողպեքների հետ աշխատելու իր ֆունկցիոնալությունը, որն ակտիվանում է՝ միացնելով կառավարվող կողպեքների ռեժիմը: Այս դեպքում, MS SQL-ի համար գործարքի մեկուսացման մակարդակը կկատարվի «Կարդացված»: Պլատֆորմն ինքնին կմեկուսացնի տվյալները՝ առանց հենվելու DBMS-ի վրա:

Կառավարվող կողպման ռեժիմը միացված է կազմաձևման հատկություններում՝

Նաև կողպման ռեժիմը կարող է սահմանվել հատուկ կազմաձևման օբյեկտների համար.

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

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

Փաստաթղթի ռեժիմ Ավտոմատ, գրանցման ռեժիմ Ավտոմատ ->
Փաստաթղթի ռեժիմ Կառավարվող, գրանցման ռեժիմ Կառավարվող -> գրանցում ըստ գրանցման կառավարվող ռեժիմում
Փաստաթղթի ռեժիմ Ավտոմատ, գրանցման ռեժիմ Վերահսկվող -> գրանցում ըստ գրանցման ավտոմատ ռեժիմում
Փաստաթղթի ռեժիմ Կառավարվող, գրանցման ռեժիմ Ավտոմատ -> բացառություն (սխալ)

Հարց 1C քննության 06.59. Պլատֆորմ Մասնագիտական. Ցանկացած ռեգիստրի միջոցով փաստաթուղթ փակցնելիս, եթե փաստաթուղթն ունի գործարքների կողպման ավտոմատ կառավարման ռեժիմ, իսկ ռեգիստրն ունի կառավարվող ռեժիմ (կազմաձևման հատկություններում օգտագործվում է «Ավտոմատ և կառավարվող» տարբերակը), ապա նման տեղադրումը կհանգեցնի.

Ճիշտ պատասխանը երկրորդն է, մենք դա որոշում ենք առաջին գործարքով, եթե այն ավտոմատ է, ապա ամեն ինչ ավտոմատ է։

Հարց 1C քննության 06.60. Պլատֆորմի պրոֆեսիոնալ: Ցանկացած ռեգիստրով փաստաթուղթ փակցնելիս, եթե փաստաթուղթն ունի գործարքների կողպեքները կառավարելու կառավարվող ռեժիմ, իսկ ռեգիստրն ունի ավտոմատ (կազմաձևման հատկություններում օգտագործվում է «Ավտոմատ և կառավարվող» տարբերակը), ապա նման տեղադրումը կհանգեցնի.

դեպի սխալ իրավիճակ
ամբողջ գործարքը կավարտվի ավտոմատ կերպով
ամբողջ գործարքը կավարտվի վերահսկվող եղանակով

Ճիշտ պատասխանն առաջինն է, մենք որոշում ենք առաջին գործարքով, եթե այն վերահսկվում է, ուրեմն սխալ է։

Հարց 1C քննության 06.61. Պլատֆորմի պրոֆեսիոնալ: Ցանկացած ռեգիստրի միջոցով փաստաթուղթ փակցնելիս, եթե փաստաթուղթն ունի գործարքների կողպեքների կառավարման ավտոմատ ռեժիմ, իսկ ռեգիստրն ունի կառավարվող ռեժիմ («Կառավարվող» տարբերակը օգտագործվում է կազմաձևման հատկություններում), ապա նման տեղադրումը կհանգեցնի.

դեպի սխալ իրավիճակ
ամբողջ գործարքը կավարտվի ավտոմատ կերպով
ամբողջ գործարքը կավարտվի վերահսկվող եղանակով

1C:Enterprise համակարգը թույլ է տալիս օգտագործել տվյալների բազայի հետ աշխատելու երկու եղանակ՝ գործարքի մեջ ավտոմատ կողպման ռեժիմ և գործարքի մեջ վերահսկվող կողպեքների ռեժիմ:

Այս ռեժիմների միջև հիմնարար տարբերությունը հետևյալն է. Ավտոմատ կողպման ռեժիմը չի պահանջում ծրագրավորողից որևէ գործողություն ձեռնարկել գործարքում կողպեքները կառավարելու համար: Այս կանոններն ապահովվում են 1C:Enterprise համակարգի հարթակի կողմից՝ որոշակի DBMS-ում գործարքների մեկուսացման որոշակի մակարդակների օգտագործման միջոցով: Գործողության այս եղանակը ամենապարզն է մշակողի համար, սակայն որոշ դեպքերում (օրինակ, մեծ թվով օգտվողների միաժամանակյա ինտենսիվ աշխատանքով), DBMS-ում օգտագործվող գործարքի մեկուսացման մակարդակը չի կարող ապահովել բավարար զուգահեռություն, որն արտահայտվում է մեծ թվով արգելափակման կոնֆլիկտների ձև, երբ օգտվողներն աշխատում են:

Կառավարվող կողպման ռեժիմում աշխատելիս 1C:Enterprise համակարգը օգտագործում է գործարքների մեկուսացման շատ ավելի ցածր մակարդակ DBMS-ում, ինչը կարող է զգալիորեն մեծացնել հավելվածի կիրառման օգտատերերի համատեղելիությունը: Այնուամենայնիվ, ի տարբերություն ավտոմատ կողպման ռեժիմի, գործարքի մեկուսացման այս մակարդակն ինքնին այլևս չի կարող ապահովել գործարքի տվյալների հետ աշխատելու բոլոր կանոնների պահպանումը: Հետևաբար, կառավարվող ռեժիմով աշխատելիս ծրագրավորողից պահանջվում է ինքնուրույն կառավարել գործարքում սահմանված կողպեքները:

Արգելափակման ռեժիմի կարգավորումը կազմաձևում

Կազմաձևն ունի Data Lock Control Mode հատկությունը: Յուրաքանչյուր կազմաձևման կիրառական օբյեկտ ունի նաև տվյալների կողպման կառավարման ռեժիմի հատկություն:
Ամբողջ կազմաձևման համար տվյալների կողպման կառավարման ռեժիմը կարող է սահմանվել Ավտոմատ, Կառավարվող (նոր կազմաձևման լռելյայն) կամ Ավտոմատ և կառավարվող: Ավտոմատ և կառավարվող արժեքները նշանակում են, որ համապատասխան արգելափակման ռեժիմը կօգտագործվի բոլոր կազմաձևման օբյեկտների համար՝ անկախ օբյեկտներից յուրաքանչյուրի համար սահմանված արժեքներից: Ավտոմատ և կառավարվող արժեքը նշանակում է, որ որոշակի կոնֆիգուրացիայի օբյեկտի համար կօգտագործվի «Տվյալների կողպման կառավարման ռեժիմ» հատկության մեջ նշված ռեժիմը՝ ավտոմատ կամ կառավարվող:
Հարկ է նշել, որ մետատվյալների օբյեկտի համար սահմանված տվյալների կողպման կառավարման ռեժիմը սահմանված է այն գործարքների համար, որոնք նախաձեռնվում են 1C:Enterprise համակարգի կողմից այս օբյեկտի տվյալների հետ աշխատելիս (օրինակ՝ օբյեկտի տվյալները փոփոխելիս):
Եթե, օրինակ, օբյեկտ գրելու գործողությունը կատարվում է մշակողի կողմից նախաձեռնված գործարքում (StartTransaction() մեթոդ), ապա տվյալների կողպման կառավարման ռեժիմը կորոշվի Locking Mode պարամետրի արժեքով:
StartTransaction() մեթոդը և ոչ Data Lock Control Mode մետատվյալների օբյեկտի հատկության արժեքը:
Լռելյայնորեն, արգելափակման ռեժիմի պարամետրը դրված է տվյալների արգելափակման կառավարման ռեժիմի վրա: Ավտոմատ, այսպես
Հստակ գործարքում կառավարվող արգելափակման ռեժիմն օգտագործելու համար դուք պետք է նշեք այս պարամետրի արժեքը
Տվյալների կողպման կառավարման ռեժիմ: Կառավարվող:

Աշխատեք կառավարվող կողպեքների հետ՝ օգտագործելով ներկառուցված լեզուն

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

Պայմաններ են սահմանվում, որպեսզի դաշտի արժեքը հավասար լինի նշված արժեքին կամ դաշտի արժեքը լինի նշված միջակայքում:
Պայմանները կարող են սահմանվել երկու եղանակով.

բացահայտորեն նշելով DataLockElement օբյեկտի դաշտի անվանումը և արժեքը (SetValue() մեթոդը);
նշելով անհրաժեշտ արժեքները պարունակող տվյալների աղբյուր (DataLockElement օբյեկտի DataSource հատկությունը):

Յուրաքանչյուր արգելափակող տարրի համար կարող է սահմանվել երկու արգելափակման ռեժիմներից մեկը.

կիսված,
բացառիկ.

Կառավարվող կողպման համատեղելիության աղյուսակն ունի հետևյալ տեսքը.

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

«Ավտոմատ և վերահսկվող» ռեժիմում գործողության առանձնահատկությունները

Ավտոմատ և վերահսկվող արգելափակման կառավարման ռեժիմում աշխատելիս պետք է հաշվի առնել երկու առանձնահատկություն.

Անկախ տվյալ գործարքի համար սահմանված ռեժիմից՝ համակարգը կտեղադրի համապատասխան կառավարվող
արգելափակում.
Կողպեքի կառավարման ռեժիմը որոշվում է ամենաբարձր մակարդակի գործարքով: Այլ կերպ ասած, եթե գործարքի մեկնարկի պահին սկսվել է մեկ այլ գործարք, ապա սկսված գործարքը կարող է իրականացվել միայն այն ռեժիմով, որը սահմանված է արդեն գործող գործարքի համար:

Դիտարկենք թվարկված հատկանիշները ավելի մանրամասն:

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

Երկրորդ առանձնահատկությունն այն է, որ կողպեքի կառավարման ռեժիմը, որը նշված է կոնֆիգուրացիայի մեջ մետատվյալների օբյեկտի համար կամ բացահայտորեն նշված է գործարքը սկսելիս (որպես StartTransaction() մեթոդի պարամետր) միայն «ցանկալի» ռեժիմ է: Կողպեքի կառավարման փաստացի ռեժիմը, որով գործարքը կիրականացվի, կախված է նրանից, թե արդյոք սա գործարք սկսելու առաջին զանգն է, թե՞ այդ պահին 1C:Enterprise համակարգի այս նիստում արդեն սկսվել է մեկ այլ գործարք:

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