Jest to sześcioczęściowa seria artykułów na temat śledzenia ODBC, która ma pomóc deweloperom programu Access w rozwiązywaniu problemów i pracy z programem Access podczas tworzenia aplikacji korzystających ze źródeł danych ODBC, zwykle, ale nie wyłącznie, programu SQL Server. Seria ma na celu zademonstrowanie, jak używać śledzenia ODBC do monitorowania instrukcji ODBC SQL, które program Access wydaje w tle podczas pracy z obiektami, takimi jak zapytania, formularze lub raporty, a nawet podczas wykonywania kodu VBA na obiektach DAO. Seria pokaże również, w jaki sposób program Access formułuje instrukcje SQL ODBC. Wreszcie seria obejmie, jak interpretować śledzenie i identyfikować potencjalne problemy. Artykuły będą drukowane codziennie, aż do zakończenia serii.
AKTUALIZACJA: Dodano klucz rejestru dla 32-bitowej instalacji C2R w 64-bitowym systemie Windows. Dzięki, Jacku MacDonaldzie!
Ile razy słyszałeś „Nie wiem dlaczego, ale potrząsanie rączką po prostu działa”? Za każdym razem, gdy otrzymuję tego rodzaju odpowiedź, irytuje mnie to, ponieważ jest tak niesatysfakcjonująca. Byłbym bardzo zaniepokojony, gdyby mój hydraulik powiedział mi, że nie wie, że jest to pułapka typu p i dalej nazywał to „taką krętą rzeczą pod zlewem”. Podobnie moi klienci powinni być bardzo zaniepokojeni, gdy powiem:„Nie wiem, dlaczego to zapytanie było powolne, więc wypróbowałem kilka losowych rzeczy i hej, znalazłem działającą sztuczkę. Ale nie wiem dlaczego. Jest to prawdopodobnie jedna z największych zmor w tworzeniu oprogramowania — pracujemy ze złożonym systemem, który polega na bardzo szybkim przeskakiwaniu między 0 a 1 w określonej kolejności i oczekuje się, że wiemy, dlaczego nie zrobił tego w ten sposób, a nie w ten sposób.
Uważam, że warto poświęcić czas i zainwestować, aby programista współpracujący z Access i VBA naprawdę wiedział, co robi, zwłaszcza z backendem ODBC. Mieliśmy scenariusze migracji, w których z różnych powodów możemy nie mieć dostępu do narzędzi do profilowania po stronie serwera, ale nie powinno to być powodem do wzruszania ramion i losowego zacierania przycisków, dopóki coś nie zadziała. Co ważniejsze, solidne zrozumienie tego, co dzieje się pod maską, pomaga znacznie lepiej przewidywać, jakie poprawki wydajności należy zastosować w danym scenariuszu. Twierdzę, że nawet jeśli wszystko, co zrobiłeś, to przeczytanie serii i nauczenie się, jak Access współpracuje ze źródłami danych ODBC, będziesz o wiele lepiej wyposażony, ponieważ wiesz, co prawdopodobnie zrobi Access.
W przypadku bardziej skomplikowanych scenariuszy śledzenie zwykle może zdziałać cuda, ujawniając, dlaczego wszystko działa tak wolno. Ponieważ można go śledzić po stronie programu Access, a nie na serwerze, nie wymaga podwyższonych uprawnień poza dostępem do klucza rejestru w celu włączenia śledzenia ODBC. Dodatkową zaletą jest to, że działa to dla wszystkich źródeł danych ODBC, nie tylko SQL Server, więc jeśli masz klienta korzystającego z MySQL lub PostgreSQL, o którym nic nie wiesz, śledzenie ODBC nadal pomoże Ci zidentyfikować potencjalne problemy, które możesz rozwiązać bezpośrednio na Strona dostępu.
Seria skoncentruje się wyłącznie na kontekście Access i DAO. Rzeczy mogą wyglądać inaczej, gdy używamy ADO w VBA, ale nie jest to na razie w zakresie, ponieważ za każdym razem, gdy używamy DAO, Access zrobi kilka rzeczy, aby spełnić nasze inaczej niemożliwe żądania. Dobrym przykładem jest zapytanie programu Access, które odwołuje się do funkcji VBA. Nie możesz uruchomić funkcji VBA na SQL Server, ale Access nie narzeka. Więc co tak naprawdę dzieje się za zasłoną? Możemy odkryć, co robi Access, śledząc polecenia ODBC SQL, które wydaje w źródłach danych ODBC.
Wiele informacji przedstawionych w tej serii artykułów jest możliwych dzięki starej białej księdze Microsoftu na temat Jet i ODBC. Choć uważam, że informacje są nadal bardzo pożyteczne, są też dość gęste i wymagają dużej biegłości technicznej. Mamy nadzieję, że prześledzenie serii śledzenia pomoże nadać sens i przedstawić informacje w bardziej przystępny sposób.
Dlaczego powinniśmy śledzić ODBC? Jak mi to pomoże?
Jeśli kiedykolwiek doświadczyłeś któregokolwiek z tych objawów:
Lub jakiekolwiek inne błędy podczas pracy z tabelą połączoną ODBC, warto zrozumieć, dlaczego otrzymujesz te wiadomości i jak możesz je naprawić. Częstą poprawką, którą stosują niektórzy programiści programu Access, jest dodanie Ponownej kwerendy lub próba zapisania rekordów. Chociaż może to rozwiązać niektóre problemy, często zdarza się, że złożony formularz Access jest obficie posypany Requery i kilka kaskadowych łańcuchów zdarzeń, które zaczynają ucierpieć na wydajności. Zamiast posypywać je jak magiczny pyłek, powinniśmy bardziej chirurgicznie podchodzić do rozwiązywania problemów z aplikacją.
Innym ważnym powodem jest możliwość przeanalizowania, dlaczego określony formularz A potrzebuje 10 sekund na otwarcie, a podobny formularz B tylko 2 sekundy. Zamiast tracić czas na przetasowanie rzeczy w celu znalezienia tego, co sprawia, że forma A szybciej się otwiera, możesz zacząć od prześledzenia i porównania różnicy, a następnie skoncentrować się na różnicy, aby pomóc rozwiązać problemy w bardziej bezpośredni sposób.
Nawet jeśli nie zawsze kończymy na śledzeniu za każdym razem, gdy pojawiają się problemy z wydajnością, znajomość tego, co powinien zrobić program Access, ma ogromną wartość. Więc nawet jeśli wszystko, co zrobiłeś, to przeczytanie serii, miejmy nadzieję, że lepiej docenisz, jak pracować z programem Access, a nie przeciwko.
Dostęp do dialektów SQL i ODBC SQL
Zanim przejdziemy do szczegółów, musimy zdać sobie sprawę, że zawsze, gdy program Access pracuje ze źródłem danych ODBC, musi najpierw przetłumaczyć swoją instrukcję SQL na prawidłową instrukcję SQL ODBC. Różni się to od docelowego dialektu SQL zaplecza (np. SQL Server, Oracle, MySQL, PostgreSQL). Gramatyka ODBC SQL jest opisana tutaj. Możesz również zobaczyć listę wszystkich funkcji obsługiwanych przez warstwę ODBC. Należy pamiętać, że korzystając z ODBC, w rzeczywistości nie dokonujemy bezpośredniego tłumaczenia z Access SQL na natywny dialekt SQL źródła danych. Zamiast tego tłumaczymy Access SQL na ODBC SQL, który sterownik ODBC dla danego źródła danych przetłumaczy następnie na jego rodzimy dialekt. Jeśli możesz sobie wyobrazić mówiącego po japońsku i francuskojęzycznego, którzy nie mówią innym językiem, ale obaj mówią po angielsku, to w zasadzie dzieje się to w warstwie ODBC. Kolejną konsekwencją jest to, że tylko dlatego, że dialekt ODBC obsługuje funkcję X, nie oznacza, że którakolwiek ze stron ją obsługuje. Obie strony muszą obsługiwać tę funkcję X, aby można ją było przenosić przez warstwę ODBC. Na szczęście większość sterowników ODBC jest dość obszerna i dobrze radzi sobie z obsługą większości funkcji. Jeśli napotkasz sytuację, w której funkcja powinna działać, ale nie działa, warto zapoznać się z dokumentacją sterownika ODBC, aby sprawdzić, czy jest obsługiwana.
Włączanie śledzenia ODBC SQL
Pierwszą rzeczą, którą należy zrobić, abyśmy mogli zajrzeć za zasłonę, jest włączenie śledzenia ODBC SQL. Chociaż możemy użyć programu SQL Server Profiler, przyjrzenie się, jak Access formatuje ODBC SQL, jest bardzo pomocne. Będzie działać z dowolnymi źródłami danych ODBC, a nie tylko z SQL Server. Co ważniejsze, pozwala nam to zobaczyć, w jaki sposób program Access tłumaczy swoje zapytania do ODBC w bardziej bezpośredni sposób niż SQL Server Profiler lub inne narzędzia do profilowania po stronie serwera. Nie potrzebujesz żadnych specjalnych uprawnień do korzystania ze śledzenia ODBC SQL, podczas gdy narzędzia do profilowania po stronie serwera mogą wymagać wysokiego poziomu uprawnień do używania. Włączenie śledzenia ODBC SQL jest ustawieniem rejestru, więc możemy to skonfigurować, przechodząc do odpowiedniego klucza rejestru:
Baza danych Jet lub wersje pakietu Office przed 2007
Dla 32-bitowego systemu Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC
W przypadku 32-bitowego silnika Jet lub pakietu Office sprzed 2007 r. w 64-bitowym systemie Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC
Uwaga:nie ma 64-bitowej wersji przestarzałego silnika Jet.
Office 2007–2016 (instalacje MSI)
W przypadku 32-bitowego pakietu Office w 32-bitowym systemie Windows lub 64-bitowego pakietu Office w 64-bitowym systemie Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
Dla 32-bitowego pakietu Office w 64-bitowym systemie Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
(gdzie X.Y odpowiada zainstalowanej wersji pakietu Office)
Office 2016 lub Office 365 (kliknij, aby uruchomić)
W przypadku 32-bitowego pakietu Office w 32-bitowym systemie Windows lub 64-bitowego pakietu Office w 64-bitowym systemie Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Dla 32-bitowego pakietu Office w 64-bitowym systemie Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Pod kluczem znajdź klucz TraceSQLMode i zmień wartość z 0 do 1 .
Dostęp będzie musiał zostać ponownie uruchomiony, jeśli jest już otwarty. W przeciwnym razie otwórz go i uruchom kilka zapytań. Plik o nazwie sqlout.txt zostanie utworzony w bieżącym katalogu. Zwykle znajduje się to w tym samym folderze co plik Access LUB w folderze dokumentów. Alternatywnie możesz wykonać funkcję VBA CurDir aby określić bieżący katalog.
Polecam używać Notepad ++ lub podobnego edytora tekstu, który ma możliwość wykrycia, że został zmodyfikowany. Następnie poprosi o ponowne załadowanie pliku. Umożliwia to wyświetlanie nowych aktualizacji, ponieważ program Access emituje nowe polecenia do pliku tekstowego bez ciągłego ponownego otwierania. Po aktywowaniu pliku tekstowego Notepad++ wyświetli okno dialogowe:
Następnie możesz kliknąć Yes aby zobaczyć najnowsze polecenia ODBC SQL wydane przez program Access. Ponieważ program Access może wydawać kilka poleceń SQL ODBC, dziennik może szybko rosnąć. Uważam, że wygodnie jest dojść do punktu, w którym chcę coś prześledzić (np. mam zamiar otworzyć formularz lub uruchomić zapytanie), a następnie przełączam się na sqlout.txt , załaduj go ponownie, a następnie zaznacz wszystko, usuń cały tekst, a następnie zapisz pusty teraz plik. W ten sposób mogę wykonać akcję, którą chcę śledzić, a następnie zobaczyć tylko odpowiednie polecenia ODBC bez wszystkich innych dźwięków, które nie mają nic wspólnego z śledzoną akcją.
Oto krótki film do zademonstrowania:
Wnioski
Wiesz już, jak włączyć śledzenie ODBC i wyświetlić dane wyjściowe generowane przez program Access. Możesz zobaczyć, że możesz zbierać dane wyjściowe nawet z akcji, takich jak otwieranie tabeli lub uruchamianie zapytania. Daje to wgląd w to, jakiego rodzaju zapytania SQL Access faktycznie wysyła do źródła danych ODBC.
Jak widać, śledzenie ODBC SQL przechwytuje wszystkie polecenia ODBC SQL wydane przez program Access, nawet jeśli nie wydałeś ich bezpośrednio. Dlatego możesz go użyć w dowolnym momencie, w którym doświadczasz spowolnienia, ponieważ nie masz dobrego wytłumaczenia. Jako przykład załóżmy, że masz formularz, który wolno się otwiera i nie masz pewności, czy to Twój kod VBA w Open formularza lub Load zdarzenia lub źródło rekordów, które są problemem. Strategią byłoby skonfigurowanie aplikacji Access tak, że masz zamiar otworzyć ten formularz, wyczyść sqlout.txt plik tekstowy, a następnie przejdź do otwarcia formularza. Następnie możesz przejrzeć śledzone instrukcje SQL ODBC i określić, czy można je ulepszyć.
Jest to szczególnie cenne, gdy masz do czynienia ze złożonym formularzem lub raportem, który zawiera również podformularz/podraporty lub zawiera pola kombi lub listy, które wysyłają własne zapytania w celu spełnienia właściwości rowsource.
W następnym artykule przeanalizujemy dane wyjściowe podczas przeglądania rekordów.
Potrzebujesz pomocy z Microsoft Access? Skontaktuj się z naszym zespołem pod numerem 773-809-5456 lub napisz do nas na adres [email protected].
