Jak program Access komunikuje się ze źródłami danych ODBC? Część 2

AKTUALIZACJA: Dodano więcej wyjaśnień dotyczących znaczenia SQLExecute i jak program Access obsługuje przygotowane zapytania. Dzięki, Bob!

Co robi Access, gdy przeglądamy i przeglądamy rekordy w tabeli połączonej ODBC?

W drugiej części naszej serii śledzenia ODBC skupimy się na wpływie typów zestawów rekordów na tabelę połączoną ODBC. W poprzednim artykule dowiedzieliśmy się, jak włączyć śledzenie ODBC SQL i możemy teraz zobaczyć wynik. Jeśli trochę się z tym pobawiłeś, być może zauważyłeś, że zapytanie programu Access i instrukcje SQL ODBC generowane przez program Access nie wyglądają zbyt podobnie. Przedstawimy również dogłębne spojrzenie na to, jak typy wpływają na zachowanie zapytań SELECT, a także przyjrzymy się różnym odmianom zestawów rekordów, takich jak migawki i zestawy dynamiczne.

Jeśli chcesz kontynuować, możesz skorzystać z przykładowej bazy danych podanej tutaj.

Wpływ typów zestawów rekordów w zapytaniu SELECT

Typy zestawów rekordów mają duży wpływ na sposób komunikowania się programu Access ze źródłami danych ODBC. Być może zauważyłeś, że w widoku projektu formularza lub widoku projektu zapytania można ustawić typ zestawu rekordów. Domyślnie jest ustawiony na Dynaset .

W VBA mamy jeszcze kilka opcji, ale na razie nie będziemy się tym martwić. Zacznijmy od zrozumienia, co dokładnie Dynaset i Snapshot oznacza pierwszy. Zaczniemy od mniej powszechnie używanego typu, Snapshot pierwszy.

Zestawy rekordów typu Snapshot

Snapshot jest dość proste. Zasadniczo oznacza to, że robimy migawkę wyniku w momencie wykonania zapytania. Zwykle oznacza to również, że program Access nie może zaktualizować wyniku. Przyjrzyjmy się jednak, jak program Access wysyła zapytanie do źródła za pomocą zestawu rekordów opartego na migawce. Możemy utworzyć nowe zapytanie programu Access, takie jak:

Kod SQL, który możemy zobaczyć w widoku SQL zapytania programu Access, to:

SELECT Cities.*
FROM Cities;

SQLExecDirect:
SELECT
   "CityID"
  ,"CityName"
  ,"StateProvinceID"
  ,"Location"
  ,"LatestRecordedPopulation"
  ,"LastEditedBy"
  ,"ValidFrom"
  ,"ValidTo"
FROM "Application"."Cities"

1. Program Access zakwalifikował tabelę nazwą schematu. Oczywiście w dialekcie Access SQL, który nie działa w ten sam sposób, ale w dialekcie ODBC SQL, warto upewnić się, że wybieramy z właściwej tabeli. To jest regulowane przez SourceTableName nieruchomość.
2. Access rozszerzył zawartość Cities.* do wyliczonej listy wszystkich kolumn, o których już wie Access, na podstawie Fields kolekcja bazowego TableDef obiekt.
3. Dostęp użył " cytować identyfikatory, czego oczekuje dialekt ODBC SQL. Mimo że zarówno Access SQL, jak i Transact-SQL używają nawiasów do cytowania identyfikatora, nie jest to prawidłowa składnia w dialekcie ODBC SQL.

Tak więc, mimo że wykonaliśmy tylko proste zapytanie migawkowe, wybierające wszystkie kolumny dla tabeli, widać, że program Access dokonuje wielu transformacji kodu SQL między tym, co umieścisz w widoku projektu zapytania programu Access lub w widoku SQL, a tym, co program Access faktycznie emituje do danych źródło. Jednak w tym przypadku jest to głównie składnia, więc nie ma żadnej rzeczywistej różnicy w instrukcji SQL między oryginalnym zapytaniem Access a instrukcją SQL ODBC.

Ślad dodał również SQLExecDirect na początku instrukcji SQL. Wrócimy do tego, gdy przyjrzymy się kilku innym przykładom.

Zestawy rekordów typu Dynaset

Użyjemy tego samego zapytania, ale zmienimy właściwość z powrotem na domyślną, Dynaset .
Uruchom go ponownie, a zobaczymy, co otrzymamy z pliku sqlout.txt . Ponownie jest sformatowany pod kątem czytelności:

SQLExecDirect:
SELECT
  "Application"."Cities"."CityID"
FROM "Application"."Cities"

SQLPrepare:
SELECT
   "CityID"
  ,"CityName"
  ,"StateProvinceID"
  ,"Location"
  ,"LatestRecordedPopulation"
  ,"LastEditedBy"
  ,"ValidFrom"
  ,"ValidTo"
FROM "Application"."Cities"
WHERE "CityID" = ?

SQLExecute: (GOTO BOOKMARK)

SQLPrepare:
SELECT
   "CityID"
  ,"CityName"
  ,"StateProvinceID"
  ,"Location"
  ,"LatestRecordedPopulation"
  ,"LastEditedBy"
  ,"ValidFrom"
  ,"ValidTo"
FROM "Application"."Cities"
WHERE "CityID" = ?
   OR "CityID" = ?
   OR "CityID" = ?
   OR "CityID" = ?
   OR "CityID" = ?
   OR "CityID" = ?
   OR "CityID" = ?
   OR "CityID" = ?
   OR "CityID" = ?
   OR "CityID" = ?

SQLExecute: (MULTI-ROW FETCH)

SQLExecute: (MULTI-ROW FETCH)

Pierwszy wybiera tylko CityID kolumna. Tak się składa, że ​​jest to klucz podstawowy tabeli, ale co ważniejsze, jest to indeks, którego Access używa po swojej stronie. Stanie się to ważne, gdy później będziemy studiować poglądy. Program Access używa tego zapytania, aby pobrać klucze i użyć go do późniejszego wypełnienia innych zapytań, jak zobaczymy.

Druga instrukcja jest bardziej zbliżona do oryginalnego zapytania migawki, z tą różnicą, że mamy teraz nowe WHERE filtrowanie klauzul w CityID kolumna. Z tego widać, że jest to pobieranie jednorzędowe. Możemy użyć kluczy otrzymanych z pierwszego zapytania i zebrać pozostałe kolumny w tym zapytaniu. Za każdym razem, gdy tak przygotowana instrukcja zostanie wykonana, zobaczysz SQLExecute: (GOTO BOOKMARK) .

Ale byłoby to nieefektywne, gdybyśmy musieli to zrobić dla wszystkich wierszy… I tu pojawia się następne zapytanie. Trzecia instrukcja jest podobna do drugiej, ale ma 10 predykatów. To przygotowane zapytanie jest wykonywane z każdym SQLExecute: (MULTI_ROW FETCH) . Oznacza to, że gdy ładujemy formularz lub arkusz danych lub nawet otwieramy zestaw rekordów w kodzie VBA, program Access użyje wersji jednorzędowej lub wielowierszowej i wypełni parametry za pomocą kluczy otrzymanych z pierwszego zapytanie.

Pobieranie i ponowne synchronizowanie w tle

Nawiasem mówiąc, czy zauważyłeś, że po otwarciu formularza lub arkusza danych nie widzisz „X z Y” na pasku nawigacyjnym?

To dlatego, że program Access nie może wiedzieć, ile ich jest, dopóki nie zakończy zbierania wyników pierwszego zapytania. Dlatego często może się okazać, że bardzo szybko można otworzyć zapytanie, które zwraca dużą ilość danych. Wyświetlasz tylko podgląd tylko małego okna całego zestawu rekordów, gdy program Access pobiera wiersze w tle. Jeśli klikniesz przycisk „Przejdź do ostatniego”, może się okazać, że blokuje dostęp. Musiałbyś poczekać, aż zakończy pobieranie wszystkich kluczy w pierwszym zapytaniu, zanim zobaczymy „X z Y” na pasku nawigacyjnym.

W ten sposób możesz docenić, że program Access może zapewnić iluzję szybkiego otwierania nawet dużego zestawu rekordów, gdy zestaw rekordów typu dynaset i jest to zwykle dobre doświadczenie dla użytkownika.

Na koniec musimy zauważyć, że otrzymaliśmy 3 różne typy wykonań, SQLExecDirect , SQLPrepare i SQLExecute . Widać, że przy tym pierwszym nie mamy żadnych parametrów. Zapytanie jest po prostu takie, jakie jest. Jeśli jednak zapytanie musi zostać sparametryzowane, należy je najpierw przygotować za pomocą SQLPrepare a następnie wykonywane za pomocą SQLExecute z podanymi wartościami parametrów. Nie możemy zobaczyć, jakie wartości zostały faktycznie przekazane do SQLExecute oświadczenie, chociaż możemy wywnioskować z tego, co widzimy w programie Access. Możesz tylko wiedzieć, czy pobrał pojedynczy wiersz (za pomocą SQLExecute: (GOTO BOOKMARK) lub wiele wierszy (za pomocą SQLExecute: (MULTI-ROW FETCH) ). Program Access użyje wersji wielowierszowej do pobierania w tle i przyrostowego wypełniania zestawu rekordów, ale użyje wersji jednowierszowej do wypełnienia tylko jednego wiersza. Może tak być w przypadku pojedynczego widoku formularza, w przeciwieństwie do ciągłego widoku formularza lub arkusza danych, lub użyć go do ponownej synchronizacji po aktualizacji.

Poruszanie się

Przy wystarczająco dużym zestawie rekordów program Access może nie być w stanie ukończyć pobierania wszystkich rekordów. Jak wspomniano wcześniej, użytkownikowi prezentowane są dane tak szybko, jak to możliwe. Zwykle, gdy użytkownik przechodzi dalej przez zestaw rekordów, program Access będzie pobierał coraz więcej rekordów, aby zachować bufor przed użytkownikiem.

Ale załóżmy, że użytkownik przeskakuje do 100. wiersza, przechodząc do sterowania nawigacją i wpisując tam 100?

W takim przypadku program Access prześle następujące zapytania…

SQLExecute: (MULTI-ROW FETCH)

SQLExecute: (GOTO BOOKMARK)

SQLExecute: (MULTI-ROW FETCH)

SQLExecute: (MULTI-ROW FETCH)

Gdy program Access uzyska dane dla wierszy z setnego wiersza, zabierze tam użytkownika, a następnie zacznij wypełniać bufor wokół tego setnego wiersza. Umożliwia to użytkownikowi przeglądanie setnego wiersza bez konieczności czekania na załadowanie wszystkich rekordów od 11 do 99. Użytkownik ma również pozornie szybkie przeglądanie, gdy kliknie poprzedni lub następny z nowej pozycji, ponieważ program Access już załadował go w tle, zanim użytkownik o to poprosił. Daje to złudzenie szybkości nawet w wolnej sieci.

Ale nawet jeśli użytkownik pozostawił formularz otwarty i bezczynny, program Access kontynuowałby zarówno pobieranie w tle, jak i odświeżanie bufora, aby uniknąć wyświetlania przestarzałych danych użytkownika. Jest to regulowane przez ustawienia ODBC w oknie dialogowym Opcje, w sekcji Zaawansowane na karcie Ustawienia klienta:

Domyślny interwał odświeżania ODBC to 1500 sekund, ale można go zmienić. Można to również zmienić za pomocą VBA.

Wnioski:masywny lub gadatliwy

Powinieneś teraz zauważyć, że głównym powodem, dla którego zestawy rekordów typu dynaset można aktualizować, ale nie są to zestawy rekordów typu migawka, jest to, że program Access jest w stanie zastąpić wiersz w zestawie rekordów najnowszą wersją tego samego z serwera, ponieważ wie, jak wybrać jeden rząd. Z tego powodu program Access musi zarządzać 2 zapytaniami ODBC; jeden do pobrania kluczy, a drugi do pobrania aktualnej zawartości wierszy dla danego klucza. Te informacje nie były obecne w zestawie rekordów typu migawki. Właśnie otrzymaliśmy duży blok danych.

Przyjrzeliśmy się dwóm głównym typom zestawów rekordów, chociaż jest ich więcej. Jednak inne są tylko wariantami 2 typów, które omówiliśmy. Ale na razie wystarczy pamiętać, że korzystanie z migawki oznacza sporą część komunikacji sieciowej. Z drugiej strony, używanie dynasetu oznacza, że ​​będziemy rozmowni. Obaj mają swoje wzloty i upadki.

Na przykład zestaw rekordów migawki nie wymaga dalszej komunikacji z serwerem po pobraniu danych. Dopóki zestaw rekordów pozostaje otwarty, program Access może swobodnie poruszać się po swojej lokalnej pamięci podręcznej. Dostęp również nie musi utrzymywać żadnych blokad, a tym samym blokować innych użytkowników. Jednak zestaw rekordów migawek jest z konieczności wolniejszy do otwarcia, ponieważ musi z góry zbierać wszystkie dane. Może to nie pasować do dużego zestawu rekordów, nawet jeśli zamierzasz odczytać wszystkie dane.

Załóżmy, że tworzysz duży raport programu Access, który ma 100 stron, zwykle warto użyć zestawu rekordów typu dynaset. Może rozpocząć renderowanie podglądu, gdy tylko wystarczy na wyrenderowanie pierwszej strony. To lepsze niż zmuszanie Cię do czekania, aż pobierze wszystkie dane, zanim zacznie renderować podgląd. Chociaż zestaw rekordów Dynaset może przyjmować blokady, zwykle trwa to krótko. Czas wystarczy, aby Access zresynchronizował swoją lokalną pamięć podręczną.

Ale kiedy pomyślimy o tym, o ile więcej żądań Access przesyła przez sieć za pomocą zestawu rekordów typu dynaset, łatwo zauważyć, że jeśli opóźnienie sieci jest niskie, wydajność Access odpowiednio ucierpi. Aby program Access umożliwiał użytkownikom edytowanie i aktualizowanie źródeł danych w sposób ogólny, program Access musi śledzić klucze do wybierania i modyfikowania pojedynczego wiersza. Przyjrzymy się temu w nadchodzących artykułach. W następnym artykule przyjrzymy się, jak sortowanie i grupowanie wpływa na zestaw rekordów typu dynaset, a także jak program Access określa klucz używany dla zestawu rekordów typu dynaset.

Aby uzyskać dodatkową pomoc dotyczącą programu Microsoft Access, zadzwoń do naszych ekspertów pod numer 773-809-5456 lub wyślij e-mail na adres [email protected].