Zaslal/a
21.2.2015 2:24pro úplné pochopení mého dotazu je asi dobré držet se určitého scénáře.
Scénář předpokládá, že chcete do listu excelu tahat data z databázového serveru se kterými se dále libovolně pracuje.
Vyhněme se také možnosti, že máme k dispozici robustní řešení datových skladů potažmo BI nebo programátorské znalosti moderních objektových jazyků a frameworků.
V takových případech byste asi raději využili výhod reportovacích nástrojů plnohodnotných databázových serverů nebo knihoven jako např ADO.NET potažmo ORM.
V našem modelu jsme nuceni využít nativních nástrojů excelu, případně VBA. Lze však využít skutečnosti, že kromě selectů můžete vytvořit nebo požádat o vytvoření databázových objektů jako uložené procedury nebo pohledy.
Otázka je už vlastně prostá. Jaké nástroje byste preferovali Vy v rámci uvedeného scénáře? Pokud možno uveďte vaše poznatky, třeba i výhody a nevýhody.
Používáte MS Query, plníte QueryTable nebo používáte ADO a mnohovrstvé ovladače ODBC? Nebo něco jiného? Proč?
S těmi, kteří to vydrželi číst až sem se můžu podělit o vlastní dosavadní zkušenosti.
V době, kdy jsem se na této problematice zamýšlel, kladl jsem si určité (základní a obecné) požadavky, které mohou být součástí našeho scénáře.
1) Dostatečná rychlost bez zbytečné zátěže serveru - zejména držet připojení pouze po nezbytnou dobu.
2) Možnost parametrizace.
3) Flexibilita pří rozložení na listu.
4) Komplexnost, která umožní vytvářet i robustnější řešení.
5) Dostatečná obecnost a znovupoužití.
Vyzkoušel jsem některé zmiňované nativní nástroje s různými výsledky. Nakonec jsem se rozhodl pustit se do VBA a zastaralého ADO (nyní již VBA/VB6 snippet) a pokusit se ušít si vše na míru podle vlastního gusta. Protože jsem nechtěl uživatele řešení zatížit nutností znalosti jazyka SQL, vybral jsem si pro získání dat uložené procedury nebo-li Stored procedures (dále SP).
Ty mají několik zásadních výhod. Pokud si je neumíte vytvořit sami, je ještě možnost požádat o vytvoření zkušeného vývojáře, který umí napsat optimalizovaný dotaz zapouzdřený v SP. Vytvořenou SP pak můžete bezpečně volat z excelu a předávat jí dynamicky parametry. SP je předkompilovaná tzn., že databázovému serveru odpadá zbytečná režie. Trocha ušetřeného výkonu se hodí zejména v případě, kdy jste nuceni využít pomalé mnohovrstvé ODBC. Dalším benefitem je, že veškerá zátěž je ponechána databázovému serveru. SP mají ještě jednu zajímavou vlastnost. Jde o možnost vracet více než jednu sadu záznamů.
Vygenerované sady záznamů lze pak zachytávat pomocí metody NextRecordset objektu Recordset. Lehce tak vytvoříte např. několik tabulek s agregovanými daty pouze pomocí volání jedné SP. Bohužel při práci s ADO je znát, že je to značně zastaralá technologie. Naopak příjemným překvapením byla metoda CopyFromRecordset kolekce Cells ve VBA, která je poměrně svižná. Největším žroutem volného času se nakonec stala implementace velkého množství flexibility. Nakonec jsem bohužel vygeneroval takové množství kódu, že jsem si musel vytvořit "objektovou vrstvu" umístěním kódu do modulu třídy. Nutno dodat, že nemůže být řeč o objektovém programování. V tomto případě se jedná spíše o jednoduché nahrazení funkcí a sub procedur, ale s tím, že se kód lépe udržuje a získáte omezené zapouzdření.
Snad se mi povede přiložit soubor s ukázkou kódu. Sešit obsahuje tři moduly. mdl_Globals pro veřejné konstanty, mdl_Main, kde je ukázka použití modulu třídy, který pracuje s uloženými procedurami pomocí ADO. Soubor jsem vytvořil v MS Excel 2013.
Oblíbený formulář Faktura byl vylepšen a rozšířen.
Více se dočtete zde.
Používáte podnikový systém Helios iNuvio? Potřebujete pomoci se správou nebo vyvinout SQL proceduru? Více informací naleznete na stránce Helios iNuvio.