Това е поредица от статии от шест части за ODBC проследяване, за да помогне на разработчиците на Access да отстраняват неизправности и да работят с Access, когато разработват приложение, което използва източник(и) на ODBC данни, обикновено, но не изключително SQL Server. Серията има за цел да демонстрира как да се използва ODBC проследяването за наблюдение на ODBC SQL изрази, които Access издава във фонов режим при работа с обекти като заявки, формуляри или отчети или дори при изпълнение на VBA код срещу DAO обекти. Серията също така ще покаже как Access формулира ODBC SQL изразите. И накрая, поредицата ще обхване как да интерпретираме проследяването и да идентифицираме потенциални проблеми. Статиите ще се отпечатват ежедневно до приключване на поредицата.
АКТУАЛИЗИРАНЕ: Добавен ключ на системния регистър за 32-битова C2R инсталация на 64-битов Windows. Благодаря, Джак Макдоналд!
Колко пъти сте чували „Не знам защо, но поклащането на дръжката просто работи“? Всеки път, когато получа такъв отговор, това ме дразни, защото е толкова неудовлетворяващо. Бих бил много притеснен, ако моят водопроводчик ми каже, че не знае, че е за P-капан и продължи да го нарича „това извито нещо под мивката“. По същия начин клиентите ми трябва да са много загрижени, ако кажа „Не знам защо тази заявка беше бавна, така че опитах няколко произволни неща и хей, открих трик, който работи. Не знам защо обаче." Това е може би една от най-големите проклятия на разработката на софтуер – ние работим със сложна система, която се равнява на преливане между 0 и 1 много бързо в определена последователност и се очаква да знаем защо не е постъпила по този начин, вместо по този начин.
Вярвам, че си струва времето и инвестицията за разработчика, който работи с Access и VBA, за да разбере наистина какво прави, особено с ODBC бекенд. Имахме сценарии за миграция, при които може да нямаме достъп до инструментите за профилиране от страна на сървъра по различни причини, но това не трябва да е причина да свиваме рамене и просто да разбиваме на случаен принцип бутони, докато нещо проработи. По-важното е, че доброто разбиране на това, което се случва под капака, ви помага да станете много по-добри в прогнозирането на кои корекции на производителността трябва да приложите за даден сценарий. Твърдя, че дори ако всичко, което направихте, беше да прочетете поредицата и да научите как Access работи с ODBC източници на данни, ще бъдете много по-добре подготвени, просто защото знаете какво вероятно ще направи Access.
За по-сложни сценарии проследяването обикновено може да направи чудеса, като разкрие защо нещата вървят толкова бавно. Тъй като можете да го проследите от страната на Access, а по-скоро на сървъра, той не изисква повишени разрешения освен достъпа до ключа на системния регистър, за да активирате ODBC проследяване. Допълнителният бонус е, че това работи за всякакви източници на данни ODBC, а не само за SQL Server, така че ако имате клиент, който използва MySQL или PostgreSQL, за които не знаете нищо, проследяването на ODBC все още ще ви помогне да идентифицирате потенциални проблеми, които след това можете да адресирате директно Страната за достъп.
Серията ще се фокусира само от контекста на Access и DAO. Нещата може да са различни, когато използваме ADO във VBA, но това засега не е в обхвата, защото всеки път, когато използваме DAO, Access ще направи няколко неща, за да удовлетвори нашите иначе невъзможни заявки. Добър пример е заявка на Access, която препраща към VBA функция. Не можете да стартирате VBA функция на SQL Server, но Access не се оплаква. И така, какво всъщност се случва зад завесата? Можем да открием какво прави Access, като проследим ODBC SQL командите, които издава, до източниците на ODBC данни.
Голяма част от информацията, представена в тази серия от статии, става възможна с помощта на старата бяла книга на Microsoft за Jet &ODBC. Въпреки че смятам, че информацията все още е много полезна, тя също е доста гъста и изисква високо ниво на технически умения. Надяваме се, че преминаването през сериите за проследяване ще помогне за осмисляне и представяне на информацията по по-достъпен начин.
Защо трябва да проследяваме ODBC? Как ще ми помогне?
Ако някога сте изпитвали някой от тези симптоми:
Или някакви други грешки при работа с ODBC свързана таблица, тогава е полезно да разберете защо получавате тези съобщения и как можете да ги коригирате. Често срещана корекция, която няколко разработчици на Access прилагат, е или да добавят Requery, или да опитат да запазят записите. Въпреки че това може да реши някои от проблемите, не е нещо нечувано да видите сложен формуляр за достъп да бъде обилно поръсен с Requery и няколко каскадни вериги от събития, от които изпълнението започва да страда. Вместо да ги пръскаме, сякаш са вълшебен прах от пикси, трябва да бъдем по-хирургични в подходите си за отстраняване на проблеми с приложението.
Друга убедителна причина е да можете да анализирате защо на дадена форма А са необходими 10 секунди, за да се отвори, а на подобна форма В – само 2 секунди за отваряне. Вместо да отделяте време, за да разбъркате нещата, за да намерите това, което прави форма А да се отваря по-бързо, можете да започнете с проследяване и сравнение на разликата и след това да се съсредоточите върху разликата, за да ви помогне да отстраните проблемите по по-директен начин.
Дори ако не винаги в крайна сметка проследяваме всеки път, когато има проблеми с производителността, познаването на това, което Access трябва да прави, е от огромна стойност. Така че дори ако всичко, което сте направили, е да прочетете поредицата, да се надяваме, че ще имате по-добра оценка за това как да работите с Access, а не срещу.
Достъп до SQL и ODBC SQL диалекти
Преди да влезем в подробностите, трябва да признаем, че когато Access работи с ODBC източник на данни, той трябва първо да преведе своя SQL израз в валиден ODBC SQL израз. Това е различно от целевия SQL диалект на бекенда (например SQL Server, Oracle, MySQL, PostgreSQL). ODBC SQL граматиката е описана тук. Можете също да видите списък с всички функции, поддържани от слоя ODBC. Важно е да запомните, че когато използваме ODBC, ние всъщност не превеждаме директно от Access SQL към естествения SQL диалект на източника на данни. По-скоро ние превеждаме Access SQL в ODBC SQL, който ODBC драйверът за даден източник на данни след това ще преведе на своя роден диалект. Ако можете да си представите говорещ японски и френски, които не говорят езика на един друг, но и двамата говорят английски, това по същество се случва над слоя ODBC. Друга последица е, че само защото ODBC диалектът поддържа функция X, не означава, че която и да е от страните я поддържа. И двете страни трябва да поддържат тази функция X, за да бъде преносима през слоя ODBC. За щастие повечето ODBC драйвери са доста широки и вършат добра работа, покривайки повечето от функциите. Ако срещнете ситуация, в която се предполага, че дадена функция трябва да работи, но не работи, може да си струва да се консултирате с документацията на ODBC драйвера, за да проверите дали се поддържа.
Активиране на ODBC SQL проследяване
Първото нещо, което трябва да направим, за да можем да надникнем зад завесите, е да активираме ODBC SQL проследяването. Въпреки че можем да използваме SQL Server Profiler, разглеждането на това как Access форматира ODBC SQL е много полезно. Той ще работи с всякакви ODBC източници на данни, а не само с SQL Server. По-важното е, че това ни позволява да видим как Access превежда своите заявки към ODBC по по-директен начин от SQL Server Profiler или други инструменти за профилиране от страна на сървъра. Не се нуждаете от специални разрешения, за да използвате ODBC SQL проследяване, докато инструментите за профилиране от страна на сървъра може да изискват високо ниво на разрешение за използване. Активирането на ODBC SQL проследяване е настройка на системния регистър, така че можем да конфигурираме това, като отидем на съответния ключ на системния регистър:
База данни Jet или версии на Office преди 2007 г.
За 32-битов Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC
За 32-битов Jet двигател или Office преди 2007 г. на 64-битов Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC
Забележка:Няма 64-битова версия на остарелия двигател Jet.
Office 2007 до 2016 (инсталирания на MSI)
За 32-битов Office на 32-битов Windows или 64-битов Office на 64-битов Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
За 32-битов Office на 64-битов Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
(където X.Y съответства на версията на Office, която сте инсталирали)
Office 2016 или Office 365 (щракнете, за да стартирате)
За 32-битов Office на 32-битов Windows или 64-битов Office на 64-битов Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
За 32-битов Office на 64-битов Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Под ключа намерете ключа TraceSQLMode и променете стойността от 0 до 1 .
Достъпът ще трябва да бъде рестартиран, ако вече е отворен. В противен случай го отворете и изпълнете някои заявки. Файл с име sqlout.txt ще бъде създаден в текущата директория. Това обикновено е в същата папка като файла на Access ИЛИ в папката с документи. Като алтернатива можете да изпълните VBA функция CurDir за да определите текущата директория.
Препоръчвам да използвате Notepad++ или подобен текстов редактор, който има способността да открие, че е променен. След това ще ви подкани да презаредите файла. Това ви позволява да преглеждате нови актуализации, тъй като Access излъчва нови команди към текстовия файл без постоянно повторно отваряне. Когато активирате текстовия файл, Notepad++ ще покаже диалогов прозорец:
След това можете да щракнете върху Yes за да видите най-новите ODBC SQL команди, издадени от Access. Тъй като Access може да издаде няколко ODBC SQL команди, дневникът може да нараства бързо. Намирам за удобно да стигна до точката, в която искам да проследя нещо (например за отваряне на формуляр или стартиране на заявка), след това преминавам към sqlout.txt , презаредете го, след това изберете всички, изтрийте целия текст и след това запазете вече празния файл. По този начин мога да изпълня действието, което искам да проследя, след което да виждам само съответните ODBC команди без всички други шумове, които нямат нищо общо с проследяваното действие.
Ето един бърз видеоклип за демонстрация:
Заключения
Научихте как да включите проследяването на ODBC и да видите изхода, генериран от Access. Можете да видите, че можете да събирате изход дори от действия като просто отваряне на таблица или изпълнение на заявка. Това ви дава представа за това какъв вид SQL заявки всъщност изпраща Access към източника на ODBC данни.
Както можете да видите, ODBC SQL проследяването улавя всички ODBC SQL команди, издадени от Access, дори ако не сте го издали директно. Следователно можете да го използвате във всеки момент, когато изпитвате забавяне, за където нямате добро обяснение. Като пример, да предположим, че имате формуляр, който се отваря бавно и не сте сигурни, че това е вашият VBA код в Open на формуляра или Load събития или източника на запис, който е проблемът. Стратегия би била да настроите приложението Access, така че да сте на път да отворите този формуляр, изчистете sqlout.txt текстов файл, след което продължете да отворите формуляра. След това можете да прегледате проследените ODBC SQL изрази и да определите дали има такива, които могат да бъдат подобрени.
Това е особено ценно, когато имате работа със сложен формуляр или отчет, който също съдържа подформуляр/подотчети или съдържа комбокутия или списъци, които издават свои собствени заявки, за да удовлетворят свойството rowsource.
В следващата статия ще анализираме изхода, когато преглеждаме записи.
Нуждаете се от помощ с Microsoft Access? Свържете се с нашия екип на 773-809-5456 или ни изпратете имейл на [email protected].
