Byť v skupine podľa hierarchie 1C 8 Operátor „v hierarchii“ v požiadavke. Získanie všetkých rodičov prvku

12.12.2023nadpis: Bezpečnosť

Ildarovič 6489 16.11.12 18:24 Aktuálne k téme

() Vladimír! Som rád, že ste venovali pozornosť článku, najmä preto, že ste boli jedným z prvých, ktorí túto techniku videli (a ocenili) v diskusii pred dvoma rokmi „Je realistické napísať zložitý dotaz“. Na zaujímavú otázku som neprišiel sám, ale videl som ju na fóre. Autorom otázky je Stanislav Sheptalov. Ďalej - 24. 10. 2012 ten istý (len si to všimol, keďže prezývka je iná) účastník fóra položil podobnú otázku, ale pri aplikácii do hierarchie. Ukazuje sa, že PRAKTICKÝ problém je vyriešený. Ďalej, v súlade s „vedeckým“ prístupom, som sa pozrel na praktické problémy, kde by sa táto technika dala použiť. Našlo sa ďalších 7 problémov. 5 - v tomto článku. Medzi nimi je problém o cykloch v špecifikáciách, ktorý som predtým sľúbil vyriešiť Ish_2 jedným dotazom. Myslím, že Ish_2 vás bude môcť presvedčiť o relevantnosti tejto úlohy - strávil na nej veľa času. Riešenie je krátke – niekoľko riadkov, teda mimoriadne jasné, formulované neprocedurálnym štýlom, cez požiadavku na výsledok. V článkoch a na fóre sa vyskytli ďalšie problémy a navrhli sa pre ne ťažkopádnejšie riešenia. Počkajme si teda, ako často sa to bude používať. Presne takúto spätnú väzbu očakávam – od tých, ktorí sa o to pokúsia.
Mimochodom, o tom, že tento odbor matematiky nie je ďaleko od praxe a je potrebný pre účtovníkov, svedčí všeobecný modul „Úprava nákladov“ v BP2, s ktorým sa momentálne finišujeme (nestabilná prevádzka štandardnej požiadavky). Tam hovoríme o prerušení cyklov grafu pohybu položiek a zostavení kostry.
Teraz o štruktúre databázy „pre konkrétnu úlohu“. Bola položená otázka o implementácii úlohy v 1C, a preto bola úloha vyriešená v 1C. Ak by ste sa vás opýtali „akým autobusom sa dostanete do knižnice“ a odpovedali by ste, že je lepšie letieť na vzducholode, potom by ste jednoducho nepochopili (možno okrem tých, ktorí uviazli v moskovskej dopravnej zápche ). Spočiatku metóda fungovala v úplne inom jazyku.
Vo všeobecnosti vás nebudem môcť presvedčiť, ak si myslíte, že architektúra platformy 1C nie je dobrá. Môžem len vyjadriť svoj názor. Vývoj databázovej schémy od začiatku pre konkrétnu úlohu je drahý. Ak to porovnáme s výstavbou: 1C sú panelové výškové budovy - lacné bývanie - prostriedok masovej automatizácie - v stiesnených podmienkach, ale bez urážky. Jednotlivé organizácie si môžu najať Normana Fostera, aby presne implementoval ich požiadavky. Zvyšok musí využívať lacné sériovo vyrábané projekty – relačné DBMS s rigidným objektovým modelom. Okrem toho poznám smutnú skúsenosť s používaním Cashe vo viacerých projektoch. Očami vývojára všetko nevyzerá tak ružovo ako teoreticky. Objektový model 1C obstojí v skúške časom – „rozľahlé územia sú vybudované a obývané“. Navyše sa rozvíja. Nedávno sa objavila technológia externých zdrojov údajov. A ak si niektorá úloha vyžaduje vyššiu reaktivitu (napríklad fakturačné systémy), môžete teraz bezproblémovo prepojiť 1C s iným DBMS. Takto napríklad vymieňame s importovaným ERP.
Ale napriek tomu by som nerád odvádzal rozhovor od hlavnej témy - práce navrhovaných techník v podrobných PRAKTICKÝCH úlohách.

Čo je adresár 1C a prečo je potrebný? V adresári sú uložené podmienene trvalé informácie, t.j. informácie, ktoré zostávajú takmer nezmenené počas dlhého časového obdobia. Napríklad adresár „Nomenklatúra“ obsahuje zoznam predaného alebo vyrobeného tovaru. Adresár môže tiež obsahovať veľa vlastností popisujúcich prvok adresára.

Ak na porovnanie vezmeme pohlavie osoby, potom je zoznam obmedzený a nemení sa, preto je preň vhodnejší zoznam.

Po vytvorení nového adresára uvidíme nasledujúci obrázok.

Pozrime sa na všetky jeho záložky.

Základné

Tu sa uvádza názov (identifikátor v databáze) a synonymum (používateľské meno adresára). Voliteľný komentár je taký, ktorý môže vysvetliť účel adresára alebo opísať jeho vlastnosti.

Hierarchia

Na tejto karte môžete nakonfigurovať hĺbku vnorenia prvkov adresára. Pomocou tohto nastavenia je vhodné rozlišovať a detailovať prvky podľa určitých kritérií. Napríklad produkty „Skrine“ sú v jednej skupine a produkty „Stoly“ sú v inej. V predvolenom nastavení sa po vytvorení adresár zobrazí zoznam prvkov. Ak zaškrtnete políčko Hierarchický adresár, potom každý prvok môže byť podriadený inému prvku (skupine). Nižšie sú uvedené možnosti prispôsobenia tejto záložky a zmeny zobrazenia vo vlastnom režime.

Typ hierarchie:

Hierarchia skupín a prvkov

Pri tomto nastavení môžu byť prvky vnorené iba do skupín (priečinkov).

Ako vidíte, všetky prvky a skupiny majú rovnaké ikony a ľubovoľný prvok možno vnoriť.

Umiestnite skupiny na vrch

Keď je toto políčko začiarknuté, skupiny budú vždy navrchu, inak budú usporiadané v poradí zoradenia, napríklad takto:

Obmedzenie počtu úrovní hierarchie

Ak tu nie je začiarknuté políčko, vkladanie je neobmedzené.

Ak je začiarkavacie políčko začiarknuté, nižšie môžete zadať počet úrovní.

Vlastníci

Na záložke vlastníkov môžu byť uvedené ďalšie adresáre, ktorým je tento podriadený. Diagram vzťahov podriadených adresárov je podobný diagramu vzťahov hierarchického adresára, len tu iný adresár vystupuje ako nadradený a nazýva sa vlastník. V typických konfiguráciách je dobrým príkladom podriadenie adresára „Dohody“ adresáru „Protistrany“, pretože Nemôže existovať dohoda, ktorá nepatrí žiadnej protistrane.

Pole "Zoznam vlastníkov adresára" určuje zoznam adresárov, ktoré vlastnia prvky tohto adresára.

Nižšie v poli „Použitie podriadenosti“ je uvedené, čomu budú prvky tohto adresára podriadené.

Ako programovo zistiť, či je adresár hierarchický alebo nie

Ak to chcete urobiť, musíte sa pozrieť na metadáta

Toto je Hierarchický Adresár = Metaúdaje. Adresáre. Protistrany. Hierarchické;

Pokračovanie nabudúce...

Adresáre 1C sú špecializovaný objekt stromu metadát, ktorý slúži na ukladanie statických referenčných informácií. Napríklad v typických konfiguráciách môžete vidieť nasledujúce zobrazenia: , Nomenklatúra, Zamestnanci, Dlhodobý majetok atď. Informácie v adresároch sa spravidla často nemenia. Adresáre sa následne používajú takmer vo všetkých účtovných objektoch ako účtovná sekcia alebo referenčné informácie.

Nižšie sa pozrieme na nastavenie a návrh adresára z konfigurátora pomocou adresára „Nomenklatúra“ ako príklad.

Základná karta

Karta „Základné“ špecifikuje názov, synonymum, reprezentáciu objektu a popis účelu.

Karta „Hierarchia adresára“.

Tu je stanovená hierarchia adresára.

Hierarchia v 1C 8.3 je dvoch typov - “ skupiny a prvky"A" prvkov". Líši sa tým, že v prvom prípade môže byť rodičom (priečinkom) iba priečinok (skupina) a v druhom prípade môže byť rodičom aj prvok.

„Umiestniť skupiny navrchu“ - príznak je zodpovedný za zobrazenie skupín vo forme zoznamu.

Taktiež v nastaveniach môžete obmedziť počet skupín v hierarchii adresárov pomocou príslušného nastavenia.

Vlastníci Tab

Adresár môže byť podriadený inému adresáru. Z hľadiska konfigurácie 1C 8.3 to znamená, že atribút „Owner“ sa stáva povinným pre podriadený prvok. Príklad takéhoto prepojenia medzi adresármi v štandardných konfiguráciách „Nomenklatúra – merné jednotky“, „Protistrany – zmluvy dodávateľov“.

Vlastníkom adresára môžu byť aj nasledujúce objekty metadát: , .

Údaje Tab

Získajte 267 video lekcií na 1C zadarmo:

Najdôležitejšia záložka z pohľadu programátora. Obsahuje podrobnosti o adresári.

Adresár obsahuje súbor štandardných podrobností, ktoré neupravuje programátor 1C 8.2, ich zoznam môžete zobraziť kliknutím na tlačidlo „Štandardné podrobnosti“:

Budem sa venovať každému podrobnejšie:

Táto skupina— atribút s booleovským typom, ktorý označuje, či ide o skupinu alebo prvok. Dostupné iba v hierarchickom adresári. Poznámka, hodnotu tohto atribútu nie je možné zmeniť v režime 1C: Enterprise.
kód— rekvizity, zadajte číslo alebo reťazec (zvyčajne reťazec). Číslo pridelené automaticky systémom. Zvyčajne sa vypočíta ako (predchádzajúci kód + 1). Odporúčam použiť typ reťazca, pretože triedenie číselných hodnôt nefunguje podľa očakávania. Dá sa použiť ako prezentácia adresára v zozname a vo vstupných poliach. Zvyčajne sa používa na vyhľadávanie prvku pri zadávaní reťazca. Ak potrebujete odstrániť pole Kód, zadajte do dĺžky riadku nulu.
názov— povinné údaje, typ reťazca. Maximálna dĺžka riadku je 150 znakov. Dá sa použiť ako prezentácia adresára v zozname a vo vstupných poliach. Zvyčajne sa používa na vyhľadávanie prvku pri zadávaní reťazca. Ak potrebujete odstrániť pole Názov, zadajte do dĺžky riadku nulu.
Rodič— atribút typu DirectoryLink.<ИмяТекущегоСправочника>. Dostupné iba v hierarchickom adresári. Ukazuje na nadriadeného rodiča v hierarchii. Ak je prvok alebo skupina v koreňovom adresári adresára, zadá sa hodnota Adresár.<ИмяТекущегоСправочника>.EmptyLink.
Vlastník— prepojenie na prvok vlastníka aktuálneho prvku adresára (skupiny). Dostupné iba v podriadenom adresári 1C.
FlagDelete— rekvizity typu Boolean. Zodpovedá za zobrazenie „značky vymazania“ v systéme. Prvok označený na vymazanie sa považuje za nepoužiteľný, ale môžu na ňom zostať staré pohyby dokumentov.
Odkaz— pole typu reťazec. Tento atribút uchováva jedinečný identifikátor objektu – GUID. To, čo vidíme v systéme na vizuálnom zobrazení nazývanom „odkaz“, je len reprezentácia objektu. Nedá sa zmeniť.
Preddefinované— booleovský typ, zobrazuje, či je prvok preddefinovaný, o tom neskôr. Nedá sa zmeniť.

Záložka „Údaje“ tiež uvádza reprezentáciu adresára v systéme pred verziou 8.2.16, reprezentácia môže byť iba Kód alebo Názov. V najnovších verziách platformy (od 8.3) je možné pohľad popísať nezávisle v module manažéra pomocou obslužného programu „ViewReceivingProcessing“.

Karta číslovanie

Tu môžete zadať nastavenia adresára týkajúce sa číslovania. Odporúča sa použiť automatické číslovanie. Kontrola jedinečnosti je príznak, ktorý v prípade potreby pomáha urobiť kód jedinečným. Ak sa s nastaveným príznakom pokúsite napísať prvok adresára s nejedinečným kódom, v 1C dostanete správu „Kód adresára sa stal nejedinečným“.

Kódová séria - určuje spôsob číslovania adresára môžete zadať číslovanie adresára podľa vlastníka; Napríklad protistrana „Rohy a kopytá“ bude mať svoje vlastné číslovanie zmlúv – „1, 2, 3“ atď.

Formuláre Tab

Formuláre pre adresár sú popísané tu. Ak je konfigurácia spustená v normálnom aj riadenom režime, potom budú predvolene dve karty s formulármi: „hlavné“ a „rozšírené“ - odlišné pre normálne a spravované aplikácie.

Táto stránka má dôležitú vlastnosť adresára - „“. Toto je veľmi pohodlná funkcia 1C 8, ktorá vám umožňuje pri vypĺňaní údajov do vstupného poľa nevstúpiť do adresára, ale zadať jeho názov, kód atď. a vyberte požadovaný prvok z rozbaľovacieho zoznamu. Vyzerá to takto:

Iné Tab

Na karte môžete získať rýchly prístup k hlavným modulom adresára - objektovému modulu a modulu manažéra.

Môžete tiež definovať zoznam preddefinovaných prvkov adresára na stránke. Toto sú položky, ktoré nie je možné odstrániť v režime Enterprise. K preddefinovaným prvkom je možné pristupovať priamo v konfigurátore podľa názvu, napríklad: Directories.Nomenclature.Service.

Táto záložka tiež určuje režim blokovania – automatický alebo riadený. Použitie fulltextového vyhľadávania, ako aj referenčné informácie o adresári, dostupné v režime 1C: Enterprise.

Dizajn „IN HIERARCHY“ v dotazoch 1C:Enterprise 8.x umožňuje získať podriadené prvky objektu hierarchickej konfigurácie podľa daného výberu. Dnes sa v článku pozrieme na príklad jej využitia, ako aj na akcie platformy na strane DBMS a jej vplyv na výkon.

Použitie

Pozrime sa na jednoduchý príklad použitia konštrukcie „IN HIERARCHIA“. Pri vykonávaní nasledujúcej požiadavky sa pre odovzdanú hodnotu premennej "Odkaz" získajú podriadené prvky hierarchického adresára "Produkty".

V testovacej databáze obsahuje adresár "Produkty" nasledujúce testovacie údaje:

Obrázok samozrejme nezobrazuje všetky položky adresára. Snímka obrazovky zobrazuje iba štruktúru uloženia údajov v hierarchickom adresári. V adresárovej tabuľke je uložených 10 skupín najvyššej úrovne, z ktorých každá obsahuje 5 vnorených skupín s 200 prvkami.

Vráťme sa k žiadosti o test. Odovzdajme odkaz na skupinu „Skupina – 1“ do parametra „&Odkaz“ (pozri snímku obrazovky vyššie). Potom bude výsledok dotazu vyzerať takto:

Ako vidíme, požiadavka vrátila odkaz na samotnú hornú skupinu (odovzdanú ako parameter), ako aj na vnorené skupiny s prvkami v nich. Použitie konštrukcie „IN HIERARCHY“ vám teda umožňuje pohodlne získať hierarchicky podriadené údaje.

Syntax dopytovacieho jazyka 1C:Enterprise klasický SQL v niektorých ohľadoch veľmi podobné. Ale pre výraz „IN HIERARCHIA“ neexistuje analóg v dopytovacom jazyku SQL, pretože napríklad pre výraz dopytovacieho jazyka platformy „B“ existuje podobný operátor SQL „IN“. Preto je práca platformy s DBMS pri použití tohto operátora zaujímavá.

V zákulisí

Tak poďme na to. Napríklad použijeme predtým napísaný dotaz pre adresár „Produkty“. Budeme analyzovať akcie platformy pre dve situácie:

Skupinu najvyššej úrovne „Group 1“ odovzdáme ako parameter „&Link“ (ako sme to urobili predtým).
V parametri odovzdáme odkaz na skupinu „Skupina 1 – 1“, vnorenú do skupiny najvyššej úrovne „Skupina 1“.

Teraz po poriadku. V prvom prípade platforma vykoná na serveri SQL nasledujúce akcie:

1. Najprv sa vykoná SQL dotaz na získanie prepojenia na skupinu adresárov odovzdanú ako parameter a všetky podriadené skupiny. Výsledok sa umiestni do dočasnej tabuľky "#tt1".

2. V druhej fáze sa rovnaký dotaz vykoná dvakrát:

Snímka obrazovky obsahuje podrobné komentáre k textu SQL dotazu. Stručne povedané, dotaz vám umožňuje vybrať podriadené prvky pre skupiny, na ktoré sa odkazuje v dočasnej tabuľke. Otázkou zostáva: "Prečo sa dotaz vykonáva dvakrát?" Odpoveď je jednoduchá: najprv dotaz dostane podriadené prvky pre skupiny prvej úrovne, ktoré sú už obsiahnuté v dočasnej tabuľke (pozri bod 1). Druhý dotaz potom načíta čiastkové prvky pre podskupiny druhej úrovne. Keďže na tretej úrovni hierarchie nie je prítomná žiadna skupina adresárov, tento dotaz sa už nevykoná.

V našom prípade druhý dotaz vráti prázdny výsledok, pretože neexistujú žiadne podriadené prvky pre záznamy umiestnené na 3. úrovni hierarchie (nie sú tam žiadne skupiny).

3. Na získanie konečného výsledku dotazu platforma vygeneruje nasledujúci SQL dotaz:

Výsledok tejto konkrétnej požiadavky môže byť ďalej spracovaný pomocou algoritmov v jazyku zabudovanom v platforme. Záznamy v dočasnej tabuľke "#tt1" sa teda používajú na nastavenie podmienky vzorkovania z referenčnej tabuľky "_Reference41".

4. V poslednom kroku platforma 1C:Enterprise 8.x vymaže dočasnú tabuľku „#tt1“, pretože sa už v budúcnosti nebude používať.

Tým sa dokončí proces vykonávania operátora „IN HIERARCHY“. Dovoľte mi pripomenúť, že uvažovaná postupnosť akcií na serveri SQL bola vykonaná, keď sme odovzdali odkaz skupine najvyššej úrovne „Skupina - 1“ na požiadavku na strane platformy. Ako sa však bude platforma správať, ak ako parameter „&Odkaz“ odovzdáme odkaz na skupinu druhej úrovne „Skupina – 1 – 1“? Všetko prebehne rovnako, až na nasledujúci bod: vyššie v druhej fáze vykonávania SQL dotazov platformou bolo napísané, že dotaz na získanie podriadených prvkov bol vykonaný dvakrát – v prípade získania podriadených prvkov pre skupina "Skupina - 1 - 1" to tak nie je. Žiadosť bude vykonaná iba raz.

Faktom je, že počet žiadostí o získanie podriadených prvkov závisí od počtu skupín v hierarchii. Inými slovami, ak úroveň hierarchie prvkov obsahuje aspoň jednu skupinu, potom žiadosť z bodu 2.

Vplyv na výkon

Nesprávne použitie ľubovoľného operátora v dotaze môže viesť k neoptimálnemu výkonu systému. Výnimkou nie je ani posudzovaný operátor „V HIERARCHII“. Musí sa používať opatrne, pretože značne komplikuje algoritmus na vykonávanie SQL dotazov do databázy a tým zvyšuje zaťaženie servera DBMS.

Dovoľte mi uviesť príklad suboptimálneho dopytu, ktorý môže viesť k smutným dôsledkom uvedeným vyššie:

VYBERTE produkty. Odkaz z adresára. Produkty AKO Produkty KDE (Produkty. Odkaz V HIERARCHII (& Link) ALEBO Produkty. Odkaz V HIERARCHII (& Link1) ALEBO Produkty. Odkaz V HIERARCHII (& Link2) )

Ako asi tušíte, požiadavka povedie ku generovaniu mnohých SQL dotazov, čo bude mať za následok zníženie výkonu informačného systému.

Vyvodzujte závery!

Je na vás, aby ste vyvodili závery. Dovoľte mi povedať, že operátor „IN HIERARCHY“ používa platforma pre systém zostavovania údajov, keď podmienky výberu zahŕňajú „IN GROUP“, „IN GROUP ZO ZOZNAMU“ a iné. Myslím, že nie je potrebné vysvetľovať, že pri nesprávnych manipuláciách môžu používatelia nastaviť veľmi zložité výbery a niekoľkokrát zvýšiť zaťaženie servera 1C a DBMS. Nastavenia meňte len skúseným používateľom.

A samozrejme pri písaní vlastných mechanizmov dávajte pozor na operátor “IN HIERARCHIA”. Na jednej strane veľmi pohodlné a na druhej nebezpečné.

Táto časť ukazuje príklady riešenia typických problémov pri práci s hierarchickými adresármi.

Získanie prvkov hierarchického adresára, ktoré sú podriadené danej skupine

Na získanie podriadených prvkov hierarchického adresára poskytuje dopytovací jazyk konštrukciu IN HIERARCHY. Príklad použitia V HIERARCHII:

VYBERTE SI
Nomenclature.Code,
Nomenklatúra.Nákupná cena
OD

V tomto príklade sa získajú všetky záznamy adresára Nomenclature nachádzajúce sa v skupine &Group, vrátane jeho samotného, jeho podriadených skupín a prvkov patriacich do podriadených skupín.

Ak nás zaujímajú len prvky a skupiny nachádzajúce sa priamo v danej skupine, tak takéto prvky môžeme získať nastavením podmienky v poli Parent. Príklad:

VYBERTE SI
Nomenclature.Code,
Nomenklatúra Názov AS Názov,
Nomenklatúra.Nákupná cena
OD
Adresár.Nomenklatúra AS Nomenklatúra

KDE
Nomenklatúra.Rodič = &Skupina

Tento dotaz vyberie skupiny a prvky podriadené skupine s prepojením &Skupina.

Kontrola prítomnosti podriadených prvkov prvku adresára

Ak chcete skontrolovať prítomnosť podriadených záznamov prvku adresára, môžete použiť dotaz podobný tomu, ktorý je uvedený:

V tomto príklade je odkaz na prvok, pre ktorý chcete skontrolovať deti, zapísaný do parametra rodičovského dotazu. Po vykonaní takéhoto dotazu musíte skontrolovať, či je výsledok prázdny. Ak výsledok nie je prázdny, existujú podriadené záznamy. Inak - nie. Príklad:

If Request.Execute().Empty() Then
Správa ("Žiadne záznamy");
Inak
Správa ("Dostupné záznamy");
koniec Ak;

Získanie všetkých rodičov prvku

Dopytovací jazyk neposkytuje žiadne špeciálne prostriedky na získanie všetkých rodičov prvku. Na dokončenie úlohy môžete použiť hierarchické súčty, ale získavanie hierarchických súčtov je optimalizované na vytváranie súčtov pre veľký počet záznamov a nie je úplne efektívne na získanie rodičov jedného prvku. Ak chcete efektívnejšie získať všetky rodičovské záznamy prvku, odporúča sa prechádzať cez jeho rodičov v malých častiach. Príklad:

CurrentItemItem = ItemItem;

Zatiaľ čo cyklus pravdy
Request.SetParameter("CurrentItemItem", CurrentItemItem);
Vysledok = Query.Run();
If Result.Empty() Then
Prerušiť;
koniec Ak;
Výber = Vysledok.Vyber();
Selection.Next();
Pre ColumnNumber = 0 Podľa Result.Columns.Quantity() - 1 slučka
CurrentItemItem = Selection[ColumnNumber];
Prerušiť;
Inak
Správa(AktuálnaPoložka);
koniec Ak;
EndCycle;

Ak CurrentItemItem = Directories.Nomenclature.EmptyLink() Then
Prerušiť;
koniec Ak;
EndCycle;

V tomto príklade sa v okne servisnej správy zobrazia všetci rodičia pre prepojenie zaznamenané v premennej ElementNomenclature. V cykle sa vyberie 5 odkazových rodičov.

Ak je počet úrovní v adresári obmedzený a malý, potom je možné získať všetkých rodičov jednou požiadavkou bez slučky.

Zobrazenie hierarchického adresára v zostave

Ak chcete zobraziť hierarchický adresár v zostave pri zachovaní hierarchie, musíte použiť dotaz podobný tomuto:

VYBERTE SI
Nomenclature.Code,
Nomenklatúra Názov AS Názov,
Nomenklatúra.Nákupná cena
OD
Adresár.Nomenklatúra AS Nomenklatúra
TRIEDIŤ PODĽA
Názov HIERARCHIA

Tento dotaz vyberie všetky záznamy z adresára a usporiada ich do hierarchie. Výsledok bude zoradený podľa mena s prihliadnutím na hierarchiu.

Aby sa skupiny adresárov umiestnili nad prvky, je potrebné nahradiť klauzulu ORDER BY v tejto požiadavke nasledujúcim:

TRIEDIŤ PODĽA
Nomenklatúra. Toto je skupina HIERARCHIA,
názov

Výsledok bude stále usporiadaný hierarchicky, ale skupiny sa zobrazia nad prvkami.

Ponuku OBJEDNÁVKA je tiež možné nahradiť možnosťou AUTOMATICKÁ OBJEDNÁVKA. V tomto prípade bude výsledok zoradený v súlade s nastavením adresára, t.j. ak je v adresári uvedené, že skupiny by mali byť umiestnené nad prvkami, potom budú umiestnené vyššie.

Pomocou výsledkov je tiež možné získať hierarchickú štruktúru adresára.

VYBERTE SI
Nomenclature.Code,
Nomenklatúra Názov AS Názov,
Nomenklatúra.Nákupná cena

FROM Directory.Nomenclature AS Nomenklatúra

KDE
(Nomenclature.ThisGroup = FALSE)

OBJEDNAŤ PODĽA mena

Získavanie súčtov podľa hierarchie

Ak chcete získať súčty podľa hierarchie v dotaze, musíte zadať kľúčové slovo HIERARCHY v klauzule SOFTWARE TOTAL po zadaní poľa, podľa ktorého sa budú vypočítavať súčty. Príklad zostavy „Obrat položiek“ so získaním súčtu podľa hierarchie:

VYBERTE SI

OD

Nomenklatúra HIERARCHIA

V dôsledku tejto požiadavky sa vypočítajú súčty nielen pre každú položku, ale aj pre skupiny, do ktorých táto alebo táto položka patrí.

V prípade, keď nie sú potrebné súčty pre prvky, ale súčty sú potrebné len pre skupiny, musíme v súčtoch použiť konštrukciu LEN HIERARCHIA. Príklad:

VYBERTE SI
Účtovanie nomenklatúryObrat. Nomenklatúra AS Nomenklatúra,
Účtovanie pre nomenklatúruObrat.Nomenklatúra.Prezentácia,
Účtovanie pre nomenklatúru Obrat. Množstvo Obrat AS Množstvo Obrat
OD
Akumulačný register.Číselník účtovníctvo.Obrat AKO Číselník ÚčtovníctvoObrat
VÝSLEDKY SUMA (Množstvo Obrat) PO
LEN nomenklatúra HIERARCHIA

Výsledkom tohto dotazu budú celkové záznamy len pre skupiny položiek.