sql >> Databáze >  >> RDS >> Access

Jak Access komunikuje se zdroji dat ODBC? Část 1

Toto je šestidílná série článků o trasování ODBC, která vývojářům Accessu pomůže odstraňovat problémy a pracovat s Accessem při vývoji aplikace, která používá zdroje dat ODBC, obvykle, ale ne výhradně SQL Server. Série si klade za cíl demonstrovat, jak používat trasování ODBC ke sledování příkazů SQL ODBC, které Access vydává na pozadí při práci s objekty, jako jsou dotazy, formuláře nebo sestavy, nebo dokonce při provádění kódu VBA proti objektům DAO. Série také ukáže, jak Access formuluje příkazy SQL ODBC. Nakonec se seriál bude zabývat tím, jak interpretovat sledování a identifikovat potenciální problémy. Články budou tištěny denně až do konce série.

AKTUALIZACE: Přidán klíč registru pro 32bitovou instalaci C2R v 64bitovém systému Windows. Díky, Jacku MacDonalde!

Kolikrát jste slyšeli:„Nevím proč, ale kývat klikou prostě funguje“? Kdykoli dostanu takovou odpověď, rozčiluje mě to, protože je to tak neuspokojivé. Velmi by mě znepokojovalo, kdyby mi můj instalatér řekl, že neví, pro co je past na p-past, a nadále o ní mluvil jako o „ten křivolaké věci pod dřezem“. Stejně tak by moji klienti měli být velmi znepokojeni, když řeknu:„Nevím, proč byl ten dotaz pomalý, tak jsem zkusil pár náhodných věcí a hej, našel jsem trik, který funguje. Nevím ale proč." Je to možná jeden z největších zádrhelů vývoje softwaru — pracujeme se složitým systémem, který se rovná překlápění mezi 0 a 1 velmi rychle v určité sekvenci a očekává se, že budeme vědět, proč to neudělalo tímto způsobem, nikoli tímto způsobem.

Věřím, že vývojářům pracujícím s Accessem a VBA stojí za čas a investici, aby skutečně věděl, co dělá, zejména s backendem ODBC. Měli jsme scénáře migrace, kdy jsme z různých důvodů nemuseli mít přístup k nástrojům pro profilování na straně serveru, ale to by neměl být důvod krčit rameny a jen náhodně mačkat tlačítka, dokud něco nefunguje. Ještě důležitější je, když budete dobře rozumět tomu, co se děje pod kapotou, pomůže vám to mnohem lépe předvídat, jaké opravy výkonu musíte pro daný scénář použít. Domnívám se, že i kdyby jste si jen přečetli sérii a naučili se, jak Access pracuje se zdroji dat ODBC, budete mnohem lépe vybaveni jednoduše proto, že víte, co Access pravděpodobně udělá.

U složitějších scénářů může trasování obvykle dělat zázraky při odhalování toho, proč věci běží tak pomalu. Vzhledem k tomu, že jej můžete sledovat na straně přístupu spíše na serveru, nevyžaduje zvýšená oprávnění kromě přístupu ke klíči registru k povolení trasování ODBC. Přidaný bonus je, že to funguje pro všechny zdroje dat ODBC, nejen pro SQL Server, takže pokud máte klienta, který používá MySQL nebo PostgreSQL, o kterém nic nevíte, trasování ODBC vám stále pomůže identifikovat potenciální problémy, které pak můžete řešit přímo na Přístupová strana.

Série se zaměří pouze na kontext Access a DAO. Věci se mohou lišit, když používáme ADO ve VBA, ale to prozatím není v rozsahu, protože kdykoli použijeme DAO, Access udělá několik věcí, aby uspokojil naše jinak nemožné požadavky. Dobrým příkladem je Access dotaz, který odkazuje na funkci VBA. Na SQL Serveru nemůžete spustit funkci VBA, ale Access si nestěžuje. Co se tedy skutečně děje za oponou? Můžeme zjistit, co Access dělá, sledováním příkazů ODBC SQL, které vydává, do zdrojů dat ODBC.

Mnoho informací uvedených v této sérii článků je umožněno pomocí starého dokumentu společnosti Microsoft o Jet &ODBC. I když si myslím, že informace jsou stále velmi přínosné, jsou také poměrně husté a vyžadují vysokou úroveň technické zdatnosti. Doufáme, že procházením sledovací série pomůže dát smysl a prezentovat informace přístupnějším způsobem.

Proč bychom měli sledovat ODBC? Jak mi to pomůže?

Pokud jste někdy zaznamenali některý z těchto příznaků:

Nebo jakékoli jiné chyby při práci s propojenou tabulkou ODBC, pak je užitečné pochopit, proč tyto zprávy dostáváte a jak je můžete opravit. Běžnou opravou, kterou používá několik vývojářů Accessu, je buď přidat Requery, nebo se pokusit záznamy uložit. I když by to mohlo vyřešit některé problémy, není neslýchané vidět složitý formulář Access, který je hojně posypán Requery a několik kaskádových řetězců událostí, které začínají trpět výkonem. Místo toho, abychom je kropili, jako by to byl kouzelný skřítek prach, měli bychom být v našich přístupech k řešení problémů s aplikací chirurgickejší.

Dalším přesvědčivým důvodem je schopnost analyzovat, proč otevření konkrétního formuláře A trvá 10 sekund, ale otevření podobného formuláře B pouze 2 sekundy. Namísto toho, abyste věnovali čas promíchávání věcí, abyste našli to, co způsobuje, že se forma A otevírá rychleji, můžete začít sledováním a porovnáním rozdílu a poté se zaměřit na rozdíl, abyste mohli problémy vyřešit přímějším způsobem.

I když ne vždy skončíme se sledováním pokaždé, když nastanou problémy s výkonem, znalost toho, co by měl Access dělat, má nesmírnou hodnotu. Takže i když jste si celou sérii přečetli, doufejme, že lépe pochopíte, jak pracovat s Accessem než proti.

Přístup k dialektům SQL a ODBC SQL

Než se dostaneme k podrobnostem, musíme si uvědomit, že kdykoli Access pracuje se zdrojem dat ODBC, musí nejprve přeložit svůj příkaz SQL na platný příkaz SQL ODBC. To se liší od cílového dialektu SQL backendu (např. SQL Server, Oracle, MySQL, PostgreSQL). Zde je popsána gramatika ODBC SQL. Můžete také vidět seznam všech funkcí podporovaných vrstvou ODBC. Je důležité si uvědomit, že když používáme ODBC, ve skutečnosti nepřekládáme přímo z Access SQL do nativního SQL dialektu zdroje dat. Spíše překládáme Access SQL do ODBC SQL, který pak ovladač ODBC pro daný zdroj dat přeloží do jeho rodného dialektu. Pokud si dokážete představit japonského mluvčího a francouzštinu, kteří nemluví cizím jazykem, ale oba mluví anglicky, to je v podstatě to, co se děje na ODBC vrstvě. Dalším důsledkem je, že to, že dialekt ODBC podporuje funkci X, neznamená, že ji podporuje některá ze stran. Obě strany musí podporovat tuto funkci X, aby byla přenosná přes vrstvu ODBC. Naštěstí je většina ovladačů ODBC poměrně široká a dobře pokrývají většinu funkcí. Pokud byste se dostali do situace, kdy by nějaká funkce měla fungovat, ale nefunguje, může se vyplatit podívat se do dokumentace ovladače ODBC a ověřit, zda je podporována.

Povolení trasování ODBC SQL

První věc, kterou musíme udělat, abychom mohli nahlédnout za závěsy, je povolit trasování ODBC SQL. I když můžeme použít SQL Server Profiler, pohled na to, jak Access formátuje ODBC SQL, je velmi užitečný. Bude fungovat se všemi zdroji dat ODBC, nejen se serverem SQL. Ještě důležitější je, že nám to umožňuje zobrazit, jak Access převádí své dotazy do ODBC přímějším způsobem než SQL Server Profiler nebo jiné nástroje pro profilování na straně serveru. K použití trasování ODBC SQL nepotřebujete žádná zvláštní oprávnění, zatímco nástroje pro profilování na straně serveru mohou vyžadovat vysokou úroveň oprávnění k použití. Povolení trasování ODBC SQL je nastavení registru, takže jej můžeme nakonfigurovat přechodem na příslušný klíč registru:

Verze databáze Jet nebo Office před rokem 2007

Pro 32bitový systém Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC

Pro 32bitový stroj Jet nebo Office starší než 2007 v 64bitovém systému Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC

Poznámka:Neexistují žádné 64bitové verze zastaralého stroje Jet.

Office 2007 až 2016 (instalace MSI)

Pro 32bitový Office v 32bitovém systému Windows nebo 64bitový Office v 64bitovém systému Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC

Pro 32bitový Office v 64bitovém systému Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC

(kde X.Y odpovídá verzi Office, kterou jste nainstalovali)

Office 2016 nebo Office 365 (spustit kliknutím)

Pro 32bitový Office v 32bitovém systému Windows nebo 64bitový Office v 64bitovém systému Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC

Pro 32bitový Office v 64bitovém systému Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC

Pod klíčem vyhledejte klíč TraceSQLMode a změňte hodnotu z 01 .

Pokud je již přístup otevřený, bude nutné jej restartovat. V opačném případě jej otevřete a spusťte nějaké dotazy. Soubor s názvem sqlout.txt bude vytvořen v aktuálním adresáři. To je obvykle buď ve stejné složce jako soubor Access NEBO ve složce dokumentů. Případně můžete spustit funkci VBA CurDir k určení aktuálního adresáře.

Doporučuji použít Notepad++ nebo podobný textový editor, který má schopnost detekovat, že byl změněn. Poté vás vyzve k opětovnému načtení souboru. To vám umožní zobrazit nové aktualizace, protože Access vysílá nové příkazy do textového souboru bez neustálého opětovného otevírání. Když aktivujete textový soubor, Notepad++ zobrazí dialogové okno:

Poté můžete kliknout na Yes zobrazíte nejnovější příkazy ODBC SQL vydané aplikací Access. Protože Access může vydávat několik příkazů ODBC SQL, protokol se může rychle zvětšovat. Považuji za vhodné dostat se do bodu, kdy chci něco sledovat (např. když se chystám otevřít formulář nebo spustit dotaz), pak přepnu na sqlout.txt , znovu jej načtěte, vyberte vše, odstraňte veškerý text a poté uložte nyní prázdný soubor. Tímto způsobem mohu provést akci, kterou chci sledovat, a poté uvidím pouze příslušné příkazy ODBC bez všech ostatních zvuků, které nemají nic společného s trasovanou akcí.

Zde je rychlé video k demonstraci:

Závěry

Naučili jste se, jak zapnout trasování ODBC a zobrazit výstup generovaný aplikací Access. Můžete vidět, že můžete shromažďovat výstup i z akcí, jako je jednoduché otevření tabulky nebo spuštění dotazu. To vám dává přehled o tom, jaké dotazy SQL ve skutečnosti odesílá Access do zdroje dat ODBC.

Jak vidíte, trasování ODBC SQL zachycuje všechny příkazy ODBC SQL vydané aplikací Access, i když jste je přímo nevydali. Proto jej můžete použít kdykoli, kde dochází ke zpomalení, pro které nemáte dobré vysvětlení. Předpokládejme například, že máte formulář, který se otevírá pomalu, a nejste si jisti, zda se jedná o váš kód VBA v Open formuláře. nebo Load události nebo zdroj záznamů, který je problémem. Strategií by bylo nastavit aplikaci Access tak, abyste se chystali otevřít tento formulář, vymažte sqlout.txt textový soubor a poté pokračujte k otevření formuláře. Poté můžete zkontrolovat trasované příkazy SQL ODBC a určit, zda existují nějaké, které lze zlepšit.

To je zvláště cenné, když máte co do činění se složitým formulářem nebo sestavou, která také obsahuje podformulář/podsestavy nebo obsahuje comboboxy či seznamy, které zadávají vlastní dotazy k uspokojení vlastnosti rowsource.

V příštím článku budeme analyzovat výstup, když budeme procházet záznamy.

Potřebujete pomoci s Microsoft Access? Kontaktujte náš tým na čísle 773-809-5456 nebo nám napište na [email protected].


  1. Jak MINUTE() funguje v MariaDB

  2. Aggregační funkce SQLite

  3. Jak mohu zavést více podmínek v operátoru LIKE?

  4. Problém Java + Mysql UTF8