Dávkové dotazy pro figuríny. Dávkové žádosti o figuríny Spuštění dávky požadavku 1 s 8

Tento článek je určen pro čtenáře, kteří znají jazyk SQL.

Dotazovací jazyk 1C, který se používá od verze 8, se dnes stal užitečným nástrojem pro práci s databázemi, který vám umožňuje číst z nich, ale ne psát. Syntakticky je dotazovací jazyk velmi podobný jazyku SQL, ale v ruštině.

Níže je tabulka korespondence mezi hlavními operátory dotazovacího jazyka a SQL:

A toto není úplný seznam. Podrobnější referenční informace o dostupných operátorech dotazovacích jazyků najdete v návrháři dotazů, o kterém pojednáme níže.

Spuštění 1C požadavku z programového kódu se provádí pomocí objektu vloženého jazyka „Request“. Příklad psaní databázového dotazu pomocí vloženého programovacího jazyka:

Metoda "Spustit" provede dotaz, metoda "Vybrat" vrátí hodnotu typu "FetchFromQueryResult". Alternativně můžete použít metodu Unload, která vrací tabulku hodnot.

Parametry dotazu jsou uloženy ve vlastnosti „Parametry“ (v tomto případě se jedná o strukturu, takže zde platí všechny metody struktury - vkládání, mazání atd.).

Příklad nastavení parametru „Query.Parameters.Insert“ („Reference“, ReferenceLink). Na parametry v požadavku se můžete podívat přes ampersand „& Reference“. Níže je uveden příklad požadavku pomocí parametrů:

Připomeňme, že dotazovací jazyk je určen pouze ke čtení dat z databáze, a proto mu chybí analogy pro příkazy SQL, jako jsou INS ERT a UPDATE. Data lze upravovat pouze prostřednictvím objektového modelu integrovaného programovacího jazyka 1C. Také v dotazovacím jazyce 1C existují operátoři, kteří nemají v SQL žádné analogy, například:

• V HIERARCHII
• Na místo
• INDEX PODLE

V HIERARCHII - umožňuje vybrat všechny prvky hierarchického adresáře, které jsou zahrnuty v hierarchii předaného odkazu. Příklad použití žádosti V HIERARCHII:

V tomto případě výsledek vrátí všechny podřízené prvky katalogu nomenklatury "Citrus", bez ohledu na to, kolik úrovní hierarchie tento katalog má.

Úkolem je například také najít produkt s názvem „Pen“. Položka musí být zahrnuta v hierarchii „Psací potřeby“. Zboží “, to znamená, že nemusíme hledat kliku. Struktura nomenklatury je v tomto případě následující:

Kancelář

Kování

Píšeme následující požadavek:

Při použití designu V HIERARCHII je třeba mít na paměti, že pokud předáte prázdný odkaz na parametr "Office", dotaz se zpomalí, protože platforma zkontroluje každý prvek na členství root.

Na místo - Toto prohlášení umístí výsledek do dočasné tabulky. Příklad požadavku:

Tento dotaz SQL bude proveden několika dotazy:

• Vytvoření dočasné tabulky (platforma je schopna „znovu použít“ dříve vytvořené dočasné tabulky, takže k vytvoření nedochází vždy);
• Vkládání dat do dočasné tabulky;
• Provádění hlavního dotazu, konkrétně SEL ECT z této dočasné tabulky;
• Zničení / vymazání dočasné tabulky.

Dočasný stůl lze explicitně zničit prostřednictvím konstrukce ZNIČIT, nebo implicitně - při zavírání dočasného správce tabulky.

Objekt "Dotaz" vloženého programovacího jazyka má vlastnost "TemporaryTablesManager", která je určena pro práci s dočasnými tabulkami. Ukázkový kód:

Po provedení dotazu lze MBT použít podruhé v jiném dotazu, což je nepochybně další výhoda použití dočasných tabulek. V takovém případě bude dočasná tabulka odstraněna z databáze, když se nazývá metoda „Zavřít“ ...

... nebo při mazání proměnné z paměti, tedy při provádění metody, ve které byla proměnná deklarována. Dočasné tabulky zvyšují zatížení diskového subsystému, takže byste neměli vytvářet příliš mnoho dočasných subsystémů (například ve smyčce) nebo velkých subsystémů.

INDEX PODLE - tento operátor se používá ve spojení s operátorem MÍSTO. Při vytváření dočasné tabulky může tento operátor indexovat vytvářenou tabulku, což výrazně zrychluje práci s ní (ale pouze v případě, že index odpovídá vašemu dotazu).

Bezplatná odborná konzultace

Děkujeme za váš požadavek!

Specialista 1C vás bude kontaktovat do 15 minut.

Vlastnosti některých operátorů dotazovacího jazyka

PRO ZMĚNU - tento operátor je určen k uzamčení konkrétní tabulky dotazu (nebo všech tabulek, které se dotazu účastní). Zamykání se provádí umístěním zámku U na stůl. V SQL je to implementováno pomocí nápovědy UPDLOCK. Tento design je nezbytný, aby se zabránilo zablokování. Příklad požadavku na konstrukci PRO ZMĚNU:

V tomto příkladu bude zámek U nastaven na tabulku Users. Pokud nezadáte tabulku, kterou chcete uzamknout, bude překryta na všech tabulkách účastnících se dotazu. Je důležité si uvědomit, že tento design funguje pouze v konfiguracích, ve kterých je povoleno automatické řízení blokování.

SLOUČENINA - požadavek podporuje připojení LEVÝ / PRAVÝ, PLNÝ, VNITŘNÍ,což odpovídá spojení v SQL - LEFT / RIGHT JOIN, OUTER JOIN, INNER JOIN.

Když však používáte Query Designer, nemůžete to udělat SPRÁVNÉ PŘIPOJENÍ.Konstruktor jednoduše zamění tabulky, ale operátor bude vždy ponechán. Z tohoto důvodu v 1C nikdy neuvidíte použití správného připojení.

Syntakticky vypadá připojení takto:

V dotazovacím jazyce 1C neexistuje žádný operátor pro připojení k kartézskému produktu (CROSS JOIN). Absence operátora však neznamená, že dotazovací jazyk takové připojení nepodporuje. V případě potřeby můžete tabulky připojit takto:

Jak vidíte na příkladu, klíč připojení je nastaven SKUTEČNÝto znamená, že každý řádek v jedné tabulce odpovídá řádku v jiné. Typ spojení (LEFT, RIGHT, FULL, INNER) není důležitý, pokud máte řádky v obou tabulkách, ale pokud v jedné z tabulek nejsou žádné řádky (pusťte tabulku), bude výsledek jiný. Například při použití VNITŘNÍ výsledek připojení bude prázdný. Použitím LEVÝ PRAVÝ výsledkem bude spojení nebo žádná data, podle toho, ke které tabulce se připojujeme - s daty nebo ne. Použitím ÚPLNÝ datová připojení budou vždy (samozřejmě pouze jedna tabulka, protože ve druhé je prázdnota), výběr typu připojení závisí na konkrétním problému aplikace.

Malá vizuální stopa, jak fungují různé typy připojení:

JAKO.Na rozdíl od podobného operátoru SQL LIKE, šablona pro JAKO lze nastavit pouze pomocí některých speciálních znaků:

• % (procenta): sekvence obsahující libovolný počet libovolných znaků;
• _ (podtržítko): jeden libovolný znak;
• / - Následující znak musí být interpretován jako běžný znak.

VÝSLEDKY ZAPNUTYekvivalent v SQL je operátor ROLLUP. Příklad použití operátoru VÝSLEDEK:

Výsledek bude vypadat takto:

To znamená, že do výsledku je přidán další řádek obsahující hodnotu pole, podle kterého je seskupení provedeno, a hodnotu agregační funkce.

Práce s dávkovými požadavky

1C vám umožňuje pracovat s balíčky požadavků. V dávkovém požadavku jsou texty dotazů odděleny středníkem (;). Dávkový požadavek 1C se provádí postupně. Ukázkový text žádosti o dávku:

Chcete-li získat výsledek všech požadavků obsažených v balíčku, musíte místo metody Execute použít metodu ExecuteBatch objektu požadavku. Tato metoda provádí všechny požadavky postupně. Výsledkem dotazu je pole výsledků pro každý dotaz z balíčku a posloupnost v poli je stejná jako posloupnost požadavků v textu balíčku.

Vzhledem k dotazovacímu jazyku stojí za zmínku například virtuální tabulky. V databázi nejsou žádné virtuální tabulky, jedná se o druh obálky, která se provádí na straně DBMS jako dotaz pomocí poddotazů. Příklad 1C dotazu využívajícího virtuální tabulky:

Takový dotaz na DBMS bude vypadat takto:

Je vidět, že to nevypadá jako SQL, protože existuje poddotaz, seskupení. Virtuální tabulky jsou obecně „syntaktický cukr“, to znamená, že jsou vytvářeny obecně pro pohodlí při vývoji dotazů, takže dotazy jsou kompaktnější a čitelnější.

Pouze registry mají virtuální tabulky, ale které virtuální tabulky jsou k dispozici z registru, lze zobrazit v návrháři dotazů.

Při použití virtuálních tabulek musíte vždy zadat podmínku výběru. Jinak mohou nastat problémy s výkonem.

V těle žádosti to vypadá takto:

Pro usnadnění psaní dotazů, tj. Vytváření textů dotazů, je v 1C konstruktor, který lze vyvolat prostřednictvím kontextové nabídky (kliknutí pravým tlačítkem):

V návrháři dotazů můžete zobrazit kompletní seznam podporovaných funkcí a operátorů dotazovacího jazyka.

Tvůrce dotazů je velmi flexibilní vizuální nástroj pro vytváření dotazů jakékoli složitosti. Je k dispozici pouze v režimu konfigurátoru. V režimu Enterprise existuje takzvaná „Query Console“ - jedná se o externí zpracování dodávané na disku ITS. U spravované aplikace lze konzolu dotazu stáhnout ze stránky its.1c.ru.

Popis práce v konstruktoru dotazu je nad rámec tohoto článku, proto nebude podrobně zvažován.

Důvody pro neoptimální výkon dotazu

Níže je uveden seznam hlavních důvodů (ale ne všech), které vedou k pomalejšímu provádění dotazu.

• Použití spojení s poddotazy

Nedoporučuje se spojovat s poddotazy; poddotazy by měly být nahrazeny dočasnými tabulkami. Připojení poddotazů může vést k významné ztrátě výkonu, zatímco provedení dotazu na různých DBMS se může výrazně lišit v rychlosti. Rychlost provádění takových dotazů je také citlivá na statistiky v DBMS. Důvodem tohoto chování je, že optimalizátor DBMS nemůže vždy správně určit plán optimálního provedení dotazu, protože optimalizátor neví nic o tom, kolik řádků vrací poddotaz po jeho provedení.

• Používání virtuálních tabulek ve spojení dotazů

Virtuální tabulky na úrovni DBMS jsou spouštěny jako poddotazy, takže důvody jsou stejné jako v prvním odstavci.

• Použití podmínek v dotazu, které neodpovídají existujícím indexům

Pokud v podmínkách dotazu (v operátoru KDE nebo v podmínkách virtuální tabulky) jsou použita pole, která nejsou všechna zahrnuta v indexu, tento dotaz bude proveden pomocí skenování tabulky konstruktu SQL nebo indexového skenování (zcela nebo zčásti). To ovlivní nejen čas provedení dotazu, ale také nadměrné S zámky budou uloženy na další řádky, což může vést k eskalaci zámků, to znamená, že bude uzamčena celá tabulka.

• Použití NEBO v dotazovacích podmínkách

Použití logického operátoru NEBO ve výstavbě KDE může také vést ke skenování tabulky. To je způsobeno skutečností, že DBMS nemůže index používat správně. Namísto NEBOmůžete použít konstrukci KOMBINUJTE VŠE.

• Získání dat tečkou pro pole komplexního typu

Nedoporučuje se získávat hodnoty bodem (v konstrukci VYBERTE KDE), protože pokud se atribut objektu ukáže jako složený typ, dojde ke spojení s každou tabulkou v tomto složeném typu. Výsledkem bude, že dotaz na DBMS bude výrazně komplikovaný; to může zabránit optimalizátoru ve výběru správného plánu provedení dotazu.

Dávkové dotazy logicky doplňují funkčnost dočasných tabulek a poskytují více možností při práci s dotazy.

V dávkovém dotazu můžete ve skutečnosti popsat několik dotazů, které spolu navzájem souvisejí pomocí dočasných tabulek a nesouvisí (je to možné, ale není jasné proč?). Ve výsledku můžete všechny žádosti spustit postupně a jako výsledek přijmout buď pole s výsledky každého požadavku, nebo výsledek posledního. Chcete-li získat pole s výsledky dotazu, použijte metodu RunPackage () požadavek na objekt a získat výsledek posledního požadavku ExecuteRequest ().

V textu požadavku jsou požadavky na balíček odděleny znakem „;“ (středník). Jeden dávkový dotaz má jeden jmenný prostor virtuální tabulky. Použití dočasného správce tabulek není nutné, ale je možné, pokud chcete přenést dočasné tabulky z jednoho dávkového dotazu do jiného.
Postup zpracování odeslání kódu 1C v 8.x (odmítnutí, režim odesílání)

Žádost \u003d Nový požadavek;
Request.Text \u003d "
| VYBERTE si
| Nomenklatura, SUM (množství) JAKO množství
| POST LEKÁŘ
| OD
| KDE
| Odkaz \u003d & Odkaz
| Nomenklatura LOAD BY
|;
| VYBERTE RŮZNÉ
| Nomenklatura
| Seznam položek POST
| OD
| Document.Income.Produkty
| KDE
| Odkaz \u003d & Odkaz
|;
| VYBERTE si
| Doc. Nomenklatura,
| Doc.Quantity AS Doc_Quantity,
| JE NULL (zbývající částka reg., 0) JAKO reg_Nčíslo
| OD
| DOCTCH AS Doc
| VLEVO KLOUB
| Akumulační registr. Dobré zůstatky. Zůstává (,
| Nomenklatura B (VYBRAT RŮZNÉ
| Nomenklatura
| Z
| Seznam položek AS Seznam položek)) AS Reg
| PODLE
| Doc.Nomenclature \u003d Reg.Nomenclature ";

While Fetch.Next () Loop
// Zkontrolujte negativní zbytky
// Přejeďte přes registr
Konec cyklu;
Konec postupu

Ve skutečnosti jsem odstranil definici objektu dotazu a použití dočasného správce tabulek, kombinoval texty dotazů (všimněte si oddělovače ";" mezi texty). Výsledkem je, že text dotazu se stal čitelnějším (a čitelnost dotazu se při použití návrháře dotazů výrazně zlepšila).

Po provedení požadavku na proměnnou Pole výsledků budeme mít 3 prvky. První dva budou obsahovat číslo charakterizující počet záznamů umístěných v dočasných tabulkách DOCT a Seznam položek a třetí bude obsahovat výběr s poli Nomenklatura, Doc_Number a Reg_Number.

Do proměnné Výsledek požadavku zahrnut bude pouze vzorek.

To je vše pro hromadné žádosti. Velmi pohodlný mechanismus jak z hlediska psaní dotazů, tak z hlediska čtení složitých dotazů.

Informace převzaty z webu

Článek popisuje mechanismus dávkových požadavků implementovaných v platformě 1C: Enterprise. Po přečtení článku se dozvíte:

• Co jsou požadavky na dávku a k čemu slouží?
• Jak vytvořím balíček dotazů pomocí nástroje Query Builder?
• Jak vrátím pole výsledků pro každý dotaz z dávky?

Použitelnost

Materiál je relevantní pro aktuální verze platformy 1C: Enterprise, verze 8.3

Účel dávky požadavku

Platforma umožňuje pracovat s dávkovými požadavky. Dostáváme příležitost provést několik požadavků „najednou“. V dávkovém požadavku jsou texty požadavku odděleny znakem „;“ (středník).

Dotazy jsou spouštěny postupně, zatímco dočasné tabulky, které byly vytvořeny během provádění dotazu, budou existovat až do konce provádění celé dávky dotazu nebo do provedení dotazu v dávce, která zničí tuto dočasnou tabulku. Důležitým rozdílem od poddotazu je, že výsledky každého požadavku na dávku jsou k dispozici samostatně.

Balíčky dotazů umožňují dosáhnout provedení postupného dotazu. K tomu jsou v dávkovém dotazu nejprve vytvořeny dočasné tabulky, poté jejich společné použití (spojení, sjednocení, filtry) k získání konečného výsledku dotazu. Je také důležité si uvědomit, že použití dočasných tabulek v dávkových dotazech zlepšuje čitelnost textu dotazu.

Hromadné dotazy s vnořenými dotazy zabalenými do sebe je často docela těžké pochopit. Pokud ale takový dotaz přepíšete pomocí dočasných tabulek, viditelnost dotazu lze výrazně zlepšit. Použití dávky dotazů s dočasnými tabulkami může také zlepšit výkon dotazu.

Existují techniky pro optimalizaci výkonu dotazu na základě nahrazení vnořených dotazů dočasnými tabulkami.

Dočasná tabulka může být užitečná, když potřebujete použít stejná data vícekrát ve velkém dotazu, jako je například spojení nebo spojení s jinými tabulkami. Při použití vnořených dotazů by taková data musela být načtena několikrát pomocí stejných vnořených dotazů, což by samozřejmě ovlivnilo čitelnost textu i výkon.

Vytvořte balíček dotazů pomocí návrháře

Jednotlivé žádosti obsažené v balíčku jsou v textu odděleny znakem „;“ (středník). Abyste se vyhnuli ručnímu rozdělení textu dotazu, můžete k tomu použít Návrháře dotazů.
Tvůrce dotazů má samostatnou kartu pro balíčky dotazů. Požadavky lze do balíčku přidat pomocí příslušného tlačítka na panelu příkazů a také je přesunout nahoru nebo dolů.

Vizuální zobrazení jednotlivých dotazů - záložky na pravé straně návrháře, pomocí kterých můžete přejít k úpravám textu jednotlivých dotazů. Na těchto kartách se zobrazují názvy dočasných tabulek, požadavků na výběr dat - „Žádost o dávku 2“ atd., Zničení - „- NameBT“.

V seznamu databázových tabulek se také zobrazí dočasné tabulky vytvořené v tomto balíčku. To však neznamená, že dočasné tabulky jsou uloženy v databázi spolu se všemi ostatními tabulkami infobase.

Vytváření žádostí o balíček

Pokud objekt Žádostpři provádění dávkového dotazu je nainstalován dočasný správce tabulek, dočasné tabulky, které nebyly zničeny v dávkovém dotazu, budou uloženy v nainstalovaném správci.

V textu dávkového požadavku je možné použít a zničit dočasné tabulky, které existovaly v nainstalovaném dočasném správci tabulek v době, kdy byl balíček spuštěn k provedení.

Kromě metody Provést ()že postupně provádí všechny požadavky balíčku a vrací výsledek posledního požadavku v balíčku, je v platformě další metoda - RunPackage ().

Tato metoda provádí všechny požadavky postupně a vrací pole výsledků pro každý požadavek v balíčku v pořadí, v jakém se požadavky zobrazují v těle balíčku.

Výsledkem provedení dotazu na zničení dočasné tabulky je hodnota Nedefinovánokterý je také umístěn v poli výsledků.

Když se můj dotaz stal tak složitým, že to bylo mimo moje chápání, rozhodl jsem se použít dávkové dotazy.

Ale stál jsem před tím, že o nich nic nevím. Ukázalo se, že vše je velmi jednoduché. Za 5 minut budete moci použít dávkové požadavky. Začněte číst.

Jak se ukázalo, vše je velmi jednoduché. Musíte pouze napsat několik dotazů oddělených středníky. Výsledek bude vrácen v posledním požadavku.

Dávkové požadavky se objevily pouze ve verzi 8.1.11.67.4.

Zde je text požadavku:

VYBERTE T1.Zn POSIT VTLETTERY OD (VYBERTE "A" AS KN KOMBINUJTE VŠE VYBERTE "B") JAKO T1;

VYBERTE T1.Zn PLACE WTDigits FROM (VYBERTE "1" AS KN KOMBINOVAT VŠE VYBERTE "2") AS T1;

VYBERTE TB.Zn, TC.Zn, TB.Zn + TC.Zn Z VT písmen AS TB, VT čísla AS TC

Dávkové dotazy jsou podporovány v jakékoli běžné konzole dotazů.

Obrázek ukazuje ukázkové provedení dotazu:

A teď trochu ze zkušenosti. Proč potřebujeme hromadné žádosti.

Faktem je, že k dočasné tabulce můžete připojit nějaký přechodný výsledek, který pak může být potřeba v několika následujících dotazech.

Dříve, když neexistovaly žádné dočasné tabulky, budete muset duplikovat text dotazu.

Samozřejmě můžete upustit od dávkového dotazu postupným prováděním více dotazů a manipulací s vnořenými tabulkami. Dávkové požadavky jsou ale pohodlnější. Stačí napsat dotaz a nepřemýšlíte o umístění dočasných tabulek. Všechno se děje samo.

Kromě toho, pokud se použije systém pro složení dat (ACS), inteligentně vybere požadovaná pole a minimalizuje celou dávku požadavků.

Pokud by žádosti měly metodu Request.Run () pak teď existuje metoda Request.RunPackage (), který vrací všechny tabulky z balíčku jako pole.

Oznámení o dávkových požadavcích na webu 1c je zde: http://v8.1c.ru/overview/release_8_1_11/#Funkční

Životní příběh

Dovolte mi vysvětlit, co mě přimělo k dávkovým požadavkům.

Představte si tedy, že existuje dokument, který má tabulkovou část. Ve sloupci " Chyba»Podepište, zda při vyplňování dokumentu nedošlo k chybě. Ve sloupci " TextErrors»Může existovat jedna nebo několik vět s chybovými texty. Typy chyb obsažené v návrzích jsou známy předem.

Takže zadáme seznam všech chyb v tabulce. Chybové kódy - obsahuje kód chyby a podřetězec vyhledávání.

Dostaneme jednu, dvě nebo více chyb pro každý řádek. Protože na jednom řádku může být více chyb.

Chyba však nemusí být rozpoznána, tj. vlajka " Chyba"Stojí a text chyby nám nedal chybový kód.

Uděláme levé spojení, kde je chybový kód NULL, dáme chybový kód " Další chyby» .

Ale problém byl v tom, že tam bylo asi 200 chybových kódů, takže levé spojení fungovalo velmi dlouho. Musel jsem to nahradit vnitřním spojením, které létalo. Zároveň však byly ztraceny řádky, pro které nebyla chyba nalezena. Nikdy jsem nebyl schopen přijít na to, jak tyto čáry vytáhnout do výsledku.

Byl napsán požadavek na systém rozložení, tj. v zásadě nelze použít žádné tabulky hodnot ani dočasné tabulky. To je místo, kde přišly dávkové požadavky.

Znovu jsem zřetězil všechny řádky s chybami se všemi řádky, pro které byly nalezeny chyby, a přesto jsem přidal typ chyby „Další chyby“.

Pojďme analyzovat, jak se syntaxe textů dotazů změnila (spíše doplnila) na jednoduchém příkladu: Spotřební obsahující v tabulkové části produkty seznam prodaných produktů a množství. Při provádění takového dokumentu je nutné zajistit kontrolu záporných zůstatků uložených v registru akumulace zůstatků Zůstatky zboží.

Konfigurační struktura je znázorněna na obrázku.

(16,22 kilobajtů) Staženo: 64

Vytvořme dotaz pro tabulkovou část dokumentu a virtuální tabulku Zbytky akumulační registr. Vezměme v úvahu možné duplicitní řádky v dokumentu, k tomu seskupíme záznamy.

Žádost \u003d Nový požadavek;
Request.Text \u003d "
| VYBERTE si
| Doc. Nomenklatura,
| AMOUNT (Doc.Quantity) AS Doc_Number,
| MINIMÁLNĚ (JE NULL (reg. Množství, 0)) AS reg_Nčíslo
| OD
| Document.Consumable.Goods AS Doc
| VLEVO KLOUB
| Akumulační registr. Dobré zůstatky. Zůstává () AS Reg
| PODLE
| Doc.Nomenclature \u003d Reg.Nomenclature
| KDE
| Odkaz \u003d & Odkaz
| LOAD BY Doc.Nomenclature ";

// Přejeďte přes registr

Konec cyklu;

Konec postupu

Přirozeně, daný dotaz není absolutně optimální. Pomocí vnořených dotazů to optimalizujeme: Pojďme seskupit tabulkovou část dokumentu před připojením k tabulce zbytků, předat seznam zboží do parametrů virtuální tabulky jako hodnotu podmínky pro výpočet zbytků. V důsledku toho bude mít náš požadavek následující podobu:

| VYBERTE si
| Doc. Nomenklatura,

| OD
| (VYBRAT

| Z
| Document.Income.Produkty
| KDE
| Odkaz \u003d & Odkaz
| Nomenklatura LOAD BY) AS Doc
| VLEVO KLOUB
Názvosloví B
| (VYBERTE SI RŮZNÉ
| Nomenklatura
| Z
| Document.Income.Produkty
| KDE
| Link \u003d & Link)) AS Reg
| PODLE

Pokud bylo v dotazu nutné získat data ze zbytků různých registrů, pak by se hodnota filtru, a tedy i náš druhý poddotaz, opakovala ve všech parametrech virtuálních tabulek, je přirozené, že se systém znovu obrátí na databázi k získejte data s každým poddotazem.

Dočasné stoly

Nepamatuji si, od kterého vydání bylo možné v dotazech používat dočasné tabulky. K tomu se používá objekt „Temporary Table Manager“. Správce dočasných tabulek ve skutečnosti popisuje jmenný prostor dočasných tabulek a odpovídá za jejich vytváření a zničení v databázi.

Samotné dočasné tabulky jsou skutečně fyzicky vytvořeny v databázi, takže byste s nimi měli zacházet opatrně, protože diskový subsystém je v současné době nejpomalejší součástí této technologie a rychlost vytváření a ničení tabulek na ní přímo závisí.

Přepíšeme dotaz tak, aby používal dočasné tabulky. Umístěte seskupenou tabulkovou část dokumentu a seznam produktů pro filtr virtuální tabulky do dočasných tabulek:

Postup zpracování účtování (odmítnutí, režim účtování)

MVT \u003d New TemporaryTable Manager;

Žádost \u003d Nový požadavek;
Request.Text \u003d "
| VYBERTE si
| Nomenklatura, SUM (množství) JAKO množství
| POŠTOVNÍ LÉKAŘ
| OD
| Document.Incoming.Goods
| KDE
| Odkaz \u003d & Odkaz
| Nomenklatura LOAD BY ";

Žádost \u003d Nový požadavek;
Query.TemporaryTablesManager \u003d MVT;
Request.Text \u003d "VYBRAT RŮZNÉ
| Nomenklatura
| Seznam položek POST
| OD
| Document.Incoming.Goods
| KDE
| Odkaz \u003d & Odkaz ";

Žádost \u003d Nový požadavek;
Query.TemporaryTablesManager \u003d MVT;
Request.Text \u003d "
| VYBERTE si
| Doc. Nomenklatura,
| Doc.Quantity AS Doc_Quantity,
| JE NULL (zbývající částka reg., 0) JAKO reg_Nčíslo
| OD
| DOCTCH AS Doc
| VLEVO KLOUB
| Akumulační registr. Dobré zůstatky. Zůstává (,
| Nomenklatura
| Z
| PODLE
| Doc.Nomenclature \u003d Reg.Nomenclature ";

QueryResult \u003d Query.Run ();
Výběr \u003d QueryResult.Select ();

While Sampling.Next () Loop

// Zkontrolujte negativní zbytky

// Přejeďte přes registr

Konec cyklu;

Konec postupu

Při použití dočasných tabulek v textu dotazu použijte instrukci Místo k vytvoření nové dočasné tabulky, v tomto případě systém nepřenáší obsah této tabulky do výsledku dotazu (viz poznámka 1 a příklad 2 v textu výše), ale počet záznamů umístěných v dočasné tabulce, pokud přání, nemůžete tuto hodnotu přijmout.

Je také povoleno použít instrukci Zničit v tomto případě je dočasná tabulka zničena, jinak jsou dočasné tabulky zničeny spolu s dočasným objektem správce tabulky.

V našem hlavním dotazu jsem použil názvy dočasných tabulek jako označení zdroje dat (musí jim být přiřazeno synonymum, které vidíme v textu). Dočasné tabulky můžete použít jako zdroj více než jednou, což vám při šikovném použití umožní zkrátit text dotazu (zlepšit čitelnost složitých dotazů) a zvýšit rychlost (při použití dočasných dat tabulky na několika místech v dotazu).

Dávkové žádosti

Dávkové dotazy logicky doplňují funkčnost dočasných tabulek a poskytují více možností při práci s dotazy.

V dávkovém dotazu můžete ve skutečnosti popsat několik dotazů, které spolu navzájem souvisejí pomocí dočasných tabulek a nesouvisí (je to možné, ale není jasné proč?). Ve výsledku můžete všechny žádosti spouštět postupně a ve výsledku přijímat buď pole s výsledky každého provedení požadavku, nebo výsledek posledního. Chcete-li získat pole s výsledky dotazu, použijte metodu RunPackage () požadavek na objekt a získat výsledek posledního požadavku ExecuteRequest ().

V textu požadavku jsou požadavky na balíček odděleny znakem „;“ (středník). Jeden dávkový dotaz má jeden jmenný prostor virtuální tabulky. Použití dočasného správce tabulek není nutné, ale je možné, pokud chcete přenést dočasné tabulky z jednoho dávkového dotazu do jiného.

Přepíšeme postup pro použití dávkových požadavků:

Postup zpracování účtování (odmítnutí, režim účtování)

Žádost \u003d Nový požadavek;
Request.Text \u003d "
| VYBERTE si
| Nomenklatura, SUM (množství) JAKO množství
| POST LEKÁŘ
| OD
| Document.Income.Produkty
| KDE
| Odkaz \u003d & Odkaz
| Nomenklatura LOAD BY
|;
| VYBERTE RŮZNÉ
| Nomenklatura
| Seznam položek POST
| OD
| Document.Income.Produkty
| KDE
| Odkaz \u003d & Odkaz
|;
| VYBERTE si
| Doc. Nomenklatura,
| Doc.Quantity AS Doc_Quantity,
| JE NULL (zbývající částka reg., 0) JAKO číslo_reg
| OD
| DOCTCH AS Doc
| VLEVO KLOUB
| Akumulační registr. Dobré zůstatky. Zůstává (,
| Nomenklatura B (VYBRAT RŮZNÉ
| Nomenklatura
| Z
| Seznam položek AS Seznam položek)) AS Reg
| PODLE
| Doc.Nomenclature \u003d Reg.Nomenclature ";

While Sampling.Next () Loop

// Zkontrolujte negativní zbytky

// Přejeďte přes registr

Konec cyklu;

Konec postupu

Ve skutečnosti jsem odstranil definici objektu dotazu a použití dočasného správce tabulek, kombinoval texty dotazů (všimněte si oddělovače ";" mezi texty). Výsledkem je, že text dotazu se stal čitelnějším (a čitelnost dotazu se při použití návrháře dotazů výrazně zlepšila).

Po provedení požadavku na proměnnou Pole výsledků budeme mít 3 prvky. První dva budou obsahovat číslo charakterizující počet záznamů umístěných v dočasných tabulkách DOCT a Seznam položeka třetí bude obsahovat výběr s poli Nomenklatura, Doc_ číslo a Reg_ číslo.

Do proměnné Výsledek požadavku zahrnut bude pouze vzorek.

To je vše pro hromadné žádosti. Velmi pohodlný mechanismus jak z hlediska psaní dotazů, tak z hlediska čtení složitých dotazů.