20.09.2014

Հարցման լեզվում կա «Թույլատրված» հրահանգ: Այն նախատեսվում է օգտագործել շրջանակի կողմից՝ զտելու այն գրառումները, որոնց նկատմամբ օգտատերը իրավունք չունի տվյալների բազայի գրառումների մակարդակի սահմանը սահմանելիս:

Թվում է, որ հարցումներում ավելի լավ է միշտ օգտագործել այս հրահանգը: Ես կպնդեմ, որ դա այդպես չէ։ Նաև կվիճարկեմ, որ հնարավորության դեպքում պետք է խուսափել օգտագործելուց, դրա համար։

Ասենք, ֆիզիկական անձանց փոխադարձ հաշվարկների մասին հաշվետվություն ենք կազմում։ Օգտագործողը իրավունքներ ունի մեկ կազմակերպության նկատմամբ, և տվյալների բազայում կան մեկից ավելի կազմակերպություններ, և տվյալների բազայում միացված է ռեկորդային մակարդակի սահմանափակումը: Նաև տվյալների բազայում կա «Բնակավայրեր» գրանցամատյան՝ «Կազմակերպություն» և «Անհատ» չափումներով։ Եթե ​​կա հարցում համակարգում

«Ընտրիր

Կազմակերպություն,

Անհատական

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

Ի՞նչ անել այս դեպքում, օգտագործել «Թույլատրված» հրահանգը: Իմ կարծիքով չարժե։ Պարզապես պետք է ընտրություն կատարել ըստ կազմակերպության, և օգտատերը կկարողանա հաշվետվություն ստեղծել: Տվյալների կազմով զեկույցի հարցումն այսպիսի տեսք կունենա

«Ընտրիր

Կազմակերպություն,

Անհատական

(Ընտրեք

Կազմակերպություն

անհատական)

Կուտակային ռեգիստրից Փոխադարձ հաշվարկներ

(Որտեղ

Կազմակերպություն

անհատական)

Եթե ​​օգտատերը կատարում է հարցումը սեղանի վրա առանց ընտրության, ապա հաշվետվությունը չի ստեղծվի, և օգտվողը չի ճանաչի այլ կազմակերպությունների տվյալները, և եթե նա ընտրի իր կազմակերպության համար, նա կստեղծի ճիշտ տվյալներ:

Դուք կարող եք նորից հարցնել. «Ինչու չպետք է օգտագործեք Թույլատրված հրահանգը», սա անմիջապես պարտադրում է ընտրություն, փրկում է օգտվողին հաղորդագրություններից, որոնք նա կարիք չունի:

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

Հետևաբար, անհրաժեշտ չէ այս հրահանգը զանգվածաբար մուտքագրել բնորոշ կոնֆիգուրացիաների հարցումների մեջ՝ համարելով դա սխալ: Դա խիստ հուսահատվում է դա անել կանոնակարգված հաշվետվությունների հարցումներում: Բացի այդ, դա մի արեք այլ հաշվետվություններում և փաստաթղթերում, որտեղ անհրաժեշտ է տեղեկատվության ճշգրտություն:

Բայց ինչպե՞ս կարող եք դեռևս խուսափել իրավունքի բացակայությամբ ծրագիրը «ընկելու» սխալից։

Այո, դա շատ պարզ է, դուք պետք է օգտագործեք «Փորձեք» հրամանը, ահա մի օրինակ.

Փորձ

Request.Execute();

Բացառություն

Զեկույց (ErrorDescription());

Փորձի ավարտ;

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

Արդյունքում օգտատերը չի ստանա սխալ տվյալներ և կստանա ողջամիտ սխալի մասին հաղորդագրություն:

Դուք կարող եք ծանոթանալ մեր հոդվածում RLS-ի առանձին բաժիններում տեղադրելու նրբություններին:

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

ԽնդիրՈրոշ դեպքերում 1C 8.3-ում տվյալների հասանելիության սահմանափակումների արդյունքը կարող է կախված լինել DBMS հարցման պլանից: Այս հոդվածը քննարկում է հնարավոր իրավիճակները և տալիս է խորհուրդներ, թե ինչպես խուսափել դրանից:

DBMS հարցման պլանից տվյալների հասանելիության սահմանափակումների արդյունքի հնարավոր կախվածության խնդիրը կարող է առաջանալ, երբ տվյալների բազայի հարցումը կատարվում է առանց հիմնաբառի: ԹՈՒՅԼԱՏՐՎԱԾ Էեթե առկա են տվյալների հասանելիության սահմանափակումներ ընթացիկ օգտագործողի համար, և հարցումը պարունակում է ձևի մեկ կամ մի քանի համեմատություն.

• <Выражение над полями>(ՄԵՐ|ՉԻ ՄԵՋ) (<Вложенный запрос>)
• (<Выражение над полями 1>, …, <Выражение над полями N>) (IN|NOT IN) (<Вложенный запрос>)

Եթե ​​այս դեպքում < > (հարցումը հարցման մեջ) օգտագործում է տվյալների բազայի աղյուսակներ, որոնք ենթակա են մուտքի սահմանափակումների, այնուհետև հնարավոր է, որ հարցումը հաջողությամբ կատարվի որոշ DBMS-ների վրա, իսկ մյուսների վրա հաղորդագրություն կհրապարակվի, պայմանով, որ ինֆաբազերի տվյալները լիովին նույնական են: .

Ստացեք 267 1C վիդեո դասեր անվճար.

Տարբերությունների պատճառ

Վարքագծի հնարավոր տարբերությունը պայմանավորված է առանց բանալի բառի տվյալների հասանելիության սահմանափակումների կիրառմամբ ԹՈՒՅԼԱՏՐՎԱԾ Է 1C ձեռնարկությունում 8.3.

Հարցում առանց հիմնաբառի ԹՈՒՅԼԱՏՐՎԱԾ Էհաջողությամբ կկատարվի միայն այն դեպքում, եթե դրա կատարման ընթացքում մուտքեր չկան արգելված տվյալներին: Դա անելու համար դրան ավելացվում է հատուկ ազդանշանային դաշտ, որը վերցնում է արժեքը Ճիշտայն գրառումների համար, որոնց ձևավորմանը մասնակցել են միայն թույլատրելի տվյալները, և արժեքը Սուտմնացած բոլոր մուտքերի համար: Եթե ​​ընտրության առնվազն մեկ գրառումը պարունակում է արժեքը Սուտազդանշանի դաշտում, ապա հարցումն ավարտվում է աննորմալ կերպով:

Նույն ազդանշանային դաշտը ավելացվում է համեմատության մեջ տեղադրված հարցումների արդյունքներին: IN/ՄԵՋ ՉԻ. Ընդ որում, ազդանշանի սյունակի արժեքի ստուգումն այս դեպքում կատարվում է DBMS-ի միջոցով։ Այսպիսով, եթե ներդրված հարցման կատարման գործընթացում մուտք են գործել արգելված տվյալներ, ապա հարցման կատարումը պետք է ավարտվի սխալմամբ. Օգտագործողը չունի բավարար իրավունքներ տվյալների բազայում գործողություն կատարելու համար.

Այնուամենայնիվ, հարցման պլան կառուցելիս DBMS-ը կարող է չստանալ ամբողջական ընտրությունը <Вложенным запросом> , և ստացեք միայն այն գրառումները, որոնք իրականում անհրաժեշտ են վիճակը ստուգելու համար IN/ՄԵՋ ՉԻ. Այս դեպքում հարցումը կարող է հաջողվել, նույնիսկ եթե <Вложенного запроса> Արգելված տվյալների հասանելիությունը կարող է առաջանալ որպես անկախ հարցում:

Դիտարկենք մի պարզ օրինակ. Թողեք սեղանի վրա տեղեկատու.Անհատներտվյալների հասանելիության սահմանափակումներ. Այս դեպքում հարցումը հետևյալն է.

Աղյուսակ.Անհատական ​​ՀԾ Անհատ

կկատարվի սխալմամբ՝ արգելված տվյալներ մուտք գործելու փորձի պատճառով: Եթե ​​այս հարցումը ներգրավված է համեմատության մեջ, օրինակ.

Աղյուսակ.Անհատական ​​ՀԾ Անհատ

Directory.Individuals AS Table)

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

Անհատի հետ աշխատանքի կատարման պայմանագիր

Փաստաթուղթ Անհատի հետ Աշխատանքի Կատարման Պայմանագիր ՀՍԿ Պայմանագիր ֆիզիկական անձի հետ աշխատանք կատարելու համար

Պայմանագիր անհատի հետ աշխատանքի կատարման համար. Աշխատակից. Անհատ B (

Աղյուսակ.Անհատական ​​ՀԾ Անհատ

տեղեկատու.Անհատներ AS Table

Հարցման լեզուն մշակողների համար 1C 8.3-ի հիմնարար մեխանիզմներից մեկն է: Հարցումների օգնությամբ դուք կարող եք արագ ստանալ տվյալների բազայում պահվող ցանկացած տվյալ: Դրա շարահյուսությունը շատ նման է SQL-ին, սակայն կան որոշ տարբերություններ։

1C 8.3 (8.2) հարցումների լեզվի հիմնական առավելությունները SQL-ի նկատմամբ.

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

Հարցման լեզվի թերությունները 1C-ում.

• ի տարբերություն SQL-ի, 1C հարցումները թույլ չեն տալիս փոխել տվյալները.
• պահեստավորված ընթացակարգերի բացակայություն;
• տողը թվի վերածելու անհնարինությունը։

Դիտարկենք մեր մինի ձեռնարկը 1C հարցումների լեզվի հիմնական կառուցվածքների վերաբերյալ:

Հաշվի առնելով այն հանգամանքը, որ 1C-ում հարցումները թույլ են տալիս ստանալ միայն տվյալներ, ցանկացած հարցում պետք է սկսվի «SELECT» բառով: Այս հրամանից հետո նշվում են այն դաշտերը, որոնցից ցանկանում եք ստանալ տվյալներ։ Եթե ​​նշեք «*», ապա բոլոր հասանելի դաշտերը կընտրվեն: «FROM» բառից հետո նշվում է այն վայրը, որտեղից կընտրվեն տվյալները (փաստաթղթեր, գրանցամատյաններ, տեղեկատուներ և այլն):

Ստորև բերված օրինակում ամբողջ անվանացանկի անվանումներն ընտրված են «Անոմենկլատուրա» տեղեկատուից: «ԻՆՉՊԵՍ» բառից հետո նշվում են աղյուսակների և դաշտերի փոխանունները (անունները):

ԸՆՏՐԵԼ
Nomenclature.Name AS NameNomenclature
ԻՑ
տեղեկատու Անվանակարգ ՀԾ Անվանակարգ

«SELECT» հրամանի կողքին կարող եք նշել հիմնաբառեր.

• ՏԱՐԲԵՐ. Հարցումը կընտրի միայն տողերը, որոնք տարբերվում են առնվազն մեկ դաշտում (առանց կրկնօրինակների):
• ԱՌԱՋԻՆ n, Որտեղ n– ընտրվելիք արդյունքի սկզբից տողերի քանակը: Ամենից հաճախ այս կոնստրուկցիան օգտագործվում է տեսակավորման հետ համատեղ (ORDER BY): Օրինակ, երբ դուք պետք է ընտրեք վերջին փաստաթղթերի որոշակի քանակ ըստ ամսաթվի:
• ԹՈՒՅԼԱՏՐՎԱԾ Է. Այս դիզայնը թույլ է տալիս տվյալների բազայից ընտրել միայն այն գրառումները, որոնք հասանելի են ընթացիկ օգտագործողին: Եթե ​​այս հիմնաբառն օգտագործվի, օգտվողը սխալի հաղորդագրություն կստանա, եթե փորձի հարցումներ կատարել այն գրառումների վրա, որոնց հասանելի չեն:

Այս հիմնաբառերը կարող են օգտագործվել բոլորը միասին կամ առանձին:

ՓՈՓՈԽՈՒԹՅԱՆ ՀԱՄԱՐ

Այս կետը կողպում է տվյալները՝ կոնֆլիկտներից խուսափելու համար: Կողպված տվյալները չեն կարդացվի այլ կապից մինչև գործարքի ավարտը: Այս կետում դուք կարող եք նշել հատուկ աղյուսակներ, որոնք ցանկանում եք կողպել: Հակառակ դեպքում բոլորը կարգելափակվեն։ Դիզայնը տեղին է միայն ավտոմատ արգելափակման ռեժիմի համար:

Առավել հաճախ մնացորդներ ստանալիս օգտագործվում է «ՓՈՓՈԽՈՒԹՅԱՆ ՀԱՄԱՐ» կետը։ Իսկապես, երբ մի քանի օգտատերեր միաժամանակ աշխատում են ծրագրում, մինչդեռ մեկը ստանում է մնացորդները, մյուսը կարող է փոխել դրանք։ Այս դեպքում ստացված հաշվեկշիռն այլևս ճիշտ չի լինի։ Եթե ​​այս առաջարկով արգելափակեք տվյալները, ապա մինչև առաջին աշխատակիցը ստանա ճիշտ հաշվեկշիռը և դրա հետ կատարի բոլոր անհրաժեշտ մանիպուլյացիաները, երկրորդ աշխատակիցը պետք է սպասի։

ԸՆՏՐԵԼ
Փոխադարձ հաշվարկներ Աշխատակից,
Փոխադարձ հաշվարկներ Գումարը Փոխադարձ հաշվարկներ Մնացորդ
ԻՑ
կուտակային ռեգիստր Փոխադարձ հաշվարկներ աշխատողների հետ մնացորդներ AS փոխադարձ հաշվարկներ
ՓՈՓՈԽՈՒԹՅԱՆ ՀԱՄԱՐ

ՈՐՏԵՂ

Կառուցումն անհրաժեշտ է բեռնաթափված տվյալների վրա ցանկացած ընտրություն պարտադրելու համար: Ռեգիստրներից տվյալներ ստանալու որոշ դեպքերում ավելի խելամիտ է ընտրության պայմանները սահմանել վիրտուալ աղյուսակների պարամետրերում։ «WHERE»-ն օգտագործելիս նախ բոլոր գրառումները ստացվում են, և միայն դրանից հետո կիրառվում է ընտրությունը, ինչը զգալիորեն դանդաղեցնում է հարցումը։

Հետևյալը կոնկրետ պաշտոն ունեցող կոնտակտային անձանց ստանալու խնդրանքի օրինակ է: Ընտրության պարամետրն ունի հետևյալ ձևաչափը՝ &ParameterName (պարամետրի անունը կամայական է):

ԸՆՏՐՈՒԹՅՈՒՆ (ԳՈՐԾՈՎ)

Կառուցվածքը թույլ է տալիս նշել պայմանները անմիջապես հարցումի մարմնում:

Ստորև բերված օրինակում «Լրացուցիչ դաշտը» կպարունակի տեքստ՝ կախված նրանից՝ փաստաթուղթը տեղադրված է, թե ոչ.

ԸՆՏՐԵԼ
ԸնդունելությունT&U.Link,
ԸՆՏՐՈՒԹՅՈՒՆ
ԵՐԲ
ՀԵՏՈ «Փաստաթուղթը տեղադրվեց»:
ԱՅԼ «Փաստաթուղթը տեղադրված չէ...»
ԱՎԱՐՏ ՈՐՊԵՍ լրացուցիչ դաշտ
ԻՑ
Փաստաթուղթ.Ապրանքների ծառայությունների անդորրագիր AS անդորրագիրT&C

ՄԻԱՑԵՔ

Միացումները կապում են երկու աղյուսակները որոշակի կապի պայմանով:

ՁԱԽ/ԱՋ ՄԻԱՑԵՔ

LEFT միացման էությունը կայանում է նրանում, որ առաջին նշված աղյուսակը ամբողջությամբ վերցված է, իսկ երկրորդը կցվում է դրան միացման պայմանով։ Եթե ​​երկրորդում առաջին աղյուսակին համապատասխան գրառումներ չկան, ապա որպես դրանց արժեքներ փոխարինվում է NULL-ը: Պարզ ասած, հիմնական աղյուսակը առաջին նշված աղյուսակն է, և երկրորդ աղյուսակի տվյալները (եթե այդպիսիք կան) արդեն փոխարինված են դրա տվյալներին:

Օրինակ՝ ապրանքների ապրանքները պետք է ստանաք «Ապրանքների և ծառայությունների ստացում» փաստաթղթերից, իսկ գները՝ «Ապրանքների գներ» տեղեկատվական ռեգիստրից: Այս դեպքում, եթե որևէ դիրքի գինը չի գտնվել, փոխարենը փոխարինեք NULL-ը: Փաստաթղթից բոլոր կետերը կընտրվեն՝ անկախ նրանից՝ գին ունեն, թե ոչ։

ԸՆՏՐԵԼ
T&U. անվանացանկի ստացում,
Գներ.Գին
ԻՑ
Փաստաթուղթ.Ապրանքների Ծառայությունների անդորրագիր.Ապրանքների AS անդորրագիրT&C
ՆԵՐՔԻՆ ՄԻԱՑՈՒՄ
Հարց ու պատասխանի ստացման ՄԱՍԻՆ.Անվանակոչ = Գներ.Անվանակարգ

ԻՐԱՎՈՒՄ ամեն ինչ ճիշտ հակառակն է։

ԼԻՎԱԾ ՄԻԱՑՈՒՄ

Միացման այս տեսակը տարբերվում է նախորդներից նրանով, որ արդյունքում կվերադարձվեն ինչպես առաջին աղյուսակի, այնպես էլ երկրորդի բոլոր գրառումները: Եթե ​​առաջին կամ երկրորդ աղյուսակում նշված կապի պայմանի համար գրառումներ չգտնվեն, փոխարենը կվերադարձվի NULL-ը:

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

ՆԵՐՔԻՆ ՄԻԱՑՈՒՄ

INNER միացման և FULL միացման միջև տարբերությունն այն է, որ եթե աղյուսակներից գոնե մեկում գրառում չի գտնվել, ապա հարցումն այն ընդհանրապես չի ցուցադրի: Արդյունքում ապրանքների և ծառայությունների անդորրագրի փաստաթղթից կընտրվեն միայն այն ապրանքները, որոնց համար ապրանքների գների տեղեկատվական ռեգիստրում գրառումներ կան, եթե նախորդ օրինակում FULL-ը փոխարինում ենք ՆԵՐՔԻՆ:

ԽՈՒՄԲԸ ԸՍՏ

1C հարցումներում խմբավորումը թույլ է տալիս փլուզել աղյուսակի տողերը (խմբավորման դաշտերը) ըստ որոշակի ընդհանուր հատկանիշի (խմբավորման դաշտեր): Խմբավորման դաշտերը կարող են ցուցադրվել միայն ագրեգատ գործառույթների միջոցով:

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

ԸՆՏՐԵԼ
,
MAX (Գին. Գին) AS Price
ԻՑ

ԽՈՒՄԲԸ ԸՍՏ
Գներ.Անվանակոչ.ՏիպԱնոմենկլատուրա

ԱՐԴՅՈՒՆՔՆԵՐ

Ի տարբերություն խմբավորման, ընդհանուր գումարներն օգտագործելիս բոլոր գրառումները ցուցադրվում են, և դրանց ընդհանուր տողերն արդեն ավելացվում են: Խմբավորումը ցուցադրում է միայն ընդհանրացված գրառումները:

Արդյունքները կարող են ամփոփվել ամբողջ աղյուսակի համար (օգտագործելով «GENERAL» հիմնաբառը), մի քանի դաշտերի, հիերարխիկ կառուցվածք ունեցող դաշտերի համար (հիմնաբառեր «HIERARCHY», «ONLY HIERARCHY»): Ամփոփելիս անհրաժեշտ չէ օգտագործել ագրեգատ ֆունկցիաներ։

Դիտարկենք վերը նշված օրինակին նման օրինակ՝ օգտագործելով խմբավորումը: Այս դեպքում հարցման արդյունքը կվերադարձնի ոչ միայն խմբավորված դաշտերը, այլև մանրամասն գրառումները:

ԸՆՏՐԵԼ
Գներ.Անվանակատուրա.Անվանակոչի տեսակը AS անվանացանկի տեսակ,
Գներ.Գին AS գինը
ԻՑ
RegisterInformation.PricesNomenclature.SliceLast AS Prices
ԱՐԴՅՈՒՆՔՆԵՐ
ՄԱՔՍԻՄՈՒՄ (գին)
ԿՈՂՄԻՑ
Տիպի անվանացանկ

ՈՒՆԵՑՈՂ

Այս օպերատորը նման է WHERE օպերատորին, բայց օգտագործվում է միայն ագրեգատ գործառույթների համար: Այս օպերատորի կողմից օգտագործվող այլ դաշտերը պետք է խմբավորվեն: «WHERE» օպերատորը կիրառելի չէ ագրեգատ գործառույթների համար:

Ստորև բերված օրինակում ապրանքների առավելագույն գները ընտրվում են, եթե դրանք գերազանցում են 1000-ը՝ խմբավորված ըստ ապրանքի տեսակի:

ԸՆՏՐԵԼ

MAX (Գին. Գին) AS Price
ԻՑ
RegisterInformation.PricesNomenclature.SliceLast AS Prices
ԽՈՒՄԲԸ ԸՍՏ
Գներ.Անվանակոչ.ՏիպԱնոմենկլատուրա
ՈՒՆԵՑՈՂ
MAX (Գներ. Գին) > 1000

ԴԱՍԱՎՈՐԵԼ ԸՍՏ

«ORDER BY» օպերատորը տեսակավորում է հարցման արդյունքը: Ապահովելու համար, որ գրառումները թողարկվում են հետևողական հերթականությամբ, օգտագործվում է AUTO-ORDER: Պարզունակ տեսակները դասակարգվում են ըստ սովորական կանոնների։ Հղումների տեսակները դասավորված են ըստ GUID-ի:

Աշխատակիցների անուններով տեսակավորված ցուցակ ստանալու օրինակ.

ԸՆՏՐԵԼ
Employees.Name AS Անուն
ԻՑ
տեղեկատու Աշխատակիցներ AS Employees
ԴԱՍԱՎՈՐԵԼ ԸՍՏ
Անուն
ԱՎՏՈՊԱՏՎԵՐ

1C հարցումների լեզվի այլ կառույցներ

• ՄԻԱՑԵՔ- երկու հարցումների արդյունքները մեկում:
• ՄԻԱՑԵՔ ԲՈԼՈՐԻՆ– նման է JOIN-ին, բայց առանց նույնական տողերի խմբավորման:
• ԴԱՏԱՐԿ ՍԵՂԱՆ- երբեմն օգտագործվում է հարցումները միացնելիս դատարկ ներդիր աղյուսակը նշելու համար:
• ԴՆԵԼ- ստեղծում է ժամանակավոր աղյուսակ 1C բարդ հարցումները օպտիմալացնելու համար: Նման հարցումները կոչվում են խմբաքանակի հարցումներ:

Հարցման լեզվի առանձնահատկությունները

• ԵՆԹԱԴՐՈՒՄկրճատում է տողը նշված դիրքից նշված թվով նիշերով:
• ՏԱՐԻ… ԵՐԿՐՈՐԴթույլ է տալիս ստանալ թվային տեսակի ընտրված արժեքը: Ներածման պարամետրը ամսաթիվ է:
• ԺԱՄԱՆԱԿԱՇՐՋԱՆԻ ՍԿԶԲԸ ԵՎ ԱՎԱՐՏԸօգտագործվում են ամսաթվերի հետ աշխատելիս: Որպես լրացուցիչ պարամետր նշվում է ժամանակաշրջանի տեսակը (ՕՐ, ԱՄԻՍ, ՏԱՐԻ և այլն):
• ԱՎԵԼԱՑՆԵԼթույլ է տալիս ամսաթվից ավելացնել կամ հանել որոշակի տեսակի նշված ժամը (ԵՐԿՐՈՐԴ, ՐՈՊԵ, ՕՐ և այլն):
• ԺԱՄԱՆԱԿԻ ՏԱՐԲԵՐՈՒԹՅՈՒՆորոշում է երկու ամսաթվերի տարբերությունը՝ նշելով ելքային արժեքի տեսակը (ՕՐ, ՏԱՐԻ, ԱՄԻՍ և այլն):
• ԱՆՈՒՐ Էփոխարինում է բաց թողնված արժեքը նշված արտահայտությամբ:
• ՆԵՐԿԱՅԱՑՆՈՒՄ և ՆԵՐԿԱՅԱՑՆՈՒՄ ՀՂՈՒՄՆԵՐստացեք նշված դաշտի տողերի ներկայացումը: Դրանք օգտագործվում են համապատասխանաբար ցանկացած արժեքների և միայն հղման արժեքների համար:
• ՏԵՍԱԿ, ԱՐԺԵՔԻ ՏԵՍԱԿօգտագործվում են մուտքային պարամետրի տեսակը որոշելու համար:
• ՀՂՈՒՄտրամաբանական համեմատական ​​օպերատոր է հատկանիշի արժեքի տեսակի համար:
• EXPRESSօգտագործվում է արժեքը ցանկալի տեսակի փոխարկելու համար:
• Ամսաթիվ ԺԱՄԱՆԱԿթվային արժեքներից ստանում է «Ամսաթիվ» տիպի արժեք (տարի, ամիս, օր, ժամ, րոպե, վայրկյան):
• ԻՄԱՍՏՈՒԹՅՈՒՆ 1C հարցումում այն ​​օգտագործվում է նախապես սահմանված արժեքներ նշելու համար՝ տեղեկատուներ, թվարկումներ, բնութագրերի տեսակների պլաններ: Օգտագործման օրինակ. Որտեղ LegalIndividual = Value (Enumeration.LegalIndividual.Individual)«.

Հարցման ստեղծող

1C-ով հարցումներ ստեղծելու համար կա շատ հարմար ներկառուցված մեխանիզմ՝ հարցման դիզայներ։ Այն պարունակում է հետևյալ հիմնական ներդիրները.

• «Սեղաններ և դաշտեր» - պարունակում է ընտրվելիք դաշտերը և դրանց աղբյուրները:
• «Հղումներ» - նկարագրում է ՄԻԱՑՄԱՆ կառուցվածքի պայմանները:
• «Խմբավորում» - պարունակում է խմբավորումների կառուցվածքների և դրանց կողմից ամփոփված դաշտերի նկարագրությունը:
• «Պայմաններ» - պատասխանատու է հարցումի տվյալների ընտրության համար:
• «Ընդլայնված» - հարցման լրացուցիչ պարամետրեր, ինչպիսիք են «SELECT» հրամանի հիմնաբառերը և այլն:
• «Միացումներ / Անանուններ» - նշվում են աղյուսակների միացման հնարավորությունները և սահմանվում են կեղծանունները («ԻՆՉՊԵՍ» կառուցվածքը):
• «Պատվեր» - պատասխանատու է հարցումների արդյունքների տեսակավորման համար:
• «Ընդամենը» - նման է «Խմբավորում» ներդիրին, բայց օգտագործվում է «TOTALS» կառուցման համար:

Հարցման տեքստն ինքնին կարելի է դիտել՝ սեղմելով ներքևի ձախ անկյունում գտնվող «Պահանջել» կոճակը: Այս ձևով այն կարելի է ուղղել ձեռքով կամ պատճենել:

Հարցման վահանակ

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

Դուք կարող եք ներբեռնել հարցման վահանակը ITS սկավառակի վրա կամ .

«Դեր» կոնֆիգուրացիայի օբյեկտը տալիս է մի շարք իրավունքներ կոնֆիգուրացիայի օբյեկտների վրա գործողությունների (գործողությունների):

Դեր «Լրիվ իրավունքներ».

Սա ուղղակի դեր է (նախապես սահմանված չէ), որն ունի բոլոր տեսակի իրավունքների բոլոր կոնֆիգուրացիայի օբյեկտների վանդակները:

Նրա տարբերությունը մյուս դերերից «Ադմինիստրացիոն» իրավունքի առկայությունն է։

Եթե ​​ստեղծվել է առնվազն մեկ օգտվող, համակարգը սկսում է ստուգել «Կառավարման» իրավունքը. առնվազն մեկ օգտվող պետք է ունենա այն:

Սահմանափակել մուտքը ռեկորդային մակարդակով

Row Level Security (RLS) - Սահմանափակում ռեկորդային մակարդակում:

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

• դերեր,
• նիստի ընտրանքներ,
• ֆունկցիոնալ ընտրանքներ,
• արտոնյալ ընդհանուր մոդուլներ,
• հիմնաբառը թույլատրվում է հարցման լեզվով:

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

1C-ում մուտքի սահմանափակումների տեխնիկական իրականացում

1C-ն ստեղծում է հարցում DBMS-ին: Սերվերի կլաստերը հարցումին ավելացնում է WHERE բաժին, որը պարունակում է RLS-ով մուտքը սահմանափակելու պայմանի տեքստը, այնուհետև այս հարցումն ուղարկվում է DBMS, արդյունահանված տվյալները վերադարձվում են 1C հաճախորդին:

Այս մեխանիզմը կաշխատի հաճախորդի ցանկացած խնդրանքով.

• հաշվետվություններում
• դինամիկ ցուցակներում և կանոնավոր ցուցակների ձևերում
• պատահական հարցումներով:

Մեխանիզմի նման իրականացումը մեծապես ազդում է աշխատանքի վրա:

Մուտքի սահմանափակումները շրջանցելու ուղիներ.

Խոշոր ռեսուրսների ինտենսիվ գործողություններում (օրինակ՝ փաստաթղթերի վերահրապարակման մշակում) կոդի մի մասը կարող է տեղափոխվել արտոնյալ մոդուլներ:

Ա) արտոնյալ մոդուլ ընդհանուր մոդուլ է «Արտոնյալ» դրոշով հատկությունների մեջ:

Դրա յուրահատկությունը կայանում է նրանում, որ դրանում առկա կոդը կատարվում է առանց մուտքի հսկողության, այդ թվում՝ RLS-ի։

Բ) նաև արտոնյալռեժիմը կարող է միացված լինել փաստաթղթերի օբյեկտների մոդուլների համար. Դա արվում է փաստաթղթի հատկություններով, դրոշակով

• Արտոնյալ ռեժիմ պահելիս
• Արտոնյալ ռեժիմ՝ չպլանավորելիս

Գ) մեթոդ SetPrivilegedMode ()

Համակարգի հրաման, որը թույլ է տալիս արտոնյալ դարձնել ցանկացած մոդուլի կոդի մի մասը:

Կոդի հաջորդ տողից կգործի կատարման արտոնյալ ռեժիմը։

Այն կգործի մինչև այս ռեժիմն անջատելու տողը կամ մինչև ընթացակարգի/գործառույթի ավարտը

(Ճիշտ);

// այստեղ ցանկացած ծածկագիր կկատարվի առանց իրավունքների վերահսկման և RLS

SetPrivilegedMode(Սուտ); // կամ ընթացակարգի ավարտը / գործառույթը

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

Եթե ​​ընթացակարգի կամ ֆունկցիայի մեթոդի մեջ զանգեր է կատարում SetPrivilegedMode(False) ավելի շատ, քան կատարված մեթոդի կանչերը SetPrivilegedMode(ճշմարիտ), ապա բացառություն է նետվելու

Գործառույթ Արտոնյալ ռեժիմ() վերադարձնում է True, եթե արտոնյալ ռեժիմը դեռ միացված է, և False, եթե արտոնյալ ռեժիմն ամբողջությամբ անջատված է: Այն չի վերլուծում որոշակի ֆունկցիայի արտոնյալ ռեժիմի կարգավորումների քանակը:

Բոլոր կոչված ընթացակարգերը և գործառույթները նույնպես կկատարվեն արտոնյալ ռեժիմով:

Հնարավոր է նաև արտոնյալ նիստ սկսել։ Սա նիստ է, որում արտոնյալ ռեժիմը սահմանված է համակարգի հենց սկզբից: Միաժամանակ շահագործման ընթացքում մեթոդ Արտոնյալ ռեժիմ() միշտ կվերադարձնի True, և արտոնյալ ռեժիմն անջատելու հնարավորությունը չի ապահովվում: Միայն ադմինիստրատիվ իրավունքներ ունեցող օգտատերը (ադմինիստրատիվ իրավունք) կարող է սկսել արտոնյալ նստաշրջան: Նիստը կարող է սկսվել օգտագործելով հրամանի տող անջատիչը՝ հաճախորդի հավելվածը գործարկելու համար UsePrivilegedMode կամ infobase կապի տողի պարամետրը prmod:

Բնականաբար հարց է ծագում՝ ինչո՞ւ, ուրեմն, ընդհանրապես մուտքի սահմանափակումներ սահմանել, եթե դա կարելի է այդքան հեշտությամբ շրջանցել:

Անվտանգ ռեժիմ.

Այո, հնարավոր է գրել արտաքին մշակում արտոնյալ կատարման ռեժիմով և բեռնաթափել/կոռումպացված տվյալներ։ Դա կանխելու համար համակարգն ունի գլոբալ համատեքստի մեթոդ

Սահմանեք SafeMode-ը().

Անվտանգ ռեժիմը, ի թիվս այլ բաների, անտեսում է արտոնյալ ռեժիմը:

Այն պետք է սահմանվի նախքան արտաքին մշակողներին ծրագրային կերպով կանչելը կամ դրանց մոդուլներից արտահանման ընթացակարգերն ու գործառույթները:

Գործարկման ժամանակ արգելված գործողություններ կատարելիս բացառություն է բացում:

Բացի այդ, օգտատերերի համար դուք կարող եք անջատել դերերի կարգավորումների մակարդակով արտաքին հաշվետվությունների և մշակման ինտերակտիվ գործարկման հնարավորությունը:

Մուտքի սահմանափակման կարգավորում

RLS-ը կարող է կազմաձևվել միայն իրավունքների համար՝

• կարդալ (ընտրել)
• ավելացում (ներդիր)
• փոփոխություն (թարմացում)
• ջնջում (ջնջում)

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

Ավելացնել գործողության համարտվյալների հասանելիության սահմանափակումը պետք է համապատասխանի այն օբյեկտին, որը նախատեսվում է գրել տվյալների բազայում:

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

Մնացած բոլոր իրավունքների համար այս տարբերակը հասանելի չէ:

Ավելացնենք նոր սահմանափակում «Անոմենկլատուրա» տեղեկագրքի «կարդալու» իրավունքի համար. Կբացվի դաշտերի ցանկ, որոնց համար կարող եք կարգավորել ավելացված սահմանափակումը:

Սա նշանակում է, որ եթե փորձեք մուտք գործել վանդակում նշված դաշտեր, սահմանափակումը կաշխատի, բայց եթե փորձեք մուտք գործել չնշված դաշտեր, սահմանափակումը չի աշխատի:

Եթե ​​դուք ընտրում եք դրոշը Այլ դաշտեր», սահմանափակումը կսահմանվի աղյուսակի բոլոր դաշտերի համար, բացառությամբ այն դաշտերի, որոնց համար սահմանափակումները հստակորեն սահմանված են:

*Առանձնահատկություն՝ ավելացնելու, փոփոխելու, ջնջելու իրավունքների համար.

• Սահմանափակումը կարող է կազմաձևվել միայն բոլոր դաշտերի համար:
• Կարող է լինել միայն մեկ սահման.

«Կարդալ» իրավունքի համար կարող եք մի քանի պայման դնել, դրանք կմիավորվեն «AND» տրամաբանական օպերատորի հետ։

Հետևյալ տեսակների տվյալների բազայի օբյեկտների սահմանափակումների դեպքում սահմանափակման հիմնական տվյալների օբյեկտի ոչ բոլոր դաշտերը կարող են օգտագործվել.

• կուտակային ռեգիստրներում մուտքի սահմանափակումները կարող են պարունակել միայն հիմնական սահմանափակման օբյեկտի չափումներ.
• Սահմանափակումների հաշվառման գրանցամատյաններում կարող եք օգտագործել միայն սահմանափակման հիմնական օբյեկտի մնացորդի չափումները

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

Մուտքի սահմանափակումներ սահմանելու մեխանիզմը.

1C:Enterprise-ում տվյալների բազայում պահվող տվյալների վրա ցանկացած գործողություն, ի վերջո, հանգեցնում է տվյալների բազա մուտք գործելու՝ տվյալների ընթերցման կամ փոփոխման որոշակի խնդրանքով: Տվյալների բազա հարցումների կատարման ժամանակ 1C:Enterprise-ի ներքին մեխանիզմները սահմանում են մուտքի սահմանափակումներ: Որտեղ:

• Իրավունքների ցանկը կազմված է(կարդալ, ավելացնել, թարմացնել, ջնջել), տվյալների բազայի աղյուսակների ցանկը և այս հարցման կողմից օգտագործվող դաշտերի ցանկը:
• Ընթացիկ օգտվողի բոլոր դերերից ընտրեք մուտքի սահմանափակումներհարցումին ներգրավված բոլոր իրավունքների, աղյուսակների և դաշտերի տվյալները: Ավելին, եթե որևէ դեր չի պարունակում որևէ աղյուսակի կամ դաշտի տվյալների մուտքի սահմանափակումներ, ապա դա նշանակում է, որ ցանկացած գրառումից պահանջվող դաշտերի արժեքները հասանելի են այս աղյուսակում: Այլ կերպ ասած, տվյալների մուտքի սահմանափակման բացակայությունը նշանակում է, որ կա WHERE True սահմանափակում:
• Ստացեք բոլոր նստաշրջանի պարամետրերի և ֆունկցիոնալ ընտրանքների ընթացիկ արժեքներըմասնակցել ընտրված սահմանափակումներին:

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

Նույն դերից բխող սահմանափակումները զուգակցվում են AND գործողության հետ:

Տարբեր դերերից ստացված սահմանափակումները զուգակցվում են OR գործողության հետ:

Կառուցված պայմանները ավելացվում են SQL հարցումներին, որոնցով 1C:Enterprise-ը մուտք է գործում DBMS: Մուտքի սահմանափակման պայմանների կողմից տվյալներ մուտք գործելիս իրավունքների ստուգում չի կատարվում (ոչ մետատվյալների օբյեկտների, ոչ տվյալների բազայի օբյեկտների նկատմամբ): Ավելին, պայմանների ավելացման մեխանիզմը կախված է «բոլորը» կամ «թույլատրված» սահմանափակումների գործողության ընտրված ռեժիմից:

*Առանձնահատկություն. Եթե օգտատերը մուտք ունի մի քանի դերեր՝ կազմաձևված սահմանափակումներով մեկ օբյեկտի գրառումների մակարդակով, ապա այս դեպքում սահմանափակումների պայմանները ավելացվում են «OR» տրամաբանական գործողությամբ։ Այլ կերպ ասած, օգտագործողի թույլտվությունները կուտակային են:

Սա հանգեցնում է հետևյալ եզրակացության. թույլ մի տվեք, որ սահմանափակվի մուտքը մեկ օբյեկտ տարբեր դերերում, քանի որ այս դեպքում հարցման տեքստը շատ ավելի կբարդանա, և դա կազդի աշխատանքի վրա:

Ամբողջ ճանապարհով:

Երբ սահմանափակումներ են սահմանվում՝ օգտագործելով «բոլորը» մեթոդը, պայմանները և դաշտերը ավելացվում են SQL հարցումներին, որպեսզի 1C:Enterprise-ը կարողանա տեղեկատվություն ստանալ այն մասին, թե տվյալ օգտատիրոջ համար արգելված տվյալները օգտագործվել են տվյալների բազայի հարցումը կատարելու գործընթացում, թե ոչ: . Եթե ​​արգելված տվյալներ են օգտագործվել, ապա հարցումը դադարեցվում է մուտքի խախտման պատճառով:

Մուտքի սահմանափակումների սահմանումը «բոլորը» մեթոդով սխեմատիկորեն ներկայացված է նկարում.

«Թույլատրված» մեթոդ.

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

Տվյալների հասանելիության սահմանափակումները դրվում են տվյալների բազայի օբյեկտների վրա, երբ 1C:Enterprise-ը մուտք է գործում տվյալների բազա:

1C:Enterprise-ի հաճախորդ-սերվեր տարբերակում սահմանափակումներ են կիրառվում 1C:Enterprise սերվերի վրա:

Այնուամենայնիվ, այս տարբերակը (ԹՈՒՅԼԱՏՐՎԱԾ) չի աշխատի, եթե հարցման մեջ անդրադառնանք աղյուսակին, որի համար մուտքի սահմանափակումները կազմաձևված չեն, բայց որտեղ կան աղյուսակի տողերի հղումներ կազմաձևված սահմանափակումներով: Այս դեպքում հարցման արդյունքը կլինի «<Объект не найден>……» հղման դաշտի արժեքի փոխարեն:

Եթե ​​դուք հաշվետվություն եք մշակում կամ մշակում եք՝ օգտագործելով ընդհանուր կամ հատուկ կազմաձևման հարցումներ, միշտ ստուգեք «Թույլատրված» դրոշըորպեսզի հաշվետվությունն աշխատի ցանկացած օգտագործողի տակցանկացած իրավունքների փաթեթով:

Տվյալների բազայից օբյեկտների ընթերցման դեպքում հնարավոր չէ սահմանել «Թույլատրված» դրոշը։ Ուստի անհրաժեշտ է կարգավորել ընտրանքները օբյեկտների ընթերցման համար՝ հաշվի առնելով մուտքի իրավունքի հնարավոր սահմանափակումներըօգտագործողի համար. Օբյեկտային տեխնոլոգիայում միայն թույլատրելի տվյալներ ստանալու միջոցներ չկան:

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

Պրակտիկա 1. Հարցման ստեղծող RLS կարգավորումներում:

Եկեք կազմենք «WHERE» բաժնի տեքստը գրացուցակի հարցում: Դուք կարող եք օգտագործել հարցումների ստեղծողը:
Կոնստրուկտորը կտրված է:

Ներդիր «Սեղաններ»

Հիմնական աղյուսակը կլինի այն օբյեկտի աղյուսակը, որի համար կարգավորվում է սահմանափակումը:

Կարող եք նաև ընտրել այլ աղյուսակներ և ստեղծել տարբեր հարաբերություններ նրանց միջև «Հարաբերություններ» ներդիրում:

Պայմանների ներդիր

Այստեղ դուք կարող եք կարգավորել մուտքի սահմանափակման փաստացի պայմանները:

Եկեք պայմաններ ավելացնենք բաժնետոմսերի ցուցակի գրացուցակի «Գին» հատկանիշի համար՝ աղյուսակի բոլոր դաշտերում «կարդալու» իրավունքի համար։

«Անոմենկլատուրա WHERE անվանակարգ. Գին > 500»

Տեսնենք, թե ինչպես է գործում այս պարզ կանոնը։ Հղման աղյուսակը պարունակում է հետևյալ տարրերը.

Մուտքի սահմանափակումը դնելուց հետո աղյուսակը ցույց կտա միայն այն տարրերը, որոնք բավարարում են պայմանը.

Խմբերը նույնպես անհետացել են։ Փոխեք սահմանափակումների տեքստը

«Անոմենկլատուրա WHERE Անվանակարգ. Գինը > 500

ԿԱՄ անվանակարգ: Սա խումբ է»

Դե, հիմա ահա թե ինչ է ձեզ անհրաժեշտ:

Եթե ​​ցուցակի կարգավորումներից հանեք «կոդ» դաշտի ցուցադրումը, կցուցադրվեն գրացուցակի բոլոր տարրերը, այսինքն. սահմանափակումը չգործեց. Եթե ​​սահմանեք «Կոդ» դաշտի ցուցադրումը, սահմանափակումը կգործի:

Միևնույն ժամանակ, չնայած այն հանգամանքին, որ որոնման տարրը տեսանելի է ցուցակի դաշտում, դրա ձևը չի կարող բացվել, քանի որ հատկանիշի վրա սահմանափակում է դրված: Նույնը կամայական հարցումում՝ երբ փորձում եք ստանալ «սահմանափակ» հատկանիշ, մուտքի սխալ կլինի։

Եթե ​​փորձեք ծրագրային կերպով ստանալ «սահմանափակված» հենակետերը, ապա մուտքի սխալ նույնպես կբարձրացվի:

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

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

Մուտքի սահմանափակումը սահմանելուց հետո իրավունքների ցանկում տողի ցուցադրումը փոխվեց՝ այն դարձավ մոխրագույն և հայտնվեց պատկերակ։

Մուտքի կազմաձևման սահմանափակումներ (RLS):

• Ամփոփման բաժին չկա;
• Դուք չեք կարող մուտք գործել վիրտուալ ռեգիստրի աղյուսակներ.
• Դուք չեք կարող հստակորեն օգտագործել պարամետրերը.
• Ենթահղումները կարող են օգտագործվել any>/span> հարցումների լեզվական հարմարություններ, բացառությամբ՝
  • օպերատոր ՀԻԵՐԱՐԽԻԱՅՈՒՄ;
  • առաջարկում է ԱՐԴՅՈՒՆՔՆԵՐ;
  • ներկառուցված հարցման արդյունքներ չպետք է պարունակի աղյուսակային մասեր>/span>;
  • վիրտուալ սեղաններ, մասնավորապես մնացորդները և շրջանառությունները

Պրակտիկա 2. Անվանակարգ՝ ընթացիկ գնով:

Կատարեք մուտքի սահմանափակում, եթե ձեզ անհրաժեշտ է ցուցադրել ընթացիկ գինը որոշակի արժեքից մեծ ապրանք, օրինակ՝ 100:

Լուծում:

Մենք ավելացնում ենք մուտքի սահմանափակման նոր կանոն «Անոմենկլատուրա» տեղեկատուի համար «կարդալու» իրավունքի համար:
Ընտրեք «այլ դաշտեր»:
Կառուցիչում ավելացրեք ներդիր հարցում: Դրանում ընտրեք տեղեկատվական ռեգիստրի աղյուսակը «Ապրանքների գներ»:
«Պատվեր» ներդիր չկա. սա հարցումների ստեղծողի առանձնահատկությունն է՝ մուտքի սահմանափակման հարցում ստեղծելու համար:
«Ընդլայնված» ներդիրում դրեք «առաջին 999999999», հայտնվել է «պատվեր» ներդիրը:
Կարգավորեք պատվերը «Ժամանակաշրջան» դաշտում՝ նվազման կարգով:
Այնուհետև մենք ստեղծեցինք հիմնական աղյուսակի կապը ենթահղման հետ՝ հղումով։

Մուտքի սահմանափակման կաղապարներ.

Պրակտիկա 3. «Կապալառուների» սահմանափակումն ըստ արժեքի հաստատունի:

Սահմանեք մուտքի սահմանափակում Կողմերի գրացուցակի համար՝ ըստ Constant-ում պահվող արժեքի:

Բացի այդ, դուք պետք է սահմանափակում սահմանեք բոլոր օբյեկտների համար, որոնք օգտագործում են «Կապալառուներ» գրացուցակը մանրամասների մեջ:

Լուծում

«Հաշիվներ» տեղեկատու գրքի համար, «կարդալու» իրավունքի համար, մենք սահմանափակում կսահմանենք՝ «Պայմաններ» բաժնում հաստատունին ներդիր հարցում ավելացնելով: Մի մոռացեք այս խմբի մասին:

Մենք տեսնում ենք խնդիրը, Counterparties գրացուցակը ճիշտ է զտված, և «Counterparty» հատկանիշով բոլոր փաստաթղթերը ցուցադրվում են, որոշները «կոտրված» հղումներով «Counterparty» հատկանիշում:

Այժմ դուք պետք է կարգավորեք մուտքի սահմանափակումը բոլոր օբյեկտների համար՝ օգտագործելով «Հաշիվներ» հղումը: Եկեք դրանք գտնենք «որոնում դեպի օբյեկտի հղումներ» ծառայության միջոցով։

Եկեք պատճենենք և մի փոքր փոփոխենք RLS պայմանի տեքստը «Կողմնակիցներ» գրացուցակից: Դա պետք է արվի այնքան անգամ, որքան հայտնաբերված առարկաներ կան:

Կամ օգտագործեք Մուտքի սահմանափակումների օրինակը՝ կոդի կրկնօրինակման հետ կապված խնդիրներից խուսափելու համար:

Մուտքի սահմանափակման ձևանմուշները կազմաձևված են դերի մակարդակով և կարող են օգտագործվել խմբագրված դերի ցանկացած օբյեկտի համար:

Դուք կարող եք մուտքի սահմանափակման ցանկացած տեքստ տեղադրել կաղապարի մեջ: Կաղապարը կանչվում է «#» նշանի միջոցով։ Օրինակ՝ #TemplateContractor։

1C-ում #-ի միջոցով հրահանգները գրվում են նախապրոցեսորին: Մուտքի սահմանափակման կարգավորումների կատարման համատեքստում հարթակը կաղապարի զանգի տեքստը փոխարինում է կաղապարի տեքստով:

Տեքստը WHERE բառից հետո տեղափոխենք «TemplateContractor» ձևանմուշ, բացառությամբ ThisGroup-ի մասին տեքստի։

Մուտքի սահմանափակման կաղապարների պարամետրերը:

Շարունակենք լուծել խնդիրը 2.

Խնդիրն այժմ այն ​​է, որ գրացուցակի հիմնական աղյուսակը կոչվում է «կոնտրկողմ», փաստաթղթում «Invoice»: Գրացուցակի ստուգված դաշտը կոչվում է «հղում», փաստաթղթում՝ «Կողմակից»:

Կաղապարի տեքստում հիմնական աղյուսակի անունը փոխեք «# CurrentTable»

«#CurrentTable»-ը նախապես սահմանված պարամետր է:

Իսկ կետի միջոցով նշում ենք մուտքագրման պարամետրի թիվը՝ “։#Parameter(1)

«#Parameter»-ը նույնպես նախապես սահմանված արժեք է։ Կարող է պարունակել կամայական թվով մուտքային պարամետրեր: Դրանք հիշատակվում են սերիական համարով։

Գրացուցակի մուտքի սահմանափակման տեքստում մենք նշում ենք հետևյալը.

Փաստաթղթի համար հետևյալը.

«Ապրանքների վաճառք WHERE #TemplateContractor («Կապալառու»)»

Մուտքի սահմանափակման ձևանմուշը կանչելիս պարամետրերը պետք է փոխանցվեն դրան միայն որպես String, այսինքն՝ չակերտներով:

Հիմնական աղյուսակ - Անվանակարգ

Կաղապարի տեքստը հետևյալն է.

#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)

Կաղապարի տեքստը պարունակում է տեքստի մի մասը տվյալների հասանելիության սահմանափակման լեզվով և կարող է պարունակել պարամետրեր, որոնք ընդգծված են «#» նշանով:

«#» նիշին կարող է հաջորդել.

• Հիմնաբառերից մեկը.
  • Պարամետր, որին հաջորդում է փակագծերում դրված կաղապարի պարամետրի թիվը.
  • CurrentTable - նշանակում է տեքստի մեջ տեղադրել աղյուսակի ամբողջական անվանումը, որի համար ստեղծվում է սահմանափակումը.
  • CurrentTableName- նշանակում է աղյուսակի լրիվ անվանման տեքստի մեջ (որպես տողային արժեք, չակերտների մեջ), որի վրա կիրառվում է հրահանգը, ներկառուցված լեզվի ընթացիկ տարբերակում.
  • NameCurrentPermission– պարունակում է իրավունքի անվանումը, որի համար կատարվում է ընթացիկ սահմանափակումը.
• Կաղապարի պարամետրի անվանումը – նշանակում է համապատասխան կաղապարի պարամետրի սահմանափակումը տեքստի մեջ մտցնել.
• «#» խորհրդանիշը ցույց է տալիս տեքստի մեջ մեկ «#» նշանի տեղադրումը:

Մուտքի սահմանափակման արտահայտությունը կարող է պարունակել.

• Մուտքի սահմանափակման ձևաչափը, որը նշված է ձևաչափում #TemplateName («Կաղապարի պարամետրի արժեքը 1», «Կաղապարի պարամետրի արժեքը 2»,...). Կաղապարի յուրաքանչյուր պարամետր կցվում է կրկնակի չակերտների մեջ: Եթե ​​պարամետրի տեքստում անհրաժեշտ է նշել կրկնակի չակերտի նիշ, օգտագործեք երկու կրկնակի չակերտ:
• Function StrContains (որտեղ մենք փնտրում ենք, ինչ ենք մենք փնտրում). Ֆունկցիան նախատեսված է WhatLooking for-ի երևույթը որոնելու WhereLooking for տողի մեջ: Վերադարձնում է True, եթե համընկնում է, Սխալ է հակառակ դեպքում:
• + օպերատորը տողերի միացման համար:

Կաղապարի տեքստը խմբագրելու հարմարության համար «Սահմանափակման կաղապարներ» ներդիրում դերային ձևի վրա սեղմեք «Սահմանել կաղապարի տեքստ» կոճակը: Բացվող երկխոսության մեջ մուտքագրեք ձևանմուշի տեքստը և սեղմեք OK:

Նրանք չեն կարող տեղադրվել օգտագործելով setParameter ()կամ նման մի բան:

Այս դեպքում պարամետրերն են.

• Նստաշրջանի ընտրանքներ
• Ֆունկցիոնալ ընտրանքներ

Մուտքի սահմանափակման հարցումում նստաշրջանի պարամետրերի ընթերցումը տեղի է ունենում արտոնյալ ռեժիմով, այսինքն՝ առանց դրանց հետ աշխատելու իրավունքների վերահսկման:

Պրակտիկա 4. Մատչելիություն «ձեր» գործընկերներին

Անհրաժեշտ է սահմանել ներկայիս օգտագործողի «իրենց» գործընկերներին մուտքի սահմանափակում:

Գոյություն ունի «Users» գրացուցակ, «Counterparties» գրացուցակ, անհրաժեշտ «Counterparty» փաստաթղթերով:

Ընթացիկ օգտատերը պետք է տեսնի տվյալներ միայն այն գործընկերների համար, որոնց համար կապ է հաստատվել իր հետ:

Հաղորդակցությունը նույնպես պետք է կարգավորվի:

Հնարավոր տարբերակներ.

Օգտագործող + կոնտրագենտ կապերի ստեղծում

• Մանրամասները գրացուցակի կոնտրագենտների մեջ
• Տեղեկատվական ռեգիստր

Խնդրի հնարավոր լուծումները.

• Օգտատիրոջը հաստատունում պահելը վատ տարբերակ է, հաստատունը հասանելի է բոլոր օգտագործողների համար:
• Ընթացիկ օգտագործողի գործընկերների ֆիքսված զանգվածը նստաշրջանի պարամետրերում պահելը լավ տարբերակ չէ, կարող են լինել բազմաթիվ կոնտրագենտներ:
• Պահպանեք ընթացիկ օգտատիրոջ սեսիայի պարամետրերում, այնուհետև խնդրեք ստանալ «իր» գործընկերների ցուցակը՝ ընդունելի տարբերակ:
• Այլ տարբերակներ.

Լուծում.

Եկեք ստեղծենք նոր նիստի պարամետր «CurrentUser» և գրենք դրա լրացումը նիստի մոդուլում։

Ստեղծենք տեղեկատվական ռեգիստր «Կառավարիչների և կոնտրագենտների նամակագրություն»

Եկեք ստեղծենք նոր դեր և դրանում մուտքի նոր սահմանափակում «Անդորագրի» փաստաթղթի համար։

Հարցման տեքստում մենք կկապենք հիմնական աղյուսակը տեղեկատվական ռեգիստրի հետ՝ ըստ Contractor = Contractor և Manager = &CurrentUser: Կապի տեսակը Ներքին.

Հնարավորության դեպքում ավելի լավ է խուսափել մուտքի սահմանափակման տեքստերում տեղադրված հարցումներից, քանի որ այն կկատարվի ամեն անգամ, երբ այս օբյեկտի տվյալները կարդում են տվյալների բազայից:

Մենք ստուգում ենք՝ սահմանափակումները գործում են

* Առանձնահատկություն. Եթե ռեգիստրում փոխեք օգտվողի կոնտրագենտների ցուցակը, մուտքի սահմանափակումներն ուժի մեջ կմտնեն անմիջապես՝ առանց օգտվողի նիստը վերսկսելու:

Պրակտիկա 5. Փոփոխության ամսաթիվ չկա:

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

Եկեք ստեղծենք «ChangeBarDateDate» տեղեկատվական ռեգիստր՝ User, RestrictedDate ռեսուրսով:

Լուծման տրամաբանությունը կառուցենք այսպես.

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

Ակնհայտ է, որ նման սահմանաչափը կարող է կազմաձևվել տվյալների բազայի օբյեկտների համար, որոնք որոշակի դիրք ունեն ժամանակի առանցքի վրա: Դա կարող է լինել

• Փաստաթղթեր
• Պարբերական տեղեկատվական ռեգիստրներ

Եկեք ստեղծենք նոր դեր «Restrictions By ChangeProhibitionDate»:

Դրանում «Անդորագրի հաշիվ» փաստաթղթի համար ճիշտ «փոփոխության» համար մենք կավելացնենք մուտքի նոր սահմանափակում։

Պարամետրը նշված է բոլոր դաշտերի համար:

Սահմանափակման տեքստը հետևյալն է.

Ստացական հաշիվ-ապրանքագիր փաստաթղթից.

ChangeProhibitionDates.ProhibitionDate AS ProhibitionDate
ԻՑ

ՆԵՐՔԻՆ ՄԻԱՑՈՒՄ (ԸՆՏՐԵԼ
MAXIMUM (ChangeProhibitionDate.User) AS օգտվող
ԻՑ
Տեղեկատվության գրանցամատյան Փոփոխությունների արգելման ամսաթվերը Փոփոխությունների արգելման ամսաթիվը.
ՈՐՏԵՂ
(ChangeProhibitionDates.User = &CurrentUser
ORChangeProhibitionDate.User = VALUE(Reference.users.NullReference))) AS OT_User
BYChangeProhibitedDate.User = OT_User.User) AS Subquery
Invoice Invoice.Date > NestedRequest.BanDate

Մենք ստուգում ենք՝ սահմանափակումն աշխատում է։

Օգտագործելով նախապրոցեսորի հրահանգները

#Եթե պայման1 #Այնուհետև

Հարցրեք հատված 1

#ElseIf Condition2 #Then

Հարցրեք հատված 2

#Հակառակ դեպքում

Հարցրեք հատված 3

#ՎերջԵթե

Պայմաններում դուք կարող եք օգտագործել տրամաբանական գործողություններ (և. կամ, ոչ և այլն) և մուտք գործել նստաշրջանի պարամետրերին:

Այս մոտեցումը մուտքի սահմանափակումների համատեքստում հարմար է, քանի որ, կախված պայմաններից, կկազմվի հարցման ավելի կարճ տեքստ: Ավելի պարզ հարցումն ավելի քիչ է բեռնում համակարգը:

Բացասական կողմն այն է, որ հարցումների կոնստրուկտորը չի աշխատի նման տեքստի հետ:

* Առանձնահատկություն.

Ի տարբերություն 1C:Enterprise նախապրոցեսորի հրահանգների մուտքի սահմանափակման տեքստերում, «Then» օպերատորին նախորդում է հեշ նշանով — #Then

Պրակտիկա 6. Անջատեք «Օգտագործել RLS»

Եկեք լրացնենք մեր սահմանափակման համակարգը մի անջատիչով, որը հնարավորություն է տալիս/անջատում է սահմանափակումների օգտագործումը ռեկորդային մակարդակում:

Դա անելու համար ավելացրեք Constant և նիստի պարամետր «UseRLS» անունով:

Եկեք Session Module-ում գրենք նստաշրջանի պարամետրի արժեքը հաստատունի արժեքից:

Մուտքի սահմանափակման բոլոր տեքստերին ավելացրեք հետևյալ կոդը.

«#If &UseRLS #Then….. #EndIf»

Մենք ստուգում ենք. ամեն ինչ աշխատում է:

Սակայն այժմ «օգտագործել ռադարի» դրոշը միացնելուց հետո փոփոխություններն անմիջապես ուժի մեջ չեն մտնի։ Ինչո՞ւ։

Քանի որ նիստի պարամետրը սահմանվում է նիստի մեկնարկի ժամանակ:

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

Առաջին մասի ավարտ.

   

1C 1C տվյալների բազայի տվյալների օպտիմալ REQUEST կազմելու 17 կանոն

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

Հարցման տեքստը այն հրահանգն է, որի համաձայն պետք է կատարվի հարցումը: Հարցման մեջ նկարագրված է.

• infobase աղյուսակներ, որոնք օգտագործվում են որպես հարցումների տվյալների աղբյուրներ;
• աղյուսակի դաշտերը, որոնք պետք է մշակվեն հարցման մեջ.
• խմբավորման կանոններ;
• դասակարգման արդյունքներ;
• և այլն:

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

1C հարթակի հարցումների լեզուն շատ նման է այլ SQL լեզուների շարահյուսությանը, սակայն կան տարբերություններ։ Ներկառուցված հարցումների լեզվի հիմնական առավելություններն են՝ դաշտերի վերահղում, վիրտուալ աղյուսակներ, տոտալների հետ հարմար աշխատանք, հարցումներում չտիպված դաշտեր։

Տվյալների բազայի հարցումները 1C պլատֆորմի հարցումների լեզվով գրելու առաջարկություններ.

1) Հարցման մարմինը կարող է պարունակել կանխորոշված ​​կազմաձևման տվյալներ, ինչպիսիք են.

• enum արժեքներ;
• կանխորոշված ​​տվյալներ.
• գրացուցակներ;
• բնութագրերի տեսակների պլաններ;
• հաշվային գծապատկերներ;
• հաշվարկների տեսակների պլաններ;
• դատարկ հղումներ;
• բիզնես գործընթացների ճանապարհային կետերի արժեքները.

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

Բառացի օգտագործման օրինակ ԻՄԱՍՏՈՒԹՅՈՒՆ:

• WHERE City = VALUE (Directory.Cities.Moscow)
• WHERE City = VALUE (Reference.Cities.EmptyReference)
• WHEREItemType = VALUE (Enumeration.ProductTypes.Service)
• WHEREMovementType = VALUE (MovementTypeAccumulation.Income)
• WHERE RoutePoint = VALUE (BusinessProcess.BusinessProcess1.RoutePoint.Action1

2) Օգտագործելով հրահանգներ ԱՎՏՈՊԱՏՎԵՐհարցումում հարցման կատարման ժամանակը կարող է շատ բարձր լինել, ուստի եթե տեսակավորումը չի պահանջվում, ապա ավելի լավ է ընդհանրապես չօգտագործել այն։ Շատ դեպքերում տեսակավորումը կիրառելու լավագույն միջոցը հայտարարությունն է ԴԱՍԱՎՈՐԵԼ ԸՍՏ.

Ավտոմատ դասավորությունն աշխատում է հետևյալ սկզբունքներով.

• Եթե ​​հարցման մեջ նշված է ORDER BY կետը, ապա այս կետի աղյուսակի յուրաքանչյուր հղում կփոխարինվի այն դաշտերով, որոնցով աղյուսակը դասավորված է լռելյայնորեն (դիրեկտորիաների համար սա կոդը կամ անվանումն է, փաստաթղթերի համար՝ ամսաթիվը փաստաթղթի): Եթե ​​պատվերի դաշտը վերաբերում է հիերարխիկ գրացուցակին, ապա այս գրացուցակի հիերարխիկ տեսակավորումը կկիրառվի:
• Եթե ​​հարցման մեջ չկա ORDER BY կետ, բայց կա TOTALS կետ, ապա հարցման արդյունքը կդասավորվի ըստ ԱՐԴՅՈՒՆՔՆԵՐԻ կետում առկա դաշտերի՝ BY հիմնաբառից հետո, նույն հաջորդականությամբ և, եթե գումարները հաշվարկվել են ըստ. դաշտերը՝ հղումներ, այնուհետև նշված աղյուսակների լռելյայն տեսակավորման դաշտերով:
• Եթե ​​հարցումում չկա ORDER BY և TOTAL կետեր, բայց կա GROUP BY կետ, ապա հարցման արդյունքը կդասակարգվի ըստ նախադասության մեջ առկա դաշտերի՝ նույն հաջորդականությամբ, և եթե խմբավորումն իրականացվել է ըստ դաշտերի. հղումներ, այնուհետև ըստ լռելյայն տեսակավորելու դաշտերի աղյուսակները, որոնց հղում է կատարվել:
• Եթե ​​հարցումը չի պարունակում դրույթները և ORDER BY, TOTAL և GROUP BY, արդյունքը կդասավորվի ըստ կանխադրված տեսակավորման դաշտերի այն աղյուսակների, որոնցից ընտրված են տվյալները, այն հերթականությամբ, որ նրանք հայտնվում են հարցումում:
• Եթե ​​հարցումը պարունակում է TOTAL կետ, գումարների յուրաքանչյուր մակարդակ դասակարգվում է առանձին:

3) Օգտագործողին հարցման արդյունքը ցուցադրելիս տվյալների բազայի կրկնակի հարցումից խուսափելու համար (օրինակ՝ հարցում կառուցելը կամ աղյուսակի փաստաթղթի միջոցով հարցման արդյունքը ցուցադրելը), օգտակար է օգտագործել հրահանգը. ՆԵՐԿԱՅԱՑՄԱՆ ՀՂՈՒՄՆԵՐ A, որը թույլ է տալիս ստանալ հղման արժեքի ներկայացում: Օրինակ:

Հնարավոր է նաև օգտագործել հրահանգը ՆԵՐԿԱՅԱՑՈՒՄ- նախատեսված է կամայական տիպի արժեքի լարային ներկայացում ստանալու համար: Այս հրահանգների տարբերությունն այն է, որ առաջին դեպքում, եթե հրահանգները հղում են փոխանցում, արդյունքը կլինի տող, իսկ մյուս դեպքերում արդյունքը կլինի փոխանցված պարամետրի արժեքը: Երկրորդ դեպքում, հրահանգի արդյունքը միշտ կլինի տող:

4) Եթե հարցումը պարունակում է կոմպոզիտային տիպով դաշտ, ապա այդպիսի դաշտերի համար անհրաժեշտ է դառնում դաշտի արժեքները փոխանցել որոշակի տեսակի՝ օգտագործելով հրահանգը. EXPRESS, որը թույլ կտա ձախ կապից հեռացնել անհարկի աղյուսակները կոմպոզիտային տվյալների տիպի դաշտով և արագացնել հարցումը։ Օրինակ:

Գոյություն ունի ապրանքների մնացորդների կուտակման գրանցամատյան, որում Registrar դաշտն ունի կոմպոզիտային տեսակ։ Հարցման մեջ ընտրված են ապրանքների ստացման փաստաթղթերի ամսաթիվը և համարը, մինչդեռ Գրանցող դաշտի միջոցով փաստաթղթի մանրամասներին մուտք գործելը չի ​​հանգեցնում կուտակման ռեգիստրի աղյուսակի բազմաթիվ ձախ կապերի գրանցման փաստաթղթերի աղյուսակների հետ:

Կոդ 1C v 8.x SELECT
ԷՔՍՊՐԵՍ(Ապրանքների մնացորդներ. Գրանցման AS փաստաթուղթ. Ապրանքների ստացում): Համարը AS անդորրագրի համար,
ԷՔՍՊՐԵՍ(Ապրանքների մնացորդներ. Գրանցման AS փաստաթուղթ. Ապրանքների ստացում) Ամսաթիվ AS Ստացման ամսաթիվ
ԻՑ
Կուտակման գրանցամատյան.ապրանքների մնացորդներ AS ապրանքների մնացորդներ

Եթե ​​դերասանական կազմը համարվում է անիրագործելի, ապա նկարահանման արդյունքը արժեքն է ԴԱՏԱՐԿ.

5) Մի մոռացեք հրահանգների մասին ԹՈՒՅԼԱՏՐՎԱԾ Է, ինչը նշանակում է, որ հարցումը կընտրի միայն այն գրառումները, որոնց համար ներկայիս օգտվողն ունի թույլտվություններ: Եթե ​​այս բառը նշված չէ, ապա այն դեպքում, երբ հարցումն ընտրում է գրառումներ, որոնց համար օգտատերը իրավունք չունի, հարցումը կաշխատի սխալմամբ։

6) Եթե հարցումն օգտագործում է միություն, իսկ միության որոշ մասերում կան ներդիր աղյուսակներ (փաստաթուղթ աղյուսակային մասով), իսկ որոշներում կարիք չկա ընտրության ցանկը լրացնել դաշտերով՝ դատարկ ներդիր աղյուսակներ։ Սա արվում է բանալի բառի միջոցով ԴԱՏԱՐԿԵԼԻ, որից հետո փակագծերում նշվում են այն դաշտերի փոխանունները, որոնցից բաղկացած կլինի ներդիր աղյուսակը։ Օրինակ:

Կոդ 1C v 8.x // Ընտրեք դաշտերը համարը և կազմը
// վիրտուալ աղյուսակից Document.Invoice
ԸՆՏՐԵՔ Հղում.համարը,ԴԱՏԱՐԿԱԼ.(Nom, Tov, Qty) ՈՐՊԵՍ ԿԱԶՄԱԿՑՈՒԹՅՈՒՆ
FROM Document.Invoice-ից
ՄԻԱՑԵՔ ԲՈԼՈՐԻՆ
SELECT Link.Number, Composition.(Line Number, Product, Quantity)
FROM Document.Invoice Document.Invoice.Composition.*

7) Հարցման արդյունքում կրկնվող տողերից խուսափելու համար դուք պետք է օգտագործեք հրահանգը ՏԱՐԲԵՐ, քանի որ ավելի ու ավելի պարզ է, և հրահանգը ԽՈՒՄԲԸ ԸՍՏօգտագործվում է խմբավորման համար՝ օգտագործելով ագրեգատ ֆունկցիաները: Ի դեպ, ագրեգատ ֆունկցիաներ օգտագործելիս նախադասությունը ԽՈՒՄԲԸ ԸՍՏկարող է ընդհանրապես չնշված լինել, մինչդեռ հարցման բոլոր արդյունքները կխմբավորվեն մեկ տողի մեջ: Օրինակ:

Կոդ 1C v 8.x // Պետք է պարզել, թե որ կոնտրագենտները
// ապրանքները առաքվել են տվյալ ժամանակահատվածի համար:
Ընտրեք Տարբեր
Փաստաթուղթ.Ինվոյս.Կապալառու

8) հրահանգ ԽՈՒՄԲԸ ԸՍՏթույլ է տալիս մուտք գործել վերին մակարդակի դաշտեր՝ առանց արդյունքները խմբավորելու ըստ այդ դաշտերի, եթե համախառն գործառույթները կիրառվում են ներդիր աղյուսակի դաշտերում: Չնայած այն գրված է 1C օգնության մեջ, սակայն հարցման արդյունքները խմբավորելիս ընտրության դաշտերի ցանկում պետք է նշվեն համախառն ֆունկցիաները, իսկ ագրեգատային ֆունկցիաներից բացի ընտրության ցանկում կարող են նշվել միայն այն դաշտերը, որոնցով իրականացվում է խմբավորումը: դաշտերը. Օրինակ:

Կոդ 1C v 8.x SELECT
Ապրանքների և ծառայությունների ստացում Ապրանքներ (գումար (քանակ), անվանակարգ),
Ապրանքների և ծառայությունների ստացում: Հղում,
Ապրանքների և ծառայությունների ստացում Կողմնակից
ԻՑ
Փաստաթուղթ.Ապրանքների և ծառայությունների ստացում AS ապրանքների և ծառայությունների ստացում
ԽՈՒՄԲԸ ԸՍՏ
Ապրանքների և ծառայությունների անդորրագիր Ապրանքներ (Անվանակարգ)

9) հրահանգ ԱՆՈՒՐ Էնախատեսված արժեքը փոխարինելու համար ԴԱՏԱՐԿմեկ այլ արժեքի, բայց մի մոռացեք, որ երկրորդ պարամետրը կվերածվի առաջինի տեսակին, եթե առաջին պարամետրի տեսակը տող է կամ թիվ:

10) Հիմնական աղյուսակին հղում կատարելիս կարող եք դիմել պայմանի ստորադաս աղյուսակի տվյալներին. Այս հատկանիշը կոչվում է ենթաաղյուսակի դաշտերի հետհղում:

Օրինակ (աղյուսակային բաժնում որոշակի ապրանք պարունակող փաստաթղթերի որոնում).

Այս հարցման առավելությունը Incoming.Goods ենթաաղյուսակի հարցման նկատմամբ այն է, որ եթե փաստաթղթերում կան կրկնօրինակներ, հարցման արդյունքը կվերադարձնի միայն եզակի փաստաթղթեր՝ առանց DISTINCT հիմնաբառի օգտագործման:

11) B օպերատորի հետաքրքիր տարբերակը նման բազմությունների բազմության մեջ (Field1, Field2, ... , FieldN) B (Field1, Field2, ... , FieldN) բազմության մեջ պատվիրված բազմության առկայության ստուգումն է:

Կոդ 1C v 8.x SELECT
Կապալառուներ.Հղում
ՈՐՏԵՂ
(Contractors.Link, Goods.Link)
(SELECT Sales.Customer, Sales.Product
Կուտակային ռեգիստրից. Sales AS Sales)
ԻՑ
տեղեկատու. Կողմնակիցներ,
Directory.Products

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

Մշակողը կարող է ինքնուրույն ստանալ նույն տվյալները, որոնք համակարգը տրամադրում է իրեն որպես վիրտուալ աղյուսակներ, սակայն այդ տվյալների ստացման ալգորիթմը չի օպտիմիզացվելու, քանի որ.

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

Մշակողի համար միշտ չէ, որ հնարավոր է մուտք ունենալ այն տվյալներին, որոնց հասանելի է համակարգը:

13) հաճախորդ-սերվերի աշխատանքի ռեժիմում ֆունկցիան SUBSTRING ()իրականացվում է SQL Server տվյալների բազայի սերվերին փոխանցված համապատասխան SQL հայտարարության SUBSTRING() ֆունկցիայի միջոցով, որը հաշվարկում է SUBSTRING() ֆունկցիայի արդյունքի տեսակը ըստ բարդ կանոնների՝ կախված դրա պարամետրերի տեսակից և արժեքներից, ինչպես նաև կախված այն համատեքստից, որտեղ այն օգտագործվում է: Շատ դեպքերում այս կանոնները չեն ազդում հարցման կատարման վրա, սակայն կան դեպքեր, երբ SQL Server-ի կողմից հաշվարկված արդյունքի տողի առավելագույն երկարությունը էական է հարցման կատարման համար: Կարևոր է հիշել, որ որոշ համատեքստերում SUBSTRING() ֆունկցիան օգտագործելիս դրա արդյունքի առավելագույն երկարությունը կարող է հավասար լինել սահմանափակ երկարությամբ տողի առավելագույն երկարությանը, որը 4000 նիշ է SQL Server-ում: Սա կարող է հանգեցնել հարցման կատարման անսպասելի խափանման.

Microsoft OLE DB մատակարար SQL Server-ի համար. Զգուշացում. հարցումների պրոցեսորը չկարողացավ ստեղծել հարցումների պլան օպտիմալացնողից, քանի որ GROUP BY կամ ORDER BY կետի բոլոր սյունակների ընդհանուր երկարությունը գերազանցում է 8000 բայթը:

HRESULT=80040E14, SQLSTATE=42000, բնիկ=8618

14) Օգտագործեք զգուշությամբ ԿԱՄշինարարության մեջ ՈՐՏԵՂ, քանի որ OR-ով պայմանի օգտագործումը կարող է զգալիորեն «կշռել» հարցումը։ Խնդիրը կարելի է լուծել դիզայնով ՄԻԱՑԵՔ ԲՈԼՈՐԻՆ. Օրինակ:

Կոդ 1C v 8.x SELECT

ԻՑ

ՈՐՏԵՂ
_DemoContractors.Link =Link1
ՄԻԱՑԵՔ ԲՈԼՈՐԻՆ
ԸՆՏՐԵԼ
_Demo Counterparties.NameFull
ԻՑ
տեղեկատու._DemoContractors ԻՆՉՊԵՍ _DemoContractors
ՈՐՏԵՂ
_DemoContractors.Link =Link2

15) Վիճակը ՄԱՍ ՉԷշինարարության մեջ ՈՐՏԵՂմեծացնում է հարցումի կատարման ժամանակը, քանի որ դա մի տեսակ է ՉԻ (OR1 OR2 ... ORn), այնպես որ մեծ սեղանների համար փորձեք օգտագործել ՁԱԽ ՄԻԱՑԵՔ IS NULL պայմանով. Օրինակ:

Կոդ 1C v 8.x SELECT
_DemoContractors.Link
ԻՑ
տեղեկատու._DemoContractors ԻՆՉՊԵՍ _DemoContractors
LEFT JOIN Document._DemoBuyerOrder AS _DemoBuyerOrder
Software _DemoContractors.Link = _BuyerDemoOrder.Contractor
ՈՐՏԵՂ
_Գնորդի Դեմոպատվերը: Կողմնակիցը զրոյական է

16) Օգտագործելիս Ժամանակավոր սեղաններդուք պետք է ինդեքսավորեք պայմանը և միացնեք դաշտերը այս աղյուսակներում, ԲԱՅՑ, ինդեքսներ օգտագործելիս հարցումը կարող է ավելի դանդաղ աշխատել: Ուստի անհրաժեշտ է յուրաքանչյուր հարցում վերլուծել ինդեքսով և առանց դրա, չափել հարցումների կատարման արագությունը և վերջնական որոշում կայացնել։

Եթե ​​դուք տվյալները տեղադրեք ժամանակավոր աղյուսակում, որն ի սկզբանե ինդեքսավորված է որոշ դաշտերում, ապա ժամանակավոր աղյուսակում այլևս չի լինի այդ դաշտերի ինդեքսը:

17) Եթե դուք չեք օգտագործում Temp սեղանի կառավարիչ, ապա ժամանակավոր աղյուսակը հստակորեն ջնջելու կարիք չկա, այն կջնջվի խմբաքանակի հարցման կատարումն ավարտելուց հետո, հակառակ դեպքում ժամանակավոր աղյուսակը պետք է ջնջվի հետևյալ եղանակներից մեկով՝ հրամանով. ՈՉՆՉԱՑՆԵԼհարցումում զանգահարել մեթոդը TemporaryTable Manager.Close().

Եվ բացի Եվգենի Գիլևի տեսանյութից. Տիպիկ սխալներ 1C-ի համար հարցումներ գրելիս.