Az 1C 8 hierarchia szerinti csoportba kerülés A kérésben szereplő „in hierarchy” operátor. Egy elem összes szülőjének megszerzése

12.12.2023Cím: Biztonság

Ildarovics 6489 16.11.12 18:24 Jelenleg témában

() Vlagyimir! Örülök, hogy odafigyelt a cikkre, különösen azért, mert Ön volt az egyik első, aki meglátta (és értékelte) ezt a technikát a két évvel ezelőtti „Reális trükkös lekérdezést írni” című vitában. Nem magamtól találtam ki érdekes kérdést, hanem láttam a fórumon. A kérdés szerzője Stanislav Sheptalov. Következő - 2012. 10. 24-én ugyanaz (csak most vettem észre, mert más a becenév) a fórum résztvevője hasonló kérdést tett fel, de a hierarchiára vonatkoztatva. Kiderült, hogy a GYAKORLATI probléma megoldódott. Továbbá a „tudományos” megközelítésnek megfelelően megvizsgáltam azokat a gyakorlati problémákat, ahol ez a technika alkalmazható. 7 további problémát találtunk. 5 - ebben a cikkben. Ezek közé tartozik a specifikációk ciklusaival kapcsolatos probléma, amelyet korábban megígértem, hogy egy lekérdezéssel megoldom az Ish_2-t. Azt hiszem, Ish_2 meg tudja majd győzni ennek a feladatnak a relevanciájáról – sok időt töltött vele. A megoldás rövid - néhány soros, ezért rendkívül áttekinthető, nem procedurális stílusban, az eredmény követelményén keresztül fogalmazva. Nos, a cikkekben és a fórumon más problémák is felmerültek, és ezekre bonyolultabb megoldásokat javasoltak. Várjunk tehát egy kicsit, hogy meglássuk, milyen gyakran fogják ezt alkalmazni. Pontosan ilyen visszajelzést várok – azoktól, akik megpróbálják.
Egyébként azt, hogy a matematikának ez az ága nem áll távol a gyakorlattól, és szükség van rá a könyvelőknek, bizonyítja a BP2-ben található „Költségkorrekció” általános modul, amelyen jelenleg bütykölünk (a standard kérés instabil működése). Ott az elemmozgási grafikon ciklusainak megszakításáról és egy feszítőfa felépítéséről beszélünk.
Most az adatbázis szerkezetéről „egy konkrét feladathoz”. A kérdést a feladat 1C-ben való megvalósításáról tették fel, így a feladatot az 1C-ben oldottuk meg. Ha megkérdeznék tőled, hogy „melyik busszal juthatsz el a könyvtárba”, és azt válaszolnád, hogy jobb léghajón repülni, akkor egyszerűen nem értenek meg (talán kivéve azokat, akik elakadtak egy moszkvai forgalmi dugóban ). Kezdetben a módszer teljesen más nyelven működött.
Általában véve nem fogom tudni meggyőzni, ha úgy gondolja, hogy az 1C platform architektúrája nem jó. Csak a véleményemet tudom elmondani. Az adatbázisséma nulláról való fejlesztése egy adott feladathoz drága. Ha összehasonlítjuk az építkezéssel: az 1C paneles sokemeletes épületek - olcsó lakások - tömeges automatizálás eszköze - szűkös körülmények között, de nem sértődve. Az egyes szervezetek felvehetik Norman Fostert, hogy pontosan teljesítse követelményeiket. A többieknek olcsó tömeggyártású projekteket kell használniuk – relációs DBMS-eket merev objektummodellel. Emellett ismerem a Cashe több projektben való használatának szomorú tapasztalatait is. Egy fejlesztő szemével minden nem tűnik olyan rózsásnak, mint elméletben. Az 1C objektummodell kiállja az idő próbáját – „hatalmas területek épülnek fel és laknak”. Ráadásul fejlődik. Az utóbbi időben megjelent a külső adatforrások technológiája. És ha egyes feladatok nagyobb reakciókészséget igényelnek (például számlázási rendszerek), akkor zökkenőmentesen csatlakoztathatja az 1C-t egy másik DBMS-hez. Például így cserélünk importált ERP-vel.
De ennek ellenére nem szeretném elterelni a beszélgetést a fő témáról - a javasolt technikák munkája részletes GYAKORLATI feladatokban.

Mi az 1C címtár és miért van rá szükség? A címtár feltételesen állandó információkat tárol, pl. hosszú időn keresztül szinte változatlan információ. Például a „Nómenklatúra” címtár az eladott vagy előállított áruk listáját tartalmazza. Ezenkívül egy könyvtár számos tulajdonságot tartalmazhat, amelyek leírnak egy könyvtárelemet.

Ha egy személy nemét vesszük összehasonlításul, akkor a lista korlátozott és nem változik, ezért a felsorolás alkalmasabb rá.

Miután létrehoztunk egy új könyvtárat, a következő képet fogjuk látni.

Nézzük meg az összes könyvjelzőjét.

Alapvető

Itt a név (az adatbázis azonosítója) és a szinonimája (a címtár felhasználói neve) látható. Az opcionális megjegyzés olyan megjegyzés, amely elmagyarázza a címtár célját vagy leírja annak jellemzőit.

Hierarchia

Ezen a lapon konfigurálhatja a címtárelemek egymásba ágyazásának mélységét. Ezzel a beállítással kényelmes az elemek megkülönböztetése és részletezése bizonyos kritériumok szerint. Például a „Szekrények” termékek az egyik csoportba, az „Asztalok” pedig egy másik csoportba tartoznak. Alapértelmezés szerint létrehozásakor a könyvtár megjelenik elemek listája. Ha bejelöli a Hierarchikus könyvtár jelölőnégyzetet, akkor minden elem alárendelhető egy másik elemnek (csoportnak). Az alábbiakban bemutatjuk a könyvjelző testreszabásának és a megjelenítés egyéni módban történő módosításának lehetőségeit.

Hierarchia típusa:

Csoportok és elemek hierarchiája

Ezzel a beállítással az elemek csak csoportokba (mappákba) ágyazhatók be.

Itt, amint látható, minden elemnek és csoportnak ugyanazok az ikonjai vannak, és bármelyik elem beágyazható.

Helyezzen csoportokat a tetejére

Ha ez a jelölőnégyzet be van jelölve, a csoportok mindig a tetején lesznek, ellenkező esetben rendezési sorrendbe kerülnek, például így:

A hierarchiaszintek számának korlátozása

Ha itt nincs bejelölve a jelölőnégyzet, akkor a beágyazás korlátlan.

Ha a jelölőnégyzet be van jelölve, az alábbiakban megadhatja a szintek számát.

Tulajdonosok

A könyvjelzőn tulajdonosok más címtárak is feltüntethetők, amelyekhez képest ez alárendelt. Az alárendelt könyvtárak kapcsolati diagramja hasonló egy hierarchikus címtár kapcsolati diagramjához, csak itt egy másik könyvtár működik szülőként, és tulajdonosnak nevezik. Tipikus konfigurációkban erre jó példa a "Szerződések" könyvtár alárendelése a "Counterparties" könyvtárnak, mert Nem létezhet olyan megállapodás, amely nem tartozik egyik partnerhez sem.

A "Könyvtártulajdonosok listája" mező megadja azon könyvtárak listáját, amelyek a könyvtár elemeit birtokolják.

Az alábbiakban az „Alárendeltség használata” mezőben látható, hogy ennek a címtárnak milyen elemei lesznek alárendelve.

Hogyan lehet programozottan kideríteni, hogy egy könyvtár hierarchikus-e vagy sem

Ehhez hivatkoznia kell a metaadatokra

Ez HierarchicalDirectory = Metadata.Directories.Counterparties.Hierarchical;

Folytatjuk...

Az 1C könyvtárak egy speciális metaadat-fa objektum, amely statikus hivatkozási információk tárolására szolgál. Például tipikus konfigurációkban a következő nézetek láthatók: , Nómenklatúra, Alkalmazottak, Tárgyi eszközök stb. A könyvtárakban lévő információk általában nem változnak gyakran. A könyvtárakat ezt követően szinte minden számviteli objektumban könyvelési részként vagy referencia információként használják.

Az alábbiakban egy könyvtár beállítását és tervezését tekintjük meg a konfigurátorból, példaként a „Nómenklatúra” könyvtár használatával.

Alap lap

Az „Alap” lap megadja a nevet, a szinonimát, az objektumábrázolást és a cél leírását.

„Könyvtárhierarchia” lapon

Itt jön létre a címtár hierarchiája.

Az 1C 8.3 hierarchiája kétféle - " csoportok és elemek"És" elemeket". Abban különbözik, hogy az első esetben csak egy mappa (csoport) lehet szülő (mappa), a második esetben pedig egy elem is lehet szülő.

„Csoportok elhelyezése a tetején” - a zászló felelős a csoportok lista formában történő megjelenítéséért.

Szintén a beállításokban korlátozhatja a csoportok számát a címtárhierarchiában a megfelelő beállítás segítségével.

Tulajdonosok lap

Egy címtár alárendelhető egy másik könyvtárnak. Az 1C 8.3 konfigurálása szempontjából ez azt jelenti, hogy a „Tulajdonos” attribútum kötelezővé válik az alárendelt elemnél. Példa egy ilyen kapcsolatra a címtárak között szabványos konfigurációkban: „Nómenklatúra - Mértékegységek”, „Szerződéses felek – Vállalkozói szerződések”.

A címtár tulajdonosa a következő metaadat-objektumok is lehetnek: , .

Adatok fül

Szerezzen ingyen 267 videóleckét 1C-n:

A legfontosabb lap programozói szempontból. Ez tartalmazza a címtár részleteit.

A könyvtár szabványos részleteket tartalmaz, amelyeket az 1C 8.2 programozó nem szerkeszt; ezek listája a „Standard Details” gombra kattintva tekinthető meg:

Mindegyiknél részletesebben kitérek:

Ez a csoport— egy logikai típusú attribútum, amely jelzi, hogy csoportról vagy elemről van-e szó. Csak a hierarchikus könyvtárban érhető el. Jegyzet, ennek az attribútumnak az értéke nem módosítható 1C: Enterprise módban.
Kód— kellékek, típusszám vagy karakterlánc (általában karakterlánc). A rendszer által automatikusan kiosztott szám. Általában a következőképpen számítják ki (előző kód + 1). A karakterlánc típusát javaslom, mert a numerikus értékek rendezése nem a várt módon működik. Listában és beviteli mezőkben címtárbemutatóként használható. Általában egy elem keresésére szolgál karakterlánc beírásakor. Ha el kell távolítania a Kód mezőt, írjon be nullát a sor hosszába.
Név— kötelező adatok, karakterlánc típusa. A sor maximális hossza 150 karakter. Listában és beviteli mezőkben címtárbemutatóként használható. Általában egy elem keresésére szolgál karakterlánc beírásakor. Ha el kell távolítania a Név mezőt, írjon be nullát a sor hosszába.
Szülő— a DirectoryLink típusú attribútum.<ИмяТекущегоСправочника>. Csak a hierarchikus könyvtárban érhető el. A hierarchiában a fölérendelt szülőre mutat. Ha az elem vagy csoport a könyvtár gyökerében található, akkor a Könyvtár érték kerül megadásra.<ИмяТекущегоСправочника>.EmptyLink.
Tulajdonos— hivatkozás az aktuális címtárelem (csoport) tulajdonos elemére. Elérhető csak az alárendelt 1C könyvtárban.
FlagDeletion— Boolean típusú kellékek. Felelős a „törlési jel” megjelenítéséért a rendszerben. A törlésre megjelölt elem használhatatlannak minősül, de régi dokumentummozgások maradhatnak rajta.
Link— karakterlánc típusú mező. Ez az attribútum egy egyedi objektumazonosítót - GUID - tárol. Amit a rendszerben a „link” nevű vizuális megjelenítésben látunk, az csak az objektum reprezentációja. Nem módosítható.
Előre meghatározott— logikai típus, megjeleníti, hogy az elem előre definiált-e, erről később. Nem módosítható.

Az „Adatok” fül a könyvtár rendszerbeli reprezentációját is jelzi, a 8.2.16-os verzió előtt az ábrázolás csak Kód vagy Név lehetett. A platform legújabb verzióiban (8.3-tól kezdődően) a nézet önállóan leírható a menedzser modulban a „ViewReceivingProcessing” kezelő segítségével.

Számozás fül

Itt adhatja meg a címtár számozással kapcsolatos beállításait. Az automatikus számozás használata javasolt. Az egyediség ellenőrzése egy zászló, amely szükség esetén segít egyedivé tenni a kódot. Ha a beállított jelzővel megpróbál egy könyvtárelemet nem egyedi kóddal írni, az 1C-ben a „A címtárkód nem egyedivé vált” üzenet jelenik meg.

Kódsorozat - meghatározza a telefonkönyv számozásának módját; megadhatja a számozást tulajdonos szerint. Például a „Szarvak és paták” szerződő félnek saját szerződésszámozása lesz - „1, 2, 3” stb.

Űrlapok lap

A címtár űrlapjai itt találhatók. Ha a konfigurációt normál és felügyelt módban is elindítja, akkor alapértelmezés szerint két lap lesz űrlappal: „fő” és „haladó” - a normál és a felügyelt alkalmazások esetében eltérő.

Ezen az oldalon található a könyvtár egyik fontos jellemzője - „“. Ez az 1C 8 nagyon kényelmes funkciója, amely lehetővé teszi, hogy az adatok kitöltésekor a beviteli mezőben ne lépjen be a könyvtárba, hanem írja be a nevét, kódját stb. és válassza ki a kívánt elemet a legördülő listából. Ez így néz ki:

Egyéb lap

A lapon gyorsan hozzáférhet a címtár fő moduljaihoz - az objektummodulhoz és a kezelőmodulhoz.

Az oldalon előre meghatározott könyvtárelemek listáját is megadhatja. Ezek olyan elemek, amelyeket Vállalati módban nem lehet törölni. Az előre definiált elemek név szerint közvetlenül elérhetők a konfigurátorban, például: Directories.Nomenclature.Service.

Ez a lap határozza meg a blokkolási módot is - automatikus vagy vezérelt. 1C: Enterprise módban elérhető teljes szöveges keresés, valamint a címtár referenciainformációinak használata.

Az 1C:Enterprise 8.x lekérdezések „HIERARCHYÁBAN” kialakítása lehetővé teszi egy hierarchikus konfigurációs objektum alárendelt elemeinek beszerzését egy adott kijelölésnek megfelelően. Ma a cikkben egy példát tekintünk meg a használatára, valamint a platform DBMS-oldali műveleteire és a teljesítményre gyakorolt hatására.

Használat

Nézzünk egy egyszerű példát a „HIERARCHIABAN” konstrukció használatára. A következő kérés végrehajtásakor a "Termékek" hierarchikus könyvtár alárendelt elemei lesznek beolvasva a "Link" változó átadott értékéhez.

A tesztadatbázisban a "Termékek" könyvtár a következő tesztadatokat tartalmazza:

Természetesen a kép nem mutatja az összes könyvtárbejegyzést. A képernyőképen csak az adattárolási struktúra látható a hierarchikus könyvtárban. A címtártábla 10 legfelső szintű csoportot tárol, amelyek mindegyike 5 beágyazott csoportot tartalmaz, egyenként 200 elemmel.

Térjünk vissza a tesztkéréshez. Adjuk át a "Csoport - 1" csoport hivatkozását a "&Link" paraméterhez (lásd a fenti képernyőképet). Ekkor a lekérdezés eredménye így fog kinézni:

Amint látjuk, a kérés magára a felső csoportra mutató hivatkozást adott vissza (paraméterként átadva), valamint beágyazott csoportokat a bennük lévő elemekkel. Így a „HIERARCHIABAN” konstrukció használata lehetővé teszi a hierarchikusan alárendelt adatok kényelmes megszerzését.

Az 1C:Enterprise lekérdezési nyelv szintaxisa klasszikus SQL bizonyos szempontból nagyon hasonló. Az „IN HIERARCHY” kifejezésnek azonban nincs analógja az SQL lekérdezési nyelvben, mivel például a „B” platform lekérdezési nyelvének kifejezésére van egy hasonló „IN” SQL operátor. Ezért érdekes a platform munkája a DBMS-sel az operátor használatakor.

A színfalak mögött

Tehát kezdjük. Például a „Termékek” könyvtárhoz a korábban megírt lekérdezést fogjuk használni. Két helyzetben elemezzük a platform műveleteit:

A „Group 1” legfelső szintű csoportot adjuk át „&Link” paraméternek (ahogyan korábban is tettük).
A paraméterben átadunk egy hivatkozást a "Group 1 - 1" csoporthoz, amely a "Group 1" legfelső szintű csoportba van beágyazva.

Most sorrendben. Az első esetben a platform a következő műveleteket hajtja végre az SQL szerveren:

1. Először egy SQL-lekérdezést hajtanak végre, hogy megkapják a paraméterként átadott címtárcsoportra és az összes alárendelt csoportra mutató hivatkozást. Az eredmény a „#tt1” ideiglenes táblába kerül.

2. A második szakaszban ugyanazt a lekérdezést kétszer hajtják végre:

A képernyőkép részletes megjegyzéseket tartalmaz az SQL lekérdezés szövegéhez. Röviden, a lekérdezés lehetővé teszi az alárendelt elemek kiválasztását azokhoz a csoportokhoz, amelyekre egy ideiglenes táblában hivatkozunk. A kérdés továbbra is fennáll: "Miért hajtják végre kétszer a lekérdezést?" A válasz itt egyszerű: először a lekérdezés alárendelt elemeket kap az első szintű csoportokhoz, amelyek már szerepelnek az ideiglenes táblában (lásd 1. pont). A második lekérdezés ezután lekéri a második szintű alcsoportok alelemeit. Mivel a hierarchia harmadik szintjén nincs jelen címtárcsoport, ez a lekérdezés többé nem kerül végrehajtásra.

Esetünkben a második lekérdezés üres eredményt ad vissza, mivel a hierarchia 3. szintjén található rekordokhoz nincsenek alárendelt elemek (ott nincsenek csoportok).

3. A lekérdezés végeredményének megszerzéséhez a platform a következő SQL lekérdezést generálja:

Ennek a konkrét kérésnek az eredménye a platform beépített nyelvén algoritmusokkal tovább feldolgozható. Így a „#tt1” ideiglenes tábla bejegyzései a „_Reference41” hivatkozási táblából származó mintavételi feltétel beállítására szolgálnak.

4. Az utolsó lépésben az 1C:Enterprise 8.x platform törli a „#tt1” ideiglenes táblát, mivel a jövőben nem fogja használni.

Ezzel befejeződik az „IN HIERARCHY” operátor végrehajtásának folyamata. Hadd emlékeztessem önöket arra, hogy az SQL-kiszolgálón végrehajtott műveletsor akkor történt, amikor a „Group - 1” legfelső szintű csoportra mutató hivatkozást átadtuk egy platformoldali kérésnek. De hogyan fog viselkedni a platform, ha „&Link” paraméterként egy hivatkozást adunk át a „Group - 1 - 1” második szintű csoporthoz? Minden ugyanúgy fog történni, kivéve a következő pontot: fent, az SQL lekérdezések platform általi végrehajtásának második szakaszában azt írták, hogy az alárendelt elemek megszerzésére irányuló lekérdezés kétszer futott le - az alárendelt elemek beszerzése esetén a "Group - 1 - 1" csoportnál ez nem így van. A kérés csak egyszer kerül végrehajtásra.

Az a tény, hogy az alárendelt elemek megszerzésére irányuló kérelmek száma a hierarchiában lévő csoportok számától függ. Más szóval, ha az elemhierarchia szintje legalább egy csoportot tartalmaz, akkor a kérés a 2. pontból.

Teljesítményhatás

Bármely operátor helytelen használata a lekérdezésben a rendszer optimális teljesítményének elmaradását eredményezheti. Ez alól a „HIERARCHIÁBAN” vizsgált operátor sem kivétel. Óvatosan kell használni, mert nagymértékben bonyolítja az adatbázis SQL-lekérdezések végrehajtásának algoritmusát, és ezáltal megnöveli a DBMS-kiszolgáló terhelését.

Hadd mondjak egy példát egy szuboptimális lekérdezésre, amely a fent említett szomorú következményekhez vezethet:

Termékek kiválasztása. Hivatkozás a címtárból. Termékek MINT Termékek WHERE (Termékek. Link A HIERARCHIABAN (& Link) VAGY Termékek. Link A HIERARCHIABAN (& Link1) VAGY Termékek. Link A HIERARCHIABAN (& Link2) )

Ahogy sejthető, a kérés sok SQL lekérdezés generálásához vezet, ami az információs rendszer teljesítményének csökkenését eredményezi.

Vond le a következtetéseket!

A következtetések levonása az Ön feladata. Csak annyit mondok, hogy a „HIERARCHIABAN” operátort használja a platform az adatösszeállítási rendszerhez, ha a kiválasztási feltételek között szerepel „CSOPORTBAN”, „CSOPORTBAN A LISTÁBÓL” és mások. Azt hiszem, nem kell magyarázni, hogy helytelen manipulációkkal a felhasználók nagyon összetett kijelöléseket állíthatnak be, és többszörösen növelhetik az 1C szerver és a DBMS terhelését. Csak tapasztalt felhasználóknak módosítsuk a beállításokat.

És természetesen saját mechanizmusok írásakor ügyeljen az „IN HIERARCHY” operátorra. Egyrészt nagyon kényelmes, másrészt veszélyes.

Ez a rész példákat mutat be a hierarchikus könyvtárakkal végzett munka során felmerülő tipikus problémák megoldására.

Egy hierarchikus címtár elemeinek beszerzése, amelyek egy adott csoportnak vannak alárendelve

A hierarchikus címtár alárendelt elemeinek megszerzéséhez a lekérdezési nyelv az IN HIERARCHY konstrukciót biztosítja. Példa a HIERARCHIABAN való használatra:

VÁLASZT
Nomenclature.Code,
Nómenklatúra.Vételár
TÓL TŐL

Ebben a példában a rendszer megkapja a &Csoport csoportban található Nomenclature könyvtár összes rekordját, beleértve magát, az alárendelt csoportokat és az alárendelt csoportokhoz tartozó elemeket.

Ha csak az adott csoportban közvetlenül elhelyezkedő elemekre, csoportokra vagyunk kíváncsiak, akkor a Szülő mezőben feltétel megadásával kaphatunk ilyen elemeket. Példa:

VÁLASZT
Nomenclature.Code,
Nómenklatúra. Név AS Név,
Nómenklatúra.Vételár
TÓL TŐL
Directory.Nomenclature AS Nómenklatúra

AHOL
Nomenclature.Parent = &Csoport

Ez a lekérdezés a &Csoport hivatkozással alárendelt csoportokat és elemeket választja ki.

Egy címtárelem alárendelt elemeinek meglétének ellenőrzése

Egy címtárelem alárendelt rekordjainak meglétének ellenőrzéséhez a bemutatotthoz hasonló lekérdezést használhat:

Ebben a példában a Szülő lekérdezési paraméterbe írjuk az elemre mutató hivatkozást, amelynél ellenőrizni kívánjuk, hogy vannak-e gyermekek. Egy ilyen lekérdezés végrehajtása után ellenőriznie kell az eredmény ürességét. Ha az eredmény nem üres, akkor vannak alárendelt rekordok. Ellenkező esetben - nem. Példa:

Ha Request.Execute().Empty() Akkor
Report("Nincs bejegyzés");
Másképp
Report("Elérhető rekordok");
endIf;

Egy elem összes szülőjének megszerzése

A lekérdezési nyelv nem biztosít speciális eszközöket egy elem összes szülőjének lekérésére. Használhat hierarchikus összegeket a feladat végrehajtásához, de a hierarchikus összegek lekérése nagyszámú rekord összegeinek összeállítására van optimalizálva, és nem teljesen hatékony egyetlen elem szülőinek megszerzéséhez. Egy elem összes szülőrekordjának hatékonyabb lekéréséhez ajánlatos kis részletekben végigpörgetni a szülőrekordokat. Példa:

CurrentItemItem = ItemItem;

Míg az Igazság Ciklus
Request.SetParameter("CurrentItemItem", CurrentItemItem);
Eredmény = Query.Run();
Ha Eredmény.Empty() Akkor
Elvetél;
endIf;
Selection = Eredmény.Select();
Selection.Next();
Ha Oszlopszám = 0 Eredmény szerint.Oszlopok.Mennyiség() - 1 ciklus
CurrentItemItem = Kijelölés[OszlopSzám];
Elvetél;
Másképp
Jelentés(AktuálisTétel);
endIf;
EndCycle;

Ha CurrentItemItem = Directories.Nomenclature.EmptyLink() Akkor
Elvetél;
endIf;
EndCycle;

Ebben a példában az ElementNomenclature változóban rögzített hivatkozás összes szülője megjelenik a szolgáltatási üzenet ablakában. A ciklusban 5 linkszülő kerül kiválasztásra.

Ha a címtárban a szintek száma korlátozott és kicsi, akkor minden szülőt egy kéréssel meg lehet szerezni ciklus nélkül.

Hierarchikus könyvtár megjelenítése a jelentésben

Ha hierarchikus könyvtárat szeretne megjeleníteni a jelentésben, miközben megőrzi a hierarchiát, a következőhöz hasonló lekérdezést kell használnia:

VÁLASZT
Nomenclature.Code,
Nómenklatúra. Név AS Név,
Nómenklatúra.Vételár
TÓL TŐL
Directory.Nomenclature AS Nómenklatúra
RENDEZÉS
Név HIERARCHIA

Ez a lekérdezés kiválasztja az összes rekordot a könyvtárból, és hierarchia szerint rendezi őket. Az eredmény név szerint lesz rendezve, figyelembe véve a hierarchiát.

Ahhoz, hogy a címtárcsoportok az elemek fölé kerüljenek, a kérésben az ORDER BY záradékot a következőre kell cserélni:

RENDEZÉS
Nómenklatúra. Ez a csoport HIERARCHIA,
Név

Az eredmény továbbra is hierarchikusan rendeződik, de a csoportok az elemek felett jelennek meg.

Lehetőség van a MEGRENDELÉS SZERINT ajánlatot az AUTOMATIKUS RENDELÉS opcióval helyettesíteni. Ebben az esetben az eredmény a címtár beállításainak megfelelően lesz rendezve, pl. ha a címtár azt írja ki, hogy a csoportokat az elemek felett kell elhelyezni, akkor azok felett lesznek.

Az eredmények felhasználásával a címtár hierarchikus struktúráját is megkaphatjuk.

VÁLASZT
Nomenclature.Code,
Nómenklatúra. Név AS Név,
Nómenklatúra.Vételár

FROM Directory.Nomenclature AS Nomenclature

AHOL
(Nómenklatúra.ThisGroup = HAMIS)

RENDELÉS Név szerint

Összesítések lekérése hierarchia szerint

Ha egy lekérdezésben hierarchia szerinti összegeket szeretne lekérni, meg kell adnia a HIERARCHY kulcsszót a SOFTWARE TOTAL záradékban, miután megadta azt a mezőt, amely alapján a végösszegeket kiszámítja. Példa a „Cikk forgalma” jelentésre, amely hierarchia szerinti végösszegeket kap:

VÁLASZT

TÓL TŐL

Nómenklatúra HIERARCHIA

Ennek a kérésnek az eredményeként nem csak az egyes tételekre, hanem azon csoportokra is összeszámolunk, amelyekhez ez vagy az a cikk tartozik.

Abban az esetben, ha nincs szükségünk összegekre az elemekhez, hanem csak a csoportokhoz, akkor a HIERARCHY ONLY konstrukciót kell használnunk az összegeknél. Példa:

VÁLASZT
A nómenklatúra elszámolása.Nomenclature AS Nómenklatúra,
Nómenklatúra elszámolásaForgalom.Nómenklatúra.Presentation,
NomenclatureTurnover elszámolása.QuantityTurnover AS QuantityTurnover
TÓL TŐL
Felhalmozási nyilvántartás.Nómenklatúra Számvitel.Forgalom HOGYAN Nómenklatúra KönyvelésForgalom
EREDMÉNYEK ÖSSZEG (Mennyiségforgalom) PO
Nómenklatúra HIERARCHIA CSAK

A lekérdezés eredménye csak a cikkcsoportok összes rekordja lesz.