Detta är en serie artiklar i sex delar om ODBC-spårning för att hjälpa Access-utvecklare att felsöka och arbeta med Access när de utvecklar en applikation som använder ODBC-datakällor, vanligtvis men inte enbart SQL Server. Serien syftar till att visa hur man använder ODBC-spårning för att övervaka ODBC SQL-satser som Access problem i bakgrunden när man arbetar med objekt som frågor, formulär eller rapporter eller till och med när man kör VBA-kod mot DAO-objekt. Serien kommer också att visa hur Access formulerar ODBC SQL-satserna. Slutligen kommer serien att täcka hur man tolkar spårningen och identifierar potentiella problem. Artiklarna kommer att tryckas dagligen tills serien avslutas.
UPPDATERING: Lade till en registernyckel för 32-bitars C2R-installation på 64-bitars Windows. Tack, Jack MacDonald!
Hur många gånger har du hört "Jag vet inte varför, men att vicka på handtaget fungerar bara"? När jag får den typen av svar irriterar det mig eftersom det är så otillfredsställande. Jag skulle vara mycket orolig om min rörmokare sa till mig att han inte visste att en p-fälla är till för och fortsätter att hänvisa till det som "den där kurviga thingamijigen under diskbänken". På samma sätt borde mina kunder vara mycket oroliga om jag sa "Jag vet inte varför den frågan var långsam, så jag försökte några slumpmässiga saker och hey, jag hittade ett trick som fungerar. Jag vet dock inte varför." Det är möjligen en av de största banorna med mjukvaruutveckling - vi arbetar med ett komplext system som går ut på att vända mellan 0 och 1 mycket snabbt i en viss sekvens och förväntas veta varför det inte gjorde så istället för på det här sättet.
Jag tror att det är värt tiden och investeringen för utvecklaren som arbetar med Access och VBA för att verkligen få veta vad den gör, speciellt med en ODBC-backend. Vi har haft migreringsscenarier där vi kanske inte har tillgång till profileringsverktygen på serversidan av olika anledningar, men det borde inte vara en anledning att rycka på axlarna och bara slumpmässigt mosa knappar tills något fungerar. Ännu viktigare, att ha en gedigen förståelse för vad som händer under huven hjälper dig att bli mycket bättre på att förutsäga vilka prestandafixar du behöver för att tillämpa för ett givet scenario. Jag hävdar att även om allt du gjorde var att läsa serien och lära dig hur Access fungerar med ODBC-datakällor, kommer du att vara mycket bättre rustad helt enkelt för att du vet vad Access sannolikt kommer att göra.
För mer komplicerade scenarier kan spårning vanligtvis göra underverk för att avslöja varför saker och ting går så långsamt. Eftersom du kan spåra den på Access-sidan snarare på servern, kräver den inte förhöjda behörigheter utöver att ha tillgång till registernyckeln för att aktivera ODBC-spårning. Den extra bonusen är att detta fungerar för alla ODBC-datakällor, inte bara SQL Server, så om du har en klient som använder MySQL eller PostgreSQL som du inte vet något om, kommer ODBC-spårning fortfarande att hjälpa dig att identifiera potentiella problem som du sedan kan åtgärda direkt på Åtkomstsidan.
Serien kommer endast att fokusera på Access och DAO. Saker och ting kan vara annorlunda när vi använder ADO i VBA, men det är inte i räckvidden för närvarande eftersom när vi använder DAO kommer Access att göra flera saker för att tillfredsställa våra annars omöjliga förfrågningar. Ett bra exempel är en Access-fråga som refererar till en VBA-funktion. Du kan inte köra VBA-funktion på SQL Server, men Access klagar inte. Så vad händer egentligen bakom ridån? Vi kan upptäcka vad Access gör genom att spåra de ODBC SQL-kommandon som den utfärdar till ODBC-datakällorna.
Mycket information som presenteras i denna artikelserie är möjlig med hjälp av Microsofts gamla whitepaper om Jet &ODBC. Även om jag tror att informationen fortfarande är mycket fördelaktig, är den också ganska tät och kräver hög teknisk kompetens. Förhoppningen är att genom att gå igenom spårningsserien kommer det att hjälpa till att bli vettigt och presentera informationen på ett mer tillgängligt sätt.
Varför ska vi spåra ODBC? Hur kommer det att hjälpa mig?
Om du någonsin har upplevt något av dessa symtom:
Eller andra fel när du arbetar med en ODBC-länkad tabell, då är det fördelaktigt att förstå varför du får dessa meddelanden och hur du kan fixa dem. En vanlig fix som flera Access-utvecklare tillämpar är att antingen lägga till Requery eller försöka spara posterna. Även om det kan lösa några av problemen, är det inte ovanligt att se ett komplext åtkomstformulär som rikligt strös med Requery och flera överlappande händelsekedjor som prestationen börjar lida. Istället för att strö dem som om de vore magiskt nävdamm, borde vi vara mer kirurgiska när det gäller att lösa problem med applikationen.
Ett annat övertygande skäl är att kunna analysera varför en viss form A tar 10 sekunder att öppna men en liknande form B bara 2 sekunder att öppna. Istället för att ta dig tid att blanda runt för att hitta vad som gör att formulär A öppnas snabbare, kan du börja med att spåra och jämföra skillnaden och sedan fokusera på skillnaden för att hjälpa dig lösa problemen på ett mer direkt sätt.
Även om vi inte alltid kommer att spåra varje gång det uppstår prestandaproblem, är det av enormt värde att känna till vad Access borde göra. Så även om allt du har gjort är att läsa serien, förhoppningsvis kommer du att få en bättre uppfattning om hur du arbetar med Access snarare än mot.
Åtkomst till SQL- och ODBC SQL-dialekter
Innan vi går in på detaljerna måste vi inse att närhelst Access arbetar med en ODBC-datakälla måste den först översätta sin SQL-sats till en giltig ODBC SQL-sats. Detta skiljer sig från SQL-måldialekten för backend (t.ex. SQL Server, Oracle, MySQL, PostgreSQL). ODBC SQL-grammatiken beskrivs här. Du kan också se en lista över alla funktioner som stöds av ODBC-lagret. Det är viktigt att komma ihåg att när vi använder ODBC översätter vi faktiskt inte direkt från Access SQL till datakällans ursprungliga SQL-dialekt. Snarare översätter vi Access SQL till ODBC SQL som ODBC-drivrutinen för den givna datakällan sedan kommer att översätta till sin ursprungliga dialekt. Om du kan föreställa dig en japansktalande och fransktalande som inte talar en annans språk men båda talar engelska, är det i princip vad som händer över ODBC-lagret. En ytterligare konsekvens är att bara för att ODBC-dialekten stöder funktion X, betyder det inte att någon sida stöder den. Båda sidor måste stödja den funktionen X för att den ska vara portabel över ODBC-lagret. Lyckligtvis är de flesta ODBC-drivrutiner där ute ganska breda och gör ett bra jobb med att täcka de flesta funktionerna. Om du skulle stöta på en situation där en funktion är tänkt att fungera men inte gör det, kan det löna sig att konsultera ODBC-drivrutinens dokumentation för att verifiera att den stöds.
Aktivera ODBC SQL-spårning
Det första vi ska göra så att vi kan kika bakom gardinerna är att aktivera ODBC SQL-spårning. Även om vi kan använda SQL Server Profiler, är det mycket användbart att titta på hur Access formaterar ODBC SQL. Det kommer att fungera med alla ODBC-datakällor och inte bara SQL Server. Mer avgörande är att detta låter oss se hur Access översätter sina frågor till ODBC på ett mer direkt sätt än SQL Server Profiler eller andra profileringsverktyg på serversidan. Du behöver inga speciella behörigheter för att använda ODBC SQL-spårning, medan profileringsverktyg på serversidan kan kräva en hög nivå av behörighet att använda. Aktiveringen av ODBC SQL-spårning är en registerinställning så vi kan konfigurera detta genom att gå till lämplig registernyckel:
Jet-databas eller Office-versioner före 2007
För 32-bitars Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC
För 32-bitars Jet-motor eller Office före 2007 på 64-bitars Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC
Obs! Det finns ingen 64-bitarsversion av den föråldrade Jet-motorn.
Office 2007 till 2016 (MSI-installationer)
För 32-bitars Office på 32-bitars Windows eller 64-bitars Office på 64-bitars Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
För 32-bitars Office på 64-bitars Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC
(där X.Y motsvarar den version av Office du har installerat)
Office 2016 eller Office 365 (klicka för att köra)
För 32-bitars Office på 32-bitars Windows eller 64-bitars Office på 64-bitars Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
För 32-bitars Office på 64-bitars Windows:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC
Leta reda på nyckeln TraceSQLMode under nyckeln och ändra värdet från 0 till 1 .
Åtkomst måste startas om om den redan är öppen. Annars öppnar du den och kör några frågor. En fil med namnet sqlout.txt kommer att skapas i den aktuella katalogen. Det är vanligtvis antingen i samma mapp som Access-filen ELLER i dokumentmappen. Alternativt kan du köra VBA-funktionen CurDir för att fastställa den aktuella katalogen.
Jag rekommenderar att du använder Notepad++ eller en liknande textredigerare som har förmågan att upptäcka att den har ändrats. Det kommer då att uppmanas att ladda om filen. Det gör att du kan se nya uppdateringar när Access skickar nya kommandon till textfilen utan att ständigt öppnas igen. När du aktiverar textfilen visar Notepad++ en dialogruta:
Du kan sedan klicka på Yes för att se de senaste ODBC SQL-kommandona utfärdade av Access. Eftersom Access kan utfärda flera ODBC SQL-kommandon kan loggen växa snabbt. Jag tycker att det är bekvämt att komma till den punkt där jag vill spåra något (t.ex. ska öppna ett formulär eller köra en fråga), jag byter sedan till sqlout.txt , ladda om den, välj sedan allt, ta bort all text och spara sedan den nu tomma filen. På så sätt kan jag utföra åtgärden jag vill spåra, och sedan bara se relevanta ODBC-kommandon utan alla andra ljud som inte har något att göra med åtgärden som spåras.
Här är en snabb video att demonstrera:
Slutsatser
Du har lärt dig hur du aktiverar ODBC-spårning och visar utdata som genereras av Access. Du kan se att du kan samla in utdata även från åtgärder som att helt enkelt öppna en tabell eller köra en fråga. Det ger dig insikter i vilken typ av SQL-frågor Access faktiskt skickar till ODBC-datakällan.
Som du kan se fångar ODBC SQL-spårning alla ODBC SQL-kommandon som utfärdas av Access även om du inte utfärdade det direkt. Därför kan du använda den när som helst där du upplever avmattningar där du inte har en bra förklaring. Anta som ett exempel att du har ett formulär som är långsamt att öppna och att du inte är säker på att det är din VBA-kod i formulärets Open eller Load händelser eller postkällan som är problemet. En strategi skulle vara att ställa in Access-applikationen så att du är på väg att öppna det formuläret, rensa sqlout.txt textfil och fortsätt sedan för att öppna formuläret. Du kan sedan granska de spårade ODBC SQL-satserna och avgöra om det finns några som kan förbättras.
Det är särskilt värdefullt när du har att göra med ett komplext formulär eller rapport som också innehåller underformulär/underrapporter eller innehåller kombinationsrutor eller listrutor som utfärdar sina egna frågor för att tillfredsställa rowsource-egenskapen.
I nästa artikel kommer vi att analysera resultatet när vi bläddrar igenom poster.
Behöver du hjälp med Microsoft Access? Kontakta vårt team på 773-809-5456 eller maila oss på [email protected].