Dette er en seksdelt serie af artikler om ODBC-sporing for at hjælpe Access-udviklere med at fejlfinde og arbejde med Access, når de udvikler en applikation, der bruger ODBC-datakilde(r), normalt, men ikke udelukkende, SQL Server. Serien har til formål at demonstrere, hvordan man bruger ODBC-sporingen til at overvåge ODBC SQL-sætninger, som Access problemer i baggrunden, når man arbejder med objekter såsom forespørgsler, formularer eller rapporter eller endda mens man udfører VBA-kode mod DAO-objekter. Serien vil også vise, hvordan Access formulerer ODBC SQL-sætningerne. Afslutningsvis vil serien dække, hvordan man fortolker sporingen og identificerer potentielle problemer. Artiklerne vil blive trykt dagligt, indtil serien slutter.
OPDATERING: Tilføjet en registreringsnøgle til 32-bit C2R-installation på 64-bit Windows. Tak, Jack MacDonald!
Hvor mange gange har du hørt "jeg ved ikke hvorfor, men det virker bare at vippe i håndtaget"? Når jeg får den slags svar, irriterer det mig, fordi det er så utilfredsstillende. Jeg ville være meget bekymret, hvis min blikkenslager fortalte mig, at han ikke vidste, at en p-fælde er til, og blev ved med at omtale det som "den der kurvede tingamijig under vasken". Ligeledes burde mine kunder være meget bekymrede, hvis jeg sagde "Jeg ved ikke, hvorfor den forespørgsel var langsom, så jeg prøvede nogle tilfældige ting, og hey, jeg fandt et trick, der virker. Jeg ved dog ikke hvorfor." Det er muligvis en af de største baner ved softwareudvikling - vi arbejder med et komplekst system, der svarer til at vende mellem 0 og 1 meget hurtigt i en bestemt rækkefølge og forventes at vide, hvorfor det ikke gjorde på den måde i stedet for på denne måde.
Jeg mener, at det er tiden og investeringen værd for udvikleren, der arbejder med Access og VBA, for virkelig at vide, hvad den laver, især med en ODBC-backend. Vi har haft migreringsscenarier, hvor vi måske ikke har adgang til serversideprofileringsværktøjerne af forskellige årsager, men det burde ikke være en grund til at trække på skuldrene og bare tilfældigt mash knapper, indtil noget virker. Endnu vigtigere er det, at have en solid forståelse af, hvad der foregår under motorhjelmen, hjælper dig med at blive meget bedre til at forudsige, hvilke præstationsrettelser du skal bruge for et givet scenarie. Jeg hævder, at selvom alt, hvad du gjorde, var at læse serien og lære, hvordan Access fungerer med ODBC-datakilder, vil du være meget bedre rustet, blot fordi du ved, hvad Access sandsynligvis vil gøre.
For mere komplicerede scenarier kan sporing normalt gøre underværker ved at afsløre, hvorfor tingene kører så langsomt. Fordi du kan spore det på Access-siden i stedet for på serveren, kræver det ikke forhøjede tilladelser ud over at have adgang til registreringsdatabasenøglen for at aktivere ODBC-sporing. Den ekstra bonus er, at dette virker for alle ODBC-datakilder, ikke kun SQL Server, så hvis du har en klient, der bruger MySQL eller PostgreSQL, som du ikke ved noget om, vil ODBC-sporing stadig hjælpe dig med at identificere potentielle problemer, som du derefter kan løse direkte på Adgangssiden.
Serien vil kun fokusere fra konteksten af Access og DAO. Tingene kan være anderledes, når vi bruger ADO i VBA, men det er ikke i omfang for nu, fordi når vi bruger DAO, vil Access gøre flere ting for at tilfredsstille vores ellers umulige anmodninger. Et godt eksempel er en Access-forespørgsel, der refererer til en VBA-funktion. Du kan ikke køre VBA-funktion på SQL Server, men Access klager ikke. Så hvad sker der egentlig bag gardinet? Vi kan finde ud af, hvad Access gør ved at spore de ODBC SQL-kommandoer, den udsteder til ODBC-datakilderne.
Meget af informationen præsenteret i denne serie af artikler er gjort mulig ved hjælp af Microsofts gamle hvidbog om Jet &ODBC. Selvom jeg synes, at informationen stadig er meget gavnlig, er den også ret tæt og kræver høj teknisk færdighed. Det er håbet, at det ved at gennemgå sporingsserien vil hjælpe med at give mening og præsentere informationen på en mere tilgængelig måde.
Hvorfor skal vi spore ODBC? Hvordan vil det hjælpe mig?
Hvis du nogensinde har oplevet nogen af disse symptomer:
Eller andre fejl, når du arbejder med en ODBC-linket tabel, så er det en fordel at forstå, hvorfor du får disse meddelelser, og hvordan du kan rette dem. En almindelig rettelse, som flere Access-udviklere anvender, er enten at tilføje Requery eller forsøge at gemme posterne. Selvom det måske løser nogle af problemerne, er det ikke uhørt at se en kompleks adgangsformular blive rigt drysset med Requery og flere overlappende begivenhedskæder, som forestillingen begynder at lide under. I stedet for at drysse dem, som om de var magisk nissestøv, burde vi være mere kirurgiske i vores tilgange til at løse problemer med applikationen.
En anden overbevisende grund er at kunne analysere, hvorfor en bestemt form A tager 10 sekunder at åbne, men en lignende form B kun 2 sekunder om at åbne. I stedet for at bruge tid på at blande tingene rundt for at finde, hvad der gør formular A hurtigere åben, kan du starte med at spore og sammenligne forskellen og derefter fokusere på forskellen for at hjælpe dig med at løse problemerne på en mere direkte måde.
Selvom vi ikke altid ender med at spore, hver gang der er problemer med ydeevnen, er det af enorm værdi at have kendskab til, hvad Access burde gøre. Så selvom alt, hvad du har gjort, er at læse serien, vil du forhåbentlig have en bedre forståelse af, hvordan du arbejder med Access frem for imod.
Få adgang til SQL- og ODBC SQL-dialekter
Før vi kommer ind i detaljerne, skal vi erkende, at når Access arbejder med en ODBC-datakilde, skal den først oversætte sin SQL-sætning til en gyldig ODBC SQL-sætning. Dette er forskelligt fra mål-SQL-dialekten for backend (f.eks. SQL Server, Oracle, MySQL, PostgreSQL). ODBC SQL-grammatikken er beskrevet her. Du kan også se en liste over alle funktioner, der understøttes af ODBC-laget. Det er vigtigt at huske, at når vi bruger ODBC, oversætter vi faktisk ikke direkte fra Access SQL til datakildens oprindelige SQL-dialekt. I stedet oversætter vi Access SQL til ODBC SQL, som ODBC-driveren for den givne datakilde derefter vil oversætte til sin oprindelige dialekt. Hvis du kan forestille dig en japansktalende og fransktalende, som ikke taler hinandens sprog, men begge taler engelsk, er det dybest set, hvad der sker over ODBC-laget. En yderligere konsekvens er, at bare fordi ODBC-dialekten understøtter funktion X, betyder det ikke, at nogen af siderne understøtter det. Begge sider skal understøtte denne funktion X, for at den kan transporteres over ODBC-laget. Heldigvis er de fleste ODBC-drivere derude ret brede og gør et godt stykke arbejde med at dække de fleste funktioner. Hvis du skulle støde på en situation, hvor en funktion formodes at fungere, men ikke gør det, kan det betale sig at konsultere ODBC-driverens dokumentation for at bekræfte, at den er understøttet.
Aktivering af ODBC SQL-sporing
Den første ting at gøre, så vi kan kigge bag gardinerne, er at aktivere ODBC SQL-sporing. Selvom vi kan bruge SQL Server Profiler, er det meget nyttigt at se på, hvordan Access formaterer ODBC SQL. Det vil fungere med alle ODBC-datakilder og ikke kun SQL Server. Mere afgørende er, at dette lader os se, hvordan Access oversætter sine forespørgsler til ODBC på en mere direkte måde end SQL Server Profiler eller andre profileringsværktøjer på serversiden. Du behøver ingen særlige tilladelser for at bruge ODBC SQL-sporing, hvorimod server-side profileringsværktøjer kan kræve et højt tilladelsesniveau for at bruge. Aktivering af ODBC SQL-sporing er en registreringsindstilling, så vi kan konfigurere denne ved at gå til den relevante registreringsnøgle:
Jet-database eller Office-versioner før 2007
For 32-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC
Til 32-bit Jet-motor eller Office før 2007 på 64-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC
Bemærk:Der er ingen 64-bit version af den forældede Jet-motor.
Office 2007 til 2016 (MSI-installationer)
For 32-bit Office på 32-bit Windows eller 64-bit Office på 64-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
Til 32-bit Office på 64-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
(hvor X.Y svarer til den version af Office, du har installeret)
Office 2016 eller Office 365 (klik for at køre)
For 32-bit Office på 32-bit Windows eller 64-bit Office på 64-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Til 32-bit Office på 64-bit Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Find nøglen TraceSQLMode under nøglen og ændre værdien fra 0 til 1 .
Adgang skal genstartes, hvis den allerede er åben. Ellers skal du åbne den og køre nogle forespørgsler. En fil med navnet sqlout.txt oprettes i den aktuelle mappe. Det er typisk enten i den samme mappe som Access-filen ELLER i dokumentmappen. Alternativt kan du udføre VBA-funktionen CurDir for at bestemme den aktuelle mappe.
Jeg anbefaler at bruge Notepad++ eller en lignende teksteditor, som har evnen til at registrere, at den er blevet ændret. Det vil derefter bede om at genindlæse filen. Det giver dig mulighed for at se nye opdateringer, da Access udsender nye kommandoer til tekstfilen uden konstant genåbning. Når du aktiverer tekstfilen, vil Notepad++ vise en dialogboks:
Du kan derefter klikke Yes for at se de seneste ODBC SQL-kommandoer udstedt af Access. Fordi Access kan udstede flere ODBC SQL-kommandoer, kan loggen vokse hurtigt. Jeg finder det praktisk at komme til det punkt, hvor jeg vil spore noget (f.eks. ved at åbne en formular eller køre en forespørgsel), jeg skifter derefter til sqlout.txt , genindlæs den, vælg derefter alt, slet al teksten og gem derefter den nu tomme fil. På den måde kan jeg udføre den handling, jeg vil spore, og derefter kun se de relevante ODBC-kommandoer uden alle andre støj, der ikke har noget at gøre med den handling, der spores.
Her er en hurtig video til demonstration:
Konklusioner
Du har lært, hvordan du aktiverer ODBC-sporing og får vist output genereret af Access. Du kan se, at du kan indsamle output selv fra handlinger som blot at åbne en tabel eller køre en forespørgsel. Det giver dig indsigt i, hvilken slags SQL-forespørgsler Access rent faktisk sender til ODBC-datakilden.
Som du kan se, fanger ODBC SQL-sporing alle ODBC SQL-kommandoer udstedt af Access, selvom du ikke direkte udstedte det. Derfor kan du bruge det på ethvert tidspunkt, hvor du oplever opbremsninger for, hvor du ikke har en god forklaring. Antag som et eksempel, at du har en formular, der er langsom til at åbne, og du ikke er sikker på, at det er din VBA-kode i formularens Open eller Load hændelser eller registreringskilden, der er problemet. En strategi ville være at konfigurere Access-applikationen, så du er ved at åbne formularen, ryd sqlout.txt tekstfil og fortsæt derefter for at åbne formularen. Du kan derefter gennemgå de sporede ODBC SQL-sætninger og afgøre, om der er nogen, der kan forbedres.
Det er særligt værdifuldt, når du har at gøre med en kompleks formular eller rapport, der også indeholder underformularer/underrapporter eller indeholder kombinationsbokse eller listebokse, som udsender deres egne forespørgsler for at tilfredsstille egenskaben for rækkekilden.
I den næste artikel vil vi analysere outputtet, når vi gennemser poster.
Brug for hjælp til Microsoft Access? Kontakt vores team på 773-809-5456 eller e-mail os på [email protected].