20.09.2014

V dotazovacím jazyce je direktiva "Allowed". Je určen k použití rámcem k odfiltrování záznamů, ke kterým uživatel nemá práva při nastavování limitu na úrovni záznamů v databázi.

Zdálo by se, že v dotazech je lepší vždy používat tuto direktivu. Budu tvrdit, že tomu tak není. Také budu tvrdit, že pokud je to možné, měli byste se tomu vyhnout, proto.

Řekněme, že uděláme zprávu o vzájemném vyrovnání jednotlivců. Uživatel má práva k jedné organizaci a v databázi je více než jedna organizace a v databázi je povoleno omezení na úrovni záznamů. Databáze má také registr "Vzájemná vypořádání" s dimenzemi "Organizace" a "Jednotlivec". Pokud je v systému požadavek

"Vybrat

Organizace,

Individuální

a bude proveden jménem uživatele s oprávněním k jedné organizaci, pak dotaz selže, pokud jsou v tomto registru záznamy jiných organizací. Dojde k chybě a popis chyby bude "Uživatel nemá dostatečná práva k dokončení požadavku!" a to je pravda, platforma nepodvádí, protože nemá práva k záznamům jiných organizací v tomto registru.

Co dělat v tomto případě, použít direktivu "Povoleno"? Podle mě to za to nestojí. Stačí nastavit výběr podle organizace a uživatel bude moci vygenerovat sestavu. Dotaz na sestavu se složením dat bude vypadat takto

"Vybrat

Organizace,

Individuální

(Vybrat

Organizace

individuální)

Z registru akumulace.Vzájemné vyrovnání

(Kde

Organizace

individuální)

Pokud uživatel provede dotaz na tabulku bez výběru, pak se sestava nevygeneruje a uživatel nerozpozná data pro jiné organizace, a pokud nastaví výběr pro svou organizaci, vygeneruje správná data.

Můžete se znovu zeptat - "Proč byste neměli použít direktivu Allowed", to okamžitě vynutí výběr, ušetří uživatele od zpráv, které nepotřebuje!

Odpověď na tuto otázku bude následující - jak se v tomto případě uživatel dozví, že do zprávy byly zahrnuty všechny potřebné údaje. Předpokládejme, že dříve tento uživatel pracoval s plnými právy a udělal chybu a vybral si v dokumentu jednotlivce z jiné organizace. Může také nastat situace, data se načítala - a v dokumentech organizace bylo zapsáno pododdělení jiné organizace (v ZUP jsou na ně uvalena i omezení vlastníka). V tomto případě direktiva "Allowed" odřízne zakázaná data bez jakýchkoli zpráv pro uživatele a ten nepozná, že ne vše, co by mělo být v reportu obsaženo, bylo zahrnuto.

Není tedy nutné tuto směrnici hromadně zadávat do požadavků na typické konfigurace, což považujeme za chybu. V regulovaných žádostech o podávání zpráv se to velmi nedoporučuje. Nedělejte to ani v jiných zprávách a dokumentech, kde je vyžadována přesnost informací.

Jak se ale přesto vyhnout chybě „spadnutí“ programu s nedostatkem práv?

Ano, je to velmi jednoduché, musíte použít příkaz "Vyzkoušet", zde je příklad:

Pokus

Request.Execute();

Výjimka

Report(ErrorDescription());

Konec pokusu;

V sestavách používajících ACS musí být programový kód pro provedení sestavy zapsán ručně, také prostřednictvím pokusu.

V důsledku toho uživatel neobdrží nesprávná data a obdrží rozumnou chybovou zprávu.

V našem článku se můžete seznámit s nuancemi nastavení RLS v samostatných oddílech.

). Použití tohoto klíčového slova zabrání chybě při získávání záznamů, pro které uživatel nemá práva.

Problém: V některých případech může výsledek omezení přístupu k datům v 1C 8.3 záviset na plánu dotazů DBMS. Tento článek popisuje možné situace a dává doporučení, jak se jim vyhnout.

Problém s možnou závislostí výsledku omezení přístupu k datům na plánu dotazů DBMS může nastat, když je databázový dotaz proveden bez klíčového slova POVOLENO pokud existují omezení přístupu k datům pro aktuálního uživatele a dotaz obsahuje jedno nebo více porovnání formuláře:

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

Pokud v tomto případě < > (dotaz v dotazu) používá databázové tabulky, které podléhají omezení přístupu, pak je možné, že na některých SŘB bude dotaz úspěšně proveden a na jiných bude vydána zpráva za předpokladu, že data v infobázích jsou zcela totožná .

Získejte zdarma lekce videa 267 1C:

Důvod rozdílů

Možný rozdíl v chování je způsoben implementací omezení přístupu k datům bez klíčového slova POVOLENO v 1C Enterprise 8.3.

Dotaz bez klíčového slova POVOLENO bude úspěšně spuštěn pouze v případě, že během jeho provádění nedojde k žádnému přístupu k zakázaným datům. K tomu je k němu přidáno speciální signálové pole, které přebírá hodnotu Skutečný u těch záznamů, na jejichž tvorbě se podílela pouze povolená data, a hodnotu Lhát pro všechny ostatní položky. Pokud alespoň jeden záznam výběru obsahuje hodnotu Lhát v poli signálu, pak se dotaz ukončí abnormálně.

Stejné pole signálu se přidá k výsledkům dotazů vnořených do srovnání. V/NE V. Navíc je v tomto případě kontrola hodnoty sloupce signálu prováděna pomocí DBMS. Pokud tedy v procesu provádění vnořeného dotazu došlo k přístupu k zakázaným datům, mělo by provádění dotazu skončit s chybou Uživatel nemá dostatečná práva k provedení operace s databází.

Při vytváření plánu dotazů však nemusí systém DBMS obdržet úplný výběr <Вложенным запросом> a získat pouze ty záznamy, které jsou skutečně potřeba ke kontrole stavu V/NE V. V tomto případě může být dotaz úspěšný, i když <Вложенного запроса> přístup k zakázaným údajům by mohl nastat jako nezávislá žádost.

Podívejme se na jednoduchý příklad. Pusťte na stůl Adresář. Jednotlivci omezení přístupu k datům. V tomto případě je požadavek:

Tabulka.Jednotlivec AS Jednotlivec

bude proveden s chybou kvůli pokusu o přístup k zakázaným datům. Pokud je tento dotaz součástí porovnávání, například:

Tabulka.Jednotlivec AS Jednotlivec

Directory.Individuals AS Table)

pak, v závislosti na plánu dotazů zvoleném DBMS, může být dotaz proveden buď úspěšně, nebo s chybou. Toto chování požadavku není chybné, protože přístup k zakázaným datům během provádění tohoto požadavku může, ale nemusí nastat. Pro získání předvídatelnějšího výsledku je nutné sestavit dotaz tak, aby vnořený dotaz zaručeně neprováděl přístupy ke zjevně nepotřebným datům. Zejména pokud je předchozí dotaz přepsán takto:

Smlouva o provedení díla s fyzickou osobou.Zaměstnanec.Fyzická osoba

Dokument.Smlouva o provedení díla s fyzickou osobou AS Dohoda o provedení práce s fyzickou osobou

Smlouva o provedení práce s fyzickou osobou.Zaměstnanec.Fyzická osoba B (

Tabulka.Jednotlivec AS Jednotlivec

Adresář.Jednotlivci AS Tabulka

Dotazovací jazyk je jedním ze základních mechanismů 1C 8.3 pro vývojáře. Pomocí dotazů můžete rychle získat jakákoli data uložená v databázi. Jeho syntaxe je velmi podobná SQL, ale existují určité rozdíly.

Hlavní výhody dotazovacího jazyka 1C 8.3 (8.2) oproti SQL:

• dereferencování referenčních polí (přeměna jedné nebo více teček na atributy objektu);
• práce s výsledky je velmi pohodlná;
• schopnost vytvářet virtuální tabulky;
• žádost může být napsána jak v angličtině, tak v ruštině;
• schopnost blokovat data, aby nedošlo k uváznutí.

Nevýhody dotazovacího jazyka v 1C:

• na rozdíl od SQL vám dotazy v 1C neumožňují měnit data;
• nedostatek uložených procedur;
• nemožnost převodu řetězce na číslo.

Zvažte náš mini tutoriál o základních konstrukcích dotazovacího jazyka 1C.

Vzhledem k tomu, že požadavky v 1C umožňují pouze přijímat data, musí každý požadavek začínat slovem „SELECT“. Po tomto příkazu jsou označena pole, ze kterých chcete získat data. Pokud zadáte "*", budou vybrána všechna dostupná pole. Místo, odkud se budou data vybírat (dokumenty, registry, adresáře atd.), je uvedeno za slovem „OD“.

V níže uvedeném příkladu jsou názvy celé nomenklatury vybrány z referenční knihy "Nomenklatura". Za slovem „JAK“ jsou uvedeny aliasy (názvy) pro tabulky a pole.

VYBRAT
Nomenclature.Name AS NameNomenklatura
Z
Adresář Nomenklatura AS Nomenklatura

Vedle příkazu "SELECT" můžete zadat klíčová slova:

• ROZLIČNÝ. Dotaz vybere pouze řádky, které se liší alespoň v jednom poli (bez duplicit).
• První n, Kde n– počet řádků od začátku výsledku, který se má vybrat. Nejčastěji se tato konstrukce používá ve spojení s řazením (ORDER BY). Například, když potřebujete vybrat určitý počet nejnovějších dokumentů podle data.
• POVOLENO. Tento návrh umožňuje vybrat z databáze pouze ty záznamy, které má aktuální uživatel k dispozici. Pokud je použito toto klíčové slovo, uživatel obdrží chybovou zprávu, pokud se pokusí vyhledat záznamy, ke kterým nemá přístup.

Tato klíčová slova lze použít všechna společně nebo samostatně.

PRO ZMĚNU

Tato klauzule uzamkne data, aby se zabránilo konfliktům. Uzamčená data nebudou načtena z jiného připojení až do konce transakce. V této klauzuli můžete určit konkrétní tabulky, které chcete zamknout. Jinak budou všechny zablokovány. Konstrukce je relevantní pouze pro režim automatického blokování.

Nejčastěji se při příjmu zůstatků používá doložka „PRO ZMĚNU“. Pokud totiž v programu pracuje několik uživatelů současně, zatímco jeden přijímá zůstatky, druhý je může měnit. V tomto případě již nebude výsledná rovnováha správná. Pokud s tímto návrhem zablokujete data, pak dokud první zaměstnanec nedostane správný zůstatek a neprovede s ním všechny potřebné manipulace, bude muset druhý zaměstnanec počkat.

VYBRAT
Vzájemné vyrovnání. Zaměstnanec,
Vzájemné vyrovnání Částka Vzájemné vyrovnání Zůstatek
Z
Registr akumulace. Vzájemné vyrovnání se zaměstnanci. Zůstatky JAKO vzájemné vyrovnání
PRO ZMĚNU

KDE

Konstrukce je nezbytná pro uložení libovolného výběru na vyložená data. V některých případech získávání dat z registrů je rozumnější předepsat výběrové podmínky v parametrech virtuálních tabulek. Při použití „WHERE“ se nejprve získají všechny záznamy a až poté se aplikuje výběr, což výrazně zpomalí dotaz.

Následuje příklad požadavku na získání kontaktních osob s konkrétní pozicí. Parametr výběru má následující formát: &Název parametru (název parametru je libovolný).

VÝBĚR (PŘÍPAD)

Konstrukce umožňuje zadat podmínky přímo v těle požadavku.

V níže uvedeném příkladu bude "Další pole" obsahovat text v závislosti na tom, zda je dokument zaúčtován nebo ne:

VYBRAT
VstupnéT&U.Link,
VÝBĚR
KDYŽ
PAK "Dokument zveřejněn!"
ELSE "Dokument nebyl odeslán..."
KONEC JAKO DalšíPole
Z
Dokument. Příjem zbožíSlužby AS Příjem VOP

PŘIPOJIT

Spojení spojí dva stoly určitou podmínkou propojení.

PŘIPOJTE SE VLEVO/VPRAVO

Podstatou LEVÉHO spojení je, že první zadaná tabulka je převzata celá a druhá je k ní připojena podmínkou spojení. Pokud neexistují žádné záznamy odpovídající první tabulce ve druhé, pak se jako jejich hodnoty nahradí NULL. Jednoduše řečeno, hlavní tabulka je první určená tabulka a data druhé tabulky (pokud existuje) jsou již nahrazena jejími daty.

Například potřebujete získat položky položek z dokladů "Příjem zboží a služeb" a ceny z evidence informací "Ceny položek". V tomto případě, pokud cena jakékoli pozice není nalezena, nahraďte místo ní NULL. Vyberou se všechny položky z dokladu bez ohledu na to, zda mají nebo nemají cenu.

VYBRAT
Potvrzení T&U. Nomenklatura,
Ceny.Cena
Z
Doklad.Příjem zbožíSlužby.Zboží AS Příjem VOP
VNITŘNÍ SPOJENÍ
ON Příjem Q&A. Nomenklatura = Ceny. Nomenklatura

V PRÁVĚ je vše přesně naopak.

PLNÉ PŘIPOJENÍ

Tento typ spojení se od předchozích liší tím, že jako výsledek budou vráceny všechny záznamy první i druhé tabulky. Pokud pro zadanou podmínku propojení nejsou v první nebo druhé tabulce nalezeny žádné záznamy, bude místo toho vrácena hodnota NULL.

Při použití úplného spojení v předchozím příkladu budou vybrány všechny položky položek z dokladu Příjem zboží a služeb a všechny nejnovější ceny z evidence Ceny položek. Hodnoty nenalezených záznamů v první i ve druhé tabulce budou NULL.

VNITŘNÍ SPOJENÍ

Rozdíl mezi VNITŘNÍM spojením a ÚPLNÝM spojením je v tom, že pokud záznam není nalezen alespoň v jedné z tabulek, pak jej dotaz vůbec nezobrazí. V důsledku toho budou vybrány pouze ty položky položek z dokladu Příjem zboží a služeb, pro které jsou záznamy v registru informací o cenách položek, pokud v předchozím příkladu nahradíme FULL za INTERNÍ.

SKUPINA VYTVOŘENÁ

Seskupování v dotazech 1C umožňuje sbalit řádky tabulky (seskupení polí) podle určité společné funkce (seskupení polí). Seskupování polí lze zobrazit pouze pomocí agregačních funkcí.

Výsledkem dalšího dotazu bude seznam typů položek s jejich maximálními cenami.

VYBRAT
,
MAX(cena.cena) AS Cena
Z

SKUPINA VYTVOŘENÁ
Ceny.Nomenklatura.TypNomenklatura

VÝSLEDEK

Na rozdíl od seskupování se při použití součtů zobrazují všechny záznamy a jsou k nim již přidány součtové řádky. Seskupení zobrazí pouze zobecněné záznamy.

Výsledky lze shrnout pro celou tabulku (pomocí klíčového slova "OBECNÉ"), pro několik polí, pro pole s hierarchickou strukturou (klíčová slova "HIERARCHIE", "POUZE HIERARCHIE"). Při sčítání není nutné používat agregační funkce.

Zvažte příklad podobný výše uvedenému příkladu s použitím seskupování. V tomto případě výsledek dotazu vrátí nejen seskupená pole, ale také podrobné záznamy.

VYBRAT
Ceny.Nomenklatura.Typ nomenklatury AS Typ nomenklatury,
Ceny. Cena AS Cena
Z
RegistrovatInformace.CenyNomenklatura.SliceLast AS Ceny
VÝSLEDEK
MAXIMUM (cena)
PODLE
Nomenklatura typu

MÍT

Tento operátor je podobný operátoru WHERE, ale používá se pouze pro agregační funkce. Ostatní pole, než která používá tento operátor, musí být seskupena. Operátor "WHERE" nelze použít pro agregační funkce.

V níže uvedeném příkladu jsou maximální ceny položek vybrány, pokud překročí 1000, seskupené podle typu položky.

VYBRAT

MAX(cena.cena) AS Cena
Z
RegistrovatInformace.CenyNomenklatura.SliceLast AS Ceny
SKUPINA VYTVOŘENÁ
Ceny.Nomenklatura.TypNomenklatura
MÍT
MAX (Ceny. Cena) > 1000

SEŘAZENO PODLE

Operátor "ORDER BY" seřadí výsledek dotazu. Aby bylo zajištěno, že záznamy jsou na výstupu v konzistentním pořadí, používá se AUTO-ORDER. Primitivní typy jsou seřazeny podle obvyklých pravidel. Typy odkazů jsou seřazeny podle GUID.

Příklad získání seznamu zaměstnanců seřazených podle jména:

VYBRAT
Employees.Name AS Name
Z
Adresář Zaměstnanci AS Zaměstnanci
SEŘAZENO PODLE
název
AUTO OBJEDNÁVKA

Další konstrukce dotazovacího jazyka 1C

• SJEDNOTIT- výsledky dvou dotazů v jednom.
• SPOJETE VŠECHNY– podobné JOIN, ale bez seskupování stejných řádků.
• PRÁZDNÝ STŮL- někdy se používá při spojování dotazů k určení prázdné vnořené tabulky.
• DÁT- vytvoří dočasnou tabulku pro optimalizaci složitých 1C dotazů. Takové požadavky se nazývají dávkové požadavky.

Funkce dotazovacího jazyka

• SUBSTRING zkrátí řetězec ze zadané pozice o zadaný počet znaků.
• ROK… DRUHÝ umožňují získat vybranou hodnotu číselného typu. Vstupním parametrem je datum.
• ZAČÁTEK OBDOBÍ A KONEC OBDOBÍ se používají při práci s daty. Jako další parametr je uveden typ období (DEN, MĚSÍC, ROK atd.).
• PŘIDAT umožňuje přidat nebo odečíst od data zadaný čas určitého typu (SEKUnda, MINUTA, DEN atd.).
• DATUM ROZDÍL určuje rozdíl mezi dvěma daty s uvedením typu výstupní hodnoty (DEN, ROK, MĚSÍC atd.).
• ISNULL nahradí chybějící hodnotu zadaným výrazem.
• PREZENTACE a PREZENTAČNÍ ODKAZY získat řetězcovou reprezentaci zadaného pole. Používají se pro jakékoli hodnoty a pouze referenční hodnoty.
• TYPE, VALUE TYPE se používají k určení typu vstupního parametru.
• ODKAZ je logický porovnávací operátor pro typ hodnoty atributu.
• VYJÁDŘIT slouží k převodu hodnoty na požadovaný typ.
• ČAS SCHŮZKY získá hodnotu typu "Datum" z číselných hodnot (rok, měsíc, den, hodina, minuta, sekunda).
• VÝZNAM v požadavku 1C se používá ke specifikaci předdefinovaných hodnot - adresářů, výčtů, plánů typů charakteristik. Příklad použití: " Kde LegalIndividual = Value(Enumeration.LegalIndividual.Individual)«.

Tvůrce dotazů

Pro vytváření dotazů pomocí 1C existuje velmi pohodlný vestavěný mechanismus - návrhář dotazů. Obsahuje následující hlavní záložky:

• "Tabulky a pole" - obsahuje pole k výběru a jejich zdroje.
• "Odkazy" - popisuje podmínky pro konstrukci CONNECTION.
• "Seskupování" - obsahuje popis konstrukcí seskupení a jimi sumarizovaných polí.
• "Podmínky" - odpovídá za výběr údajů v poptávce.
• "Advanced" - další parametry dotazu, jako jsou klíčová slova příkazu "SELECT" atd.
• „Joins / Aliases“ - jsou uvedeny možnosti spojení tabulek a nastaveny aliasy (konstrukt „HOW“).
• "Objednávka" - zodpovídá za řazení výsledků dotazů.
• "Součet" - podobně jako záložka "Seskupení", ale používá se pro konstrukci "TOTALS".

Samotný text žádosti lze zobrazit kliknutím na tlačítko „Požádat“ v levém dolním rohu. V této podobě jej lze ručně opravit nebo zkopírovat.

Konzole dotazu

Chcete-li rychle zobrazit výsledek dotazu v režimu "Enterprise" nebo ladit složité dotazy, použijte . Zapíše se do něj text dotazu, nastaví se parametry a zobrazí se jeho výsledek.

Konzolu dotazů si můžete stáhnout na disku ITS nebo pomocí .

Konfigurační objekt "role" poskytuje sadu práv k operacím (akcím) na konfiguračních objektech.

Role "Plná práva".

Toto je pouze role (nepředdefinovaná), která má zaškrtávací políčka pro všechny druhy práv na všechny konfigurační objekty.

Jeho odlišností od ostatních rolí je přítomnost práva „Správa“.

Pokud je vytvořen alespoň jeden uživatel, systém začne kontrolovat právo "Administrace" - musí je mít alespoň jeden uživatel.

Omezit přístup na úrovni záznamu

Row Level Security (RLS) – Omezení na úrovni záznamu.

Mechanismus omezení přístupu k datům umožňuje spravovat přístupová práva nejen na úrovni objektů metadat, ale také na úrovni databázových objektů. K omezení přístupu k datům lze použít následující objekty:

• role,
• možnosti relace,
• funkční možnosti,
• privilegované společné moduly,
• klíčové slovo ALLOWED v dotazovacím jazyce.

Mechanismus je navržen tak, aby omezoval přístup k záznamům tabulky objektů metadat podle libovolných podmínek uložených na hodnotách řádkových polí těchto tabulek. Chcete-li například zobrazit záznamy pouze pro „vaše“ protistrany, organizace atd.

Technická implementace omezení přístupu v 1C

1C generuje požadavek do DBMS. Serverový cluster přidá k požadavku sekci WHERE, která obsahuje text podmínky pro omezení přístupu RLS, poté je tento požadavek odeslán do DBMS, extrahovaná data jsou vrácena klientovi 1C.

Tento mechanismus bude fungovat pro jakýkoli požadavek od klienta:

• ve zprávách
• v dynamických seznamech a formulářích běžných seznamů
• v náhodných žádostech.

Taková implementace mechanismu výrazně ovlivňuje výkon.

Způsoby, jak obejít omezení přístupu.

V rozsáhlých operacích náročných na zdroje (například zpracování dokumentů pro přeúčtování) lze část kódu přesunout do privilegovaných modulů.

A) privilegovaný modul je sdílený modul s příznakem "Privileged" ve vlastnostech.

Jeho zvláštnost spočívá v tom, že kód v něm je spouštěn bez jakékoli kontroly přístupu, včetně RLS.

B) Také výsadní režim lze povolit pro moduly dokumentů. To se provádí ve vlastnostech dokumentu, příznak

• Privilegovaný režim při držení
• Privilegovaný režim při zrušení plánování

C) Metoda SetPrivilegedMode()

Systémový příkaz, který vám umožňuje učinit část kódu libovolného modulu privilegovanou.

Od dalšího řádku kódu bude v platnosti privilegovaný režim provádění.

Bude působit až do řádku pro deaktivaci tohoto režimu nebo do konce procedury / funkce

(Skutečný);

// jakýkoli kód zde bude spuštěn bez kontroly práv a RLS

NastavitPrivilegedMode(Lhát ); // nebo konec procedury / funkce

Počet aktivací privilegovaného režimu musí odpovídat počtu deaktivací. Pokud byl však privilegovaný režim povolen (jednou nebo vícekrát) v rámci procedury nebo funkce, ale nebyl deaktivován, systém automaticky provede vypnutí tolikrát, kolikrát bylo čekajících aktivací v proceduře nebo funkci, která je opouštěna.

Pokud v proceduře nebo funkci volá metoda NastavitPrivilegedMode(False) více než volání metod NastavitPrivilegedMode(true), pak bude vyvolána výjimka

Funkce PrivilegedMode() vrátí True, pokud je privilegovaný režim stále povolen, a False, pokud je privilegovaný režim zcela zakázán. Neanalyzuje počet nastavení privilegovaného režimu v konkrétní funkci.

Všechny volané procedury a funkce budou také provedeny v privilegovaném režimu.

Je také možné spustit privilegovanou relaci. Jedná se o relaci, ve které je privilegovaný režim nastaven od samého začátku systému. Přitom za provozu způsob PrivilegedMode() vždy vrátí True a možnost deaktivovat privilegovaný režim není podporována. Privilegovanou relaci může spustit pouze uživatel s právy správce (právo Správa). Relaci lze spustit pomocí přepínače příkazového řádku pro spuštění klientské aplikace UsePrivilegedMode nebo parametru připojovacího řetězce infobase prmod.

Přirozeně se nabízí otázka: Proč tedy vůbec nastavovat omezení přístupu, když to lze tak snadno obejít?

Nouzový režim.

Ano, je možné zapisovat externí zpracování s privilegovaným režimem provádění a uvolnit/narušit data. Aby se tomu zabránilo, má systém metodu globálního kontextu

Nastavte SafeMode().

Nouzový režim mimo jiné ignoruje privilegovaný režim.

Musí být nastaven před programovým voláním externích obslužných rutin nebo exportem procedur a funkcí z jejich modulů.

Vyvolá výjimku při provádění zakázaných operací za běhu.

Pro uživatele navíc můžete vypnout možnost interaktivního spouštění externích sestav a zpracování na úrovni nastavení role.

Nastavení omezení přístupu

RLS lze nakonfigurovat pouze pro práva:

• čtení (vybrat)
• přidání (vložit)
• změnit (aktualizovat)
• smazat (smazat)

Pro operace čtení a vymazání, objekt v databázi musí splňovat omezení přístupu k datům.

Pro operaci přidání omezení přístupu k datům musí odpovídat objektu, který má být zapsán do databáze.

Pro operaci změny Omezení přístupu k datům se musí shodovat s objektem jak před změnou (pro objekt ke čtení), tak po změně (pro objekt, který má být zapsán).

U všech ostatních práv tato možnost není dostupná.

Přidejme nové omezení pro právo „čtení“ referenční knihy „Nomenklatura“. Otevře se seznam polí, pro která můžete nakonfigurovat přidané omezení.

To znamená, že pokud se pokusíte o přístup k zaškrtnutým polím, omezení bude fungovat, a pokud se pokusíte získat přístup k nezaškrtnutým polím, omezení nebude fungovat.

Pokud vyberete příznak Ostatní obory“, omezení bude nastaveno pro všechna pole tabulky s výjimkou polí, pro která jsou omezení nastavena explicitně.

*Funkce: pro práva přidávat, měnit, mazat:

• Omezení lze nakonfigurovat pouze pro všechna pole.
• Limit může být pouze jeden.

Pro právo "Číst" můžete nastavit několik podmínek, budou kombinovány s logickým operátorem "AND".

V omezeních na databázové objekty následujících typů nelze použít všechna pole hlavního datového objektu omezení:

• v akumulačních registrech mohou omezení přístupu obsahovat pouze měření hlavního předmětu omezení;
• v účetních evidencích v omezeních lze použít pouze bilanční měření hlavního předmětu omezení

Pokud jsou za podmínek omezeného přístupu k údajům obratového registru akumulace použita měření, která nejsou zahrnuta v součtech, pak se při přístupu do virtuální tabulky obratu uložené součty nepoužijí a dotaz se provede zcela podle k pohybovému stolu.

Mechanismus pro uvalení omezení přístupu.

Jakákoli operace s daty uloženými v databázi v 1C:Enterprise nakonec vede k přístupu k databázi s určitým požadavkem na čtení nebo úpravu dat. Během provádění dotazů do databáze interní mechanismy 1C:Enterprise ukládají omezení přístupu. kde:

• Vytvoří se seznam práv(číst, přidat, aktualizovat, odstranit), seznam databázových tabulek a seznam polí používaných tímto dotazem.
• Ze všech rolí aktuálního uživatele vyberte omezení přístupu na data pro všechna práva, tabulky a pole zahrnuté v požadavku. Navíc, pokud jakákoli role neobsahuje omezení přístupu k datům jakékoli tabulky nebo pole, znamená to, že v této tabulce jsou k dispozici hodnoty požadovaných polí z libovolného záznamu. Jinými slovy, absence omezení přístupu k datům znamená, že existuje omezení WHERE True.
• Získejte aktuální hodnoty všech parametrů relace a funkčních možnostíúčastnit se vybraných omezení.

Získání hodnoty parametru relace nebo funkční volby nevyžaduje, aby aktuální uživatel měl právo tuto hodnotu získat. Pokud však hodnota některého parametru relace nebyla nastavena, dojde k chybě a databázový dotaz nebude proveden.

Omezení odvozená ze stejné role jsou kombinována s operací AND.

Omezení přijatá z různých rolí jsou kombinována s operací OR.

Vytvořené podmínky jsou přidány k SQL dotazům, se kterými 1C:Enterprise přistupuje k DBMS. Při přístupu k datům ze strany podmínek omezení přístupu se neprovádí žádná kontrola práv (ani k objektům metadat, ani k objektům databáze). Mechanismus přidávání podmínek navíc závisí na zvoleném režimu fungování omezení „vše“ nebo „povoleno“.

*Funkce: Pokud má uživatel přístup k více rolím s nakonfigurovanými omezeními na úrovni záznamů k jednomu objektu, pak jsou v tomto případě podmínky omezení přidány logickou operací "OR". Jinými slovy, oprávnění uživatele jsou kumulativní.

To vede k následujícímu závěru: nedovolte překročit podmínku omezení přístupu k jednomu objektu v různých rolích, protože v tomto případě se text dotazu značně zkomplikuje a ovlivní výkon.

Všechny cesty.

Když jsou omezení zavedena pomocí metody „all“, jsou do SQL dotazů přidány podmínky a pole, takže 1C:Enterprise může získat informace o tom, zda data, která jsou pro daného uživatele zakázaná, byla použita v procesu provádění databázového dotazu či nikoli. . Pokud byla použita zakázaná data, je požadavek přerušen z důvodu narušení přístupu.

Uvalení omezení přístupu metodou „každý“ je schematicky znázorněno na obrázku:

"Povolená" metoda.

Jsou-li omezení zavedena pomocí metody „povolené“, jsou k dotazům SQL přidány takové podmínky, aby položky zakázané pro aktuálního uživatele neovlivnily výsledek dotazu. Jinými slovy, když jsou omezení uložena v „povoleném“ režimu, záznamy zakázané pro tohoto uživatele jsou považovány za chybějící a neovlivňují výsledek operace, který je schematicky znázorněn na obrázku:

Omezení přístupu k datům jsou uvalena na databázové objekty, když 1C:Enterprise přistupuje k databázi.

Ve verzi klient-server 1C:Enterprise platí omezení na serveru 1C:Enterprise.

Tato možnost (POVOLENO) však nebude fungovat, pokud v dotazu odkazujeme na tabulku, pro kterou nejsou konfigurována omezení přístupu, ale ve které jsou odkazy na řádky tabulky s nakonfigurovanými omezeními. V tomto případě bude výsledkem dotazu "<Объект не найден>…..." místo hodnoty referenčního pole.

Pokud vytváříte sestavu nebo zpracováváte pomocí obecných nebo vlastních konfiguračních dotazů, vždy zaškrtněte příznak "Povoleno". aby report fungoval pod jakýmkoli uživatelem s jakýmkoli souborem práv.

V případě objektového čtení dat z databáze není možné nastavit příznak "Povoleno". Proto je nutné konfigurovat výběry pro čtení objektů s ohledem na možná omezení přístupových práv pro uživatele. V objektové technologii neexistují žádné prostředky, jak získat pouze povolená data.

Je důležité, že pokud v dotazu není zadáno klíčové slovo POVOLENO, pak všechny filtry uvedené v tomto dotazu nesmějí kolidovat s žádným z omezení čtení databázových objektů použitých v dotazu. Navíc, pokud jsou v dotazu použity virtuální tabulky, musí být příslušné filtry aplikovány na samotné virtuální tabulky.

Cvičení 1. Tvůrce dotazů v nastavení RLS.

Poskládejme text části "KDE" v dotazu na adresář. Můžete použít tvůrce dotazů.
Konstruktor je zkrácen.

Záložka "Tabulky"

Hlavní tabulkou bude tabulka objektu, pro který se konfiguruje omezení.

Na záložce "Vztahy" můžete také vybrat další tabulky a nastavit mezi nimi různé vztahy.

Záložka Podmínky

Zde můžete nakonfigurovat skutečné podmínky pro omezení přístupu.

Do všech polí tabulky přidáme podmínky pro atribut "Cena" adresáře skladového listu pro právo "číst".

"Nomenklatura WHERE Nomenklatura. Cena > 500"

Pojďme se podívat, jak toto jednoduché pravidlo funguje. Referenční tabulka obsahuje následující prvky:

Po nastavení omezení přístupu se v tabulce zobrazí pouze prvky, které splňují podmínku:

Skupiny také zmizely. Změňte text omezení

"Nomenklatura WHERE Nomenklatura. Cena > 500

OR Nomenklatura. Toto je skupina"

No, teď je to, co potřebujete.

Pokud v nastavení seznamu odeberete zobrazení pole “kód”, zobrazí se všechny prvky adresáře, tzn. omezení nefungovalo. Pokud nastavíte zobrazení pole "Kód", omezení bude fungovat.

Zároveň, přestože je vyhledávací prvek v poli seznamu viditelný, nelze jeho formulář otevřít, protože je nastaveno omezení atributu. Totéž v libovolném požadavku: při pokusu o získání atributu „omezený“ dojde k chybě přístupu.

Pokud se pokusíte získat "omezené" rekvizity programově, bude také vyvolána chyba přístupu.

Navíc nebude možné přistupovat k žádným polím objektu prostřednictvím odkazu, protože při přijetí odkazu systém přečte celý objekt, a pokud má „omezené“ detaily, objekt nebude načten.

Při programové práci s databázovými objekty je tedy potřeba pamatovat na možná omezení na úrovni záznamu a získat všechna potřebná objektová data dotazem a následně je umístit do struktury nebo provést část kódu v privilegovaném modulu.

Po nastavení omezení přístupu se změnilo zobrazení řádku v seznamu práv - zešedl a objevila se ikona.

Omezení konfigurace přístupu (RLS).

• Žádná sekce Souhrn;
• Nemůžete přistupovat k tabulkám virtuálních registrů;
• Nemůžete explicitně použít parametry;
• Poddotazy lze použít any>/span> jazykové prostředky dotazu, kromě:
  • operátor V HIERARCHII;
  • nabízí VÝSLEDKY;
  • vnořené výsledky dotazu nesmí obsahovat tabulkové části>/span>;
  • virtuální stoly, zejména Zůstatky a Obraty

Cvičení 2. Nomenklatura s aktuální cenou.

Proveďte omezení přístupu, pokud potřebujete zobrazit položku s aktuální cenou vyšší než určitá hodnota, například 100.

Řešení:

Přidáváme nové pravidlo omezení přístupu pro referenční knihu „Nomenklatura“ pro právo „číst“.
Vyberte "jiná pole".
V konstruktoru přidejte vnořený dotaz. V něm vyberte tabulku evidence informací "Ceny položek".
Neexistuje žádná karta „objednávka“ - to je funkce nástroje pro vytváření dotazů pro vytváření dotazu na omezení přístupu.
Na záložce „Upřesnit“ nastavte „první 999999999“, objevila se karta „objednávka“.
Nastavte řazení podle pole "Období" v sestupném pořadí.
Poté nastavíme spojení hlavní tabulky s poddotazem odkazem.

Šablony pro omezení přístupu.

Cvičení 3. Omezení "dodavatelů" hodnotou v konstantě.

Nastavte omezení přístupu pro adresář Counterparties podle hodnoty uložené v konstantě.

Navíc je potřeba v detailech nastavit omezení pro všechny objekty, které používají adresář "Dodavatelé".

Řešení

Pro referenční knihu „Účty“ pro právo „čtení“ nastavíme omezení přidáním vnořeného dotazu ke konstantě do sekce „Podmínky“. Nezapomeňte na tuto skupinu.

Vidíme problém, adresář Counterparties je filtrován správně a jsou zobrazeny všechny dokumenty s atributem „Protistrana“, některé s „nefunkčními“ odkazy v atributu „Protistrana“.

Nyní je třeba nakonfigurovat omezení přístupu pro všechny objekty pomocí odkazu na "Účty". Najdeme je pomocí služby „hledat odkazy na objekt“.

Zkopírujeme a mírně upravíme text podmínky RLS z adresáře "Protistrany". Toto musí být provedeno tolikrát, kolikrát je nalezených objektů.

Nebo použijte vzor omezení přístupu, abyste se vyhnuli problémům s duplikací kódu.

Šablony omezení přístupu se konfigurují na úrovni role a lze je použít pro jakýkoli objekt v rámci upravované role.

Do šablony můžete vložit jakoukoli část textu omezení přístupu. Šablona se volá pomocí symbolu "#". Například #TemplateContractor.

Prostřednictvím # v 1C se instrukce zapisují do preprocesoru. V kontextu provádění nastavení omezení přístupu platforma nahradí text volání šablony textem šablony.

Přesuňme text za slovem WHERE do šablony "TemplateContractor", kromě textu o ThisGroup.

Parametry v šablonách omezení přístupu.

Pokračujme v řešení problému 2.

Problém je nyní v tom, že hlavní tabulka v adresáři se v dokumentu "Faktura" nazývá "protistrana". Zaškrtnuté pole v adresáři se nazývá "odkaz", v dokumentu - "Protistrana".

Změňte název hlavní tabulky v textu šablony na „#CurrentTable“

"#CurrentTable" je předdefinovaný parametr.

A přes tečku označujeme číslo vstupního parametru - „.#Parameter(1)

"#Parameter" je také předdefinovaná hodnota. Může obsahovat libovolný počet vstupních parametrů. Jsou označeny sériovým číslem.

V textu omezení přístupu k adresáři uvádíme následující:

Pro dokument následující:

„Prodej zboží WHERE #TemplateContractor (“Dodavatel”)”

Při volání šablony omezení přístupu by jí měly být parametry předány pouze jako řetězec, tedy v uvozovkách.

Hlavní tabulka - Nomenklatura

Text šablony je:

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

Text šablony obsahuje část textu v jazyce omezení přístupu k datům a může obsahovat parametry, které jsou zvýrazněny symbolem „#“.

Za znakem „#“ může následovat:

• Jedno z klíčových slov:
  • Parametr následovaný číslem parametru v šabloně v závorce;
  • CurrentTable - znamená vložení do textu celého názvu tabulky, pro kterou je omezení budováno;
  • Aktuální název_tabulky– označuje vložení celého názvu tabulky (jako řetězcová hodnota v uvozovkách), na kterou je instrukce aplikována, do textu v aktuální verzi vestavěného jazyka;
  • NameCurrentPermission– obsahuje název práva, pro které se aktuální omezení provádí: ČÍST/ČÍT, PŘIDAT/VLOŽIT, ZMĚNIT/AKTUALIZOVAT, VYMAZAT/VYMAZAT;
• název parametru šablony – znamená vložení omezení odpovídajícího parametru šablony do textu;
• symbol "#" - označuje vložení jediného symbolu "#" do textu.

Výraz omezení přístupu může obsahovat:

• Vzor omezení přístupu, který je zadán ve formátu #TemplateName("Hodnota parametru šablony 1", "Hodnota parametru šablony 2",...). Každý parametr šablony je uzavřen ve dvojitých uvozovkách. Pokud potřebujete v textu parametru zadat znak dvojitých uvozovek, použijte dvě dvojité uvozovky.
• Funkce StrContains (kde hledáme, co hledáme). Funkce je navržena tak, aby hledala výskyt WhatLooking for v řetězci WhereLooking for. Vrátí True, pokud je nalezena shoda, False jinak.
• Operátor + pro zřetězení řetězců.

Pro usnadnění úprav textu šablony klikněte na kartě Šablony omezení ve formuláři role na tlačítko Nastavit text šablony. V dialogovém okně, které se otevře, zadejte text šablony a klikněte na OK.

Nelze je nainstalovat pomocí setParameter() nebo něco podobného.

V tomto případě jsou parametry:

• Možnosti relace
• Funkční možnosti

Čtení parametrů relace v požadavku na omezení přístupu probíhá v privilegovaném režimu, tj. bez kontroly práv s nimi pracovat.

Cvičení 4. Přístup k „vašim“ protistranám

Je nutné nastavit omezení přístupu aktuálního uživatele k "svým" protistranám.

Existuje adresář "Uživatelé", adresář "Protistrany", dokumenty s požadovaným "Protistrana".

Aktuální uživatel by měl vidět data pouze pro ty protistrany, pro které je s ním navázáno spojení.

Také je potřeba nakonfigurovat komunikaci.

Možné možnosti:

Navazování spojení uživatel + protistrana

• Podrobnosti v adresáři protistran
• Registr informací

Možná řešení problému:

• Uložení uživatele do konstanty je špatná volba, konstanta je dostupná všem uživatelům.
• Udržování pevného pole protistran aktuálního uživatele v parametrech relace není dobrá volba, protistran může být mnoho
• Uložte do parametrů relace aktuálního uživatele a poté požádejte o získání seznamu „jeho“ protistran – přijatelná možnost.
• Jiné možnosti.

Řešení.

Vytvořme nový parametr session „CurrentUser“ a jeho vyplnění zapišme do modulu session.

Vytvořme registr informací "Korespondence manažerů a protistran"

Vytvořme novou roli a v ní nové omezení přístupu k dokumentu „Příjmová faktura“.

V textu dotazu propojíme hlavní tabulku s registrem informací podle Dodavatel = Dodavatel a Manažer = &Aktuální uživatel. Typ připojení Vnitřní.

Pokud je to možné, je lepší se vyhnout vnořeným dotazům v textech o omezení přístupu, protože se spustí pokaždé, když jsou data z tohoto objektu načtena z databáze.

Kontrolujeme - omezení fungují

* Funkce: Pokud změníte seznam protistran uživatele v registru, omezení přístupu se projeví okamžitě bez restartování uživatelské relace.

Cvičení 5. Beze změny data.

Omezení editace údajů je nutné zavést dříve, než je datum stanovené pro zákaz změn.
Uživatelé musí být omezeni.

Vytvořme registr informací "ChangeBarDateDate" s dimenzí Uživatel, zdroj RestrictedDate.

Sestavme logiku řešení tímto způsobem:

• pokud uživatel není uveden, pak se zákaz vztahuje na všechny uživatele
• pokud existuje omezení pro všechny uživatele a omezení pro konkrétního uživatele, pak existuje omezení pro konkrétního uživatele a pro ostatní podle obecného principu.

Je zřejmé, že takový limit lze nakonfigurovat pro databázové objekty, které mají určitou polohu na časové ose. To může být

• Dokumentace
• Periodické informační registry

Vytvořme novou roli „RestrictionsBy ChangeProhibitionDate“.

V něm u dokumentu "Příjmová faktura" pro správnou "změnu" přidáme nové omezení přístupu.

Nastavení je určeno pro všechna pole.

Text omezení je:

Příjem faktura Z dokladu Příjem faktura JAKO faktura Faktura

ChangeProhibitionDates.ProhibitionDate AS Datum zákazu
Z

VNITŘNÍ SPOJENÍ (VYBRAT
MAXIMUM(Datum zákazu změny.Uživatel) JAKO Uživatel
Z
Rejstřík informací Termíny zákazu změn JAKO datum zákazu změn
KDE
(ChangeProhibitionDates.User = &CurrentUser
ORChangeProhibitionDate.User = VALUE(Reference.users.NullReference))) AS OT_User
BYChangeProhibitedDate.User = OT_User.User) AS dílčí dotaz
Faktura Invoice.Date > NestedRequest.BanDate

Kontrolujeme - omezení funguje.

Použití instrukcí preprocesoru

#Pokud podmínka1 #Potom

Žádost o fragment 1

#ElseIf Podmínka2 #Potom

Žádost o fragment 2

#V opačném případě

Fragment žádosti 3

#EndIf

V podmínkách můžete používat logické operace (a. nebo, ne atd.) a přístup k parametrům relace.

Tento přístup v kontextu omezení přístupu k budování je vhodný, protože v závislosti na podmínkách bude zkompilován kratší text dotazu. Jednodušší požadavek zatěžuje systém méně.

Nevýhodou je, že konstruktor dotazu s takovým textem nebude pracovat.

*Zvláštnost:

Na rozdíl od instrukcí pro preprocesor 1C:Enterprise v textech o omezení přístupu před operátor Then znak hash — #Then

Cvičení 6. Přepněte "Použít RLS"

Doplňme náš systém omezení o přepínač, který povolí/zakáže použití omezení na úrovni záznamu.

Chcete-li to provést, přidejte konstantu a parametr relace s názvem "UseRLS".

Zapišme si do Session Module nastavení hodnoty parametru session z hodnoty konstanty.

Přidejte následující kód do všech textů o omezení přístupu:

"#If &UseRLS #Then….. #EndIf"

Kontrolujeme - vše funguje.

Nyní po zapnutí příznaku „použít radar“ se však změny neprojeví okamžitě. Proč?

Protože parametr relace je nastaven při zahájení relace.

Je možné resetovat parametr relace, když je zapsána nová konstantní hodnota, ale to bude fungovat pouze pro aktuální uživatelskou relaci. Ostatní uživatelé musí být vyzváni k restartování systému.

Konec prvního dílu.

   

17 pravidel pro sestavení optimální REQUEST na data databáze 1C

Pro vytváření a provádění dotazů do databázových tabulek na platformě 1C se používá speciální objekt programovacího jazyka. Žádost. Tento objekt je vytvořen voláním konstruktu Nová žádost. Dotaz je vhodné použít, když potřebujete získat komplexní výběr dat, seskupených a setříděných podle potřeby. Klasickým příkladem použití dotazu je získání souhrnu stavu akumulačního registru v určitém časovém okamžiku. Mechanismus dotazů také usnadňuje získávání informací v různých časových úsecích.

Text požadavku je instrukce, podle které má být požadavek proveden. V těle žádosti je popsáno:

• tabulky databáze používané jako zdroje dat dotazů;
• pole tabulky, která je třeba v dotazu zpracovat;
• pravidla seskupování;
• třídění výsledků;
• atd.

Instrukce je sestavena ve speciálním jazyce - dotazovacím jazyce a skládá se z oddělených částí - sekcí, vět, klíčových slov, funkcí, aritmetických a logických operátorů, komentářů, konstant a parametrů.

Dotazovací jazyk platformy 1C je velmi podobný syntaxi jiných jazyků SQL, existují však rozdíly. Hlavní výhody vestavěného dotazovacího jazyka jsou: dereferencování polí, virtuální tabulky, pohodlná práce se součty, netypovaná pole v dotazech.

Doporučení pro psaní databázových dotazů v dotazovacím jazyce platformy 1C:

1) Tělo požadavku může obsahovat předdefinovaná konfigurační data, jako jsou:

• enum hodnoty;
• předdefinované údaje:
• adresáře;
• plány typů charakteristik;
• Účtové osnovy;
• plány typů výpočtů;
• prázdné odkazy;
• hodnoty průjezdních bodů obchodních procesů.

Text požadavku může také obsahovat systémové hodnoty výčtu, které lze přiřadit polím v databázových tabulkách: AccumulationMotionType, AccountType a AccountingMovementType. Požadavky odkazují na předdefinovaná konfigurační data a systémové hodnoty výčtu pomocí literálu typu funkce VALUE. Tento literál zlepšuje čitelnost dotazu a snižuje počet parametrů dotazu.

Příklad použití literálu VÝZNAM:

• WHERE Město = HODNOTA(Adresář.Města.Moskva)
• WHERE City = VALUE(Reference.Cities.EmptyReference)
• WHEREItemType = VALUE(Enumeration.ProductTypes.Service)
• WHEREMovementType = VALUE(Typ pohybuAkumulace.Příjem)
• WHERE RoutePoint = HODNOTA(BusinessProcess.BusinessProcess1.RoutePoint.Action1

2) Pomocí návodu AUTO OBJEDNÁVKA v dotazu může být doba provádění dotazu velmi dlouhá, takže pokud není řazení vyžadováno, je lepší jej nepoužívat vůbec. Ve většině případů je nejlepší způsob řazení pomocí příkazu SEŘAZENO PODLE.

Automatické řazení funguje podle následujících principů:

• Pokud byla v dotazu uvedena klauzule ORDER BY, pak každý odkaz na tabulku v této klauzuli bude nahrazen poli, podle kterých je tabulka standardně řazena (u adresářů je to kód nebo název, u dokumentů datum dokumentu). Pokud pole řazení odkazuje na hierarchický adresář, použije se hierarchické řazení podle tohoto adresáře.
• Pokud v dotazu není klauzule ORDER BY, ale existuje klauzule TOTALS, bude výsledek dotazu seřazen podle polí přítomných v klauzuli RESULTS za klíčovým slovem BY, ve stejném pořadí a pokud byly součty vypočteny podle pole - odkazy, pak pomocí třídicích polí ve výchozím nastavení tabulek, na které se odkazovalo.
• Pokud v dotazu nejsou žádné klauzule ORDER BY a TOTAL, ale existuje klauzule GROUP BY, bude výsledek dotazu seřazen podle polí přítomných ve větě ve stejném pořadí, a pokud bylo seskupení provedeno podle polí - odkazy a poté standardně třídí tabulky polí, na která se odkazovalo.
• Pokud dotaz neobsahuje klauzule a ORDER BY, TOTAL a GROUP BY, bude výsledek seřazen podle výchozích třídicích polí pro tabulky, ze kterých jsou data vybírána, v pořadí, v jakém se objeví v dotazu.
• Pokud dotaz obsahuje klauzuli TOTAL, každá úroveň součtů se objednává samostatně.

3) Chcete-li se vyhnout opětovnému dotazování databáze při zobrazení výsledku dotazu uživateli (například vytvoření dotazu nebo zobrazení výsledku dotazu pomocí tabulkového dokumentu), je užitečné použít instrukci ODKAZY NA PREZENTACI A, které vám umožní získat reprezentaci referenční hodnoty. Příklad:

Je také možné použít návod VÝKON- navržený k získání řetězcové reprezentace hodnoty libovolného typu. Rozdíl mezi těmito instrukcemi je v tom, že v prvním případě, pokud instrukce předají odkaz, bude výsledkem řetězec, v ostatních případech bude výsledkem hodnota předávaného parametru. V druhém případě bude výsledkem instrukce vždy řetězec!

4) Pokud dotaz obsahuje pole složeného typu, pak pro taková pole je nutné přetypovat hodnoty pole na konkrétní typ pomocí instrukce VYJÁDŘIT, což vám umožní odstranit nepotřebné tabulky z levého spojení s polem složeného datového typu a urychlit dotaz. Příklad:

Existuje registr pro hromadění zbytků zboží, ve kterém má pole Registrátor složený typ. V požadavku je vybráno Datum a číslo dokladů o příjmu zboží, přičemž při přístupu k detailu dokladu přes pole Registrátor nedochází k mnoha levým spojením tabulky akumulačního registru s tabulkami dokladů evidence.

Kód 1C v 8.x SELECT
EXPRESS(Zbytky zboží. Evidence JAKO doklad. Příjem zboží). Číslo AS Číslo účtenky,
EXPRESNÍ (Zbytky zboží. Registrátor AS doklad. Příjem zboží).Datum AS Datum převzetí
Z
Registr akumulace. Zbytky zboží AS Zbytky zboží

Pokud je obsazení považováno za neproveditelné, pak výsledkem je hodnota NULA.

5) Nezapomeňte na pokyny POVOLENO, což znamená, že dotaz vybere pouze záznamy, pro které má aktuální uživatel oprávnění. Pokud toto slovo není uvedeno, pak v případě, kdy dotaz vybere záznamy, ke kterým uživatel nemá práva, bude dotaz pracovat s chybou.

6) Pokud dotaz používá sjednocení a v některých částech sjednocení jsou vnořené tabulky (dokument s tabulkovou částí) a v některých není potřeba doplňovat výběrový seznam o pole - prázdné vnořené tabulky. To se provádí pomocí klíčového slova PRÁZDNÝ, za nímž jsou v závorkách uvedeny aliasy polí, ze kterých se bude vnořená tabulka skládat. Příklad:

Kód 1C v 8.x // Vyberte pole Číslo a Složení
// z virtuální tabulky Document.Invoice
ZVOLTE Referenční číslo, PRÁZDNÁ TABULE. (Nom, Tov, Množství) JAKO KOMPOZICE
Z dokumentu. Faktura
SPOJETE VŠECHNY
SELECT Link.Number, Composition. (LineNumber, Product, Quantity)
FROM Document.Invoice Document.Invoice.Composition.*

7) Abyste se vyhnuli duplicitním řádkům ve výsledku dotazu, měli byste použít instrukce ROZLIČNÝ, protože je to jasnější a jasnější, a návod SKUPINA VYTVOŘENÁ používá se pro seskupování pomocí agregačních funkcí. Mimochodem, při použití agregačních funkcí je věta SKUPINA VYTVOŘENÁ nemusí být zadáno vůbec, zatímco všechny výsledky dotazu budou seskupeny do jednoho řádku. Příklad:

Kód 1C v 8.x // Je třeba zjistit, které protistrany
// zboží bylo expedováno po dobu.
Vyberte Různé
Dokument.Faktura.Dodavatel

8) Instrukce SKUPINA VYTVOŘENÁ umožňuje přístup k polím nejvyšší úrovně bez seskupování výsledků podle těchto polí, pokud jsou na pole vnořené tabulky použity agregační funkce. Ačkoli je to napsáno v nápovědě 1C, při seskupování výsledků dotazu musí být agregační funkce uvedeny v seznamu výběrových polí a kromě agregačních funkcí lze v seznamu výběru uvést pouze pole, podle kterých se seskupování provádí. pole. Příklad:

Kód 1C v 8.x SELECT
Příjem zboží a služeb (součet (množství), nomenklatura),
Příjem zboží a služeb. Odkaz,
Příjem zboží a služeb. Protistrana
Z
Dokument Příjem zboží a služeb AS Příjem zboží a služeb
SKUPINA VYTVOŘENÁ
Příjem zboží a služeb. Zboží. (Nomenklatura)

9) Instrukce ISNULL určené k nahrazení hodnoty NULA na jinou hodnotu, ale nezapomeňte, že druhý parametr bude převeden na typ prvního, pokud je typem prvního parametru řetězec nebo číslo.

10) Při odkazování na hlavní tabulku můžete odkazovat na data podřízené tabulky v podmínce. Tato funkce se nazývá dereferencování polí podtabulky.

Příklad (hledejte dokumenty obsahující určitý produkt v tabulkové části):

Výhodou tohoto dotazu oproti dotazu na podtabulku Incoming.Goods je, že pokud jsou v dokumentech duplikáty, výsledek dotazu vrátí pouze jedinečné dokumenty bez použití klíčového slova DISTINCT.

11) Zajímavou variantou operátoru B je kontrola výskytu uspořádané množiny v množině takových množin (Pole1, Pole2, ... , PoleN) B (Pole1, Pole2, ... , PoleN).

Kód 1C v 8.x SELECT
Dodavatelé. Odkaz
KDE
(Contractors.Link, Goods.Link)
(SELECT Sales.Customer, Sales.Product
Z registru akumulace. Prodej AS Prodej)
Z
Adresář. Protistrany,
Adresář.Produkty

12) Kdykoli je to možné, používejte virtuální tabulky dotazů. Při vytváření dotazu poskytuje systém jako zdroje dat řadu virtuálních tabulek – jedná se o tabulky, které jsou zároveň výsledkem dotazu, který systém vygeneruje v okamžiku spuštění příslušné části kódu.

Vývojář může nezávisle získat stejná data, která mu systém poskytuje jako virtuální tabulky, ale algoritmus pro získání těchto dat nebude optimalizován, protože:

Všechny virtuální tabulky jsou parametrizované, tj. vývojář má možnost nastavit některé parametry, které systém použije při generování požadavku na vytvoření virtuální tabulky. V závislosti na tom, jaké parametry virtuální tabulky zadá vývojář, může systém generovat ROZLIČNÝ dotazy, abyste získali stejnou virtuální tabulku, a budou optimalizovány z hlediska předávaných parametrů.

Pro vývojáře není vždy možné získat přístup k datům, ke kterým má systém přístup.

13) V režimu provozu klient-server funkce SUBSTRING() implementováno pomocí funkce SUBSTRING() odpovídajícího SQL příkazu předávaného databázovému serveru SQL Server, který vypočítává typ výsledku funkce SUBSTRING() podle složitých pravidel v závislosti na typu a hodnotách jejích parametrů, jakož i v závislosti na kontextu, ve kterém se používá. Ve většině případů tato pravidla neovlivňují provádění dotazu, ale existují případy, kdy je pro spuštění dotazu nezbytná maximální délka výsledného řetězce vypočtená SQL Serverem. Je důležité mít na paměti, že v některých kontextech při použití funkce SUBSTRING() může být maximální délka jejího výsledku rovna maximální délce řetězce omezené délky, což je na serveru SQL Server 4000 znaků. To může vést k neočekávanému selhání při provádění dotazu:

Poskytovatel Microsoft OLE DB pro SQL Server: Upozornění: Procesor dotazu nemohl vytvořit plán dotazů z optimalizátoru, protože celková délka všech sloupců v klauzuli GROUP BY nebo ORDER BY přesahuje 8000 bajtů.

HRESULT=80040E14, SQLSTATE=42000, nativní=8618

14) Používejte opatrně NEBO ve výstavbě KDE, protože použití podmínky s operátorem OR může výrazně "zavážit" dotaz. Problém lze vyřešit designem SPOJETE VŠECHNY. Příklad:

Kód 1C v 8.x SELECT

Z

KDE
_DemoContractors.Link =Odkaz1
SPOJETE VŠECHNY
VYBRAT
_Demo Counterparties.NameFull
Z
Adresář._DemoContractors JAK _DemoContractors
KDE
_DemoContractors.Link =Odkaz2

15) Stav NENÍ IN ve výstavbě KDE zvyšuje dobu provedení požadavku, protože je to druh NE (OR1 OR2 ... ORn), takže pro velké stoly zkuste použít LEFT JOIN s podmínkou IS NULL. Příklad:

Kód 1C v 8.x SELECT
_DemoContractors.Link
Z
Adresář._DemoContractors JAK _DemoContractors
LEFT JOIN Document._DemoBuyerOrder AS _DemoBuyerOrder
Software _DemoContractors.Link = _BuyerDemoOrder.Contractor
KDE
_Demoobjednávka kupujícího. Protistrana JE NULOVÁ

16) Při použití Dočasné tabulky musíte indexovat podmínku a spojit pole v těchto tabulkách, ALE při použití indexů může dotaz běžet ještě pomaleji. Proto je nutné analyzovat každý dotaz s indexem i bez něj, změřit rychlost provádění dotazu a učinit konečné rozhodnutí.

Pokud umístíte data do dočasné tabulky, která je zpočátku indexována v některých polích, pak již nebude index těchto polí v dočasné tabulce.

17) Pokud nepoužíváte Správce dočasné tabulky, pak není nutné dočasnou tabulku explicitně mazat, bude odstraněna po dokončení provádění dávkového dotazu, jinak by měla být dočasná tabulka smazána jedním z následujících způsobů: příkazem ZNIČIT v požadavku zavolejte metodu TemporaryTable Manager.Close().

A kromě videa od Evgenyho Gileva: Typické chyby při psaní požadavků na 1C: