Felsökning av lagrade procedurer (VB)

av Scott Mitchell

Ladda ned PDF

Med Visual Studio Professional- och Team System-utgåvor kan du ange brytpunkter och gå in på lagrade procedurer i SQL Server, vilket gör felsökning av lagrade procedurer lika enkelt som felsökning av programkod. Den här handledningen visar direkt felsökning av databasen och applikationsfelsökning av lagrade procedurer.

Inledning

Visual Studio ger en omfattande felsökningsupplevelse. Med några tangenttryckningar eller musklickningar kan du använda brytpunkter för att stoppa körningen av ett program och undersöka dess tillstånd och kontrollflöde. Tillsammans med felsökning av programkod har Visual Studio stöd för felsökning av lagrade procedurer inifrån SQL Server. Precis som brytpunkter kan anges i koden för en ASP.NET kod bakom-klassen eller Business Logic Layer-klassen, så kan även de placeras i lagrade procedurer.

I den här handledningen tittar vi på hur man går in i lagrade procedurer från Serverutforskaren i Visual Studio samt hur man anger brytpunkter som träffas när den lagrade proceduren anropas från den körande ASP.NET-applikationen.

Sql Server-felsökningskoncept

Microsoft SQL Server 2005 har utformats för att ge integrering med Common Language Runtime (CLR) som är den körning som används av alla .NET-sammansättningar. Därför stöder SQL Server 2005 hanterade databasobjekt. Det innebär att du kan skapa databasobjekt som lagrade procedurer och User-Defined Functions (UDF: er) som metoder i en Visual Basic-klass. Detta gör att dessa lagrade procedurer och UDF:er kan använda funktioner i .NET Framework och från dina egna anpassade klasser. Naturligtvis har SQL Server 2005 även stöd för T-SQL-databasobjekt.

SQL Server 2005 erbjuder felsökningsstöd för både T-SQL- och hanterade databasobjekt. Dessa objekt kan dock bara felsökas med Visual Studio 2005 Professional- och Team System-utgåvor. I den här självstudien undersöker vi felsökning av T-SQL-databasobjekt. I den efterföljande självstudien tittar vi på felsökning av hanterade databasobjekt.

Översikt över T-SQL- och CLR-felsökning i SQL Server 2005-blogginlägget från SQL Server 2005 CLR-integreringsteamet visar de tre sätten att felsöka SQL Server 2005-objekt från Visual Studio:

• Direct Database Debugging (DDD) – från Server Explorer kan vi gå in i valfritt T-SQL-databasobjekt, till exempel lagrade procedurer och UDF:er. Vi kommer att undersöka DDD i steg 1.
• Programfelsökning – vi kan ange brytpunkter i ett databasobjekt och sedan köra vårt ASP.NET program. När databasobjektet körs kommer brytpunkten att slås och kontrollen överförs till felsökningsprogrammet. Observera att med programfelsökning kan vi inte gå in i ett databasobjekt från programkoden. Vi måste uttryckligen ange brytpunkter i de lagrade procedurer eller UDF:er där vi vill att felsökningsprogrammet ska stoppas. Programfelsökningen granskas från och med steg 2.
• Felsökning från ett SQL Server-projekt – Utgåvor av Visual Studio Professional och Team Systems innehåller en SQL Server-projekttyp som ofta används för att skapa hanterade databasobjekt. Vi kommer att använda SQL Server Projects och felsöka deras innehåll i nästa handledning.

Visual Studio kan felsöka lagrade procedurer på lokala och fjärranslutna SQL Server-instanser. En lokal SQL Server-instans är en som är installerad på samma dator som Visual Studio. Om DEN SQL Server-databas som du använder inte finns på utvecklingsdatorn anses den vara en fjärrinstans. För dessa tutorials har vi använt lokala SQL Server-instanser. Felsökning av lagrade procedurer på en sql server-fjärrinstans kräver fler konfigurationssteg än vid felsökning av lagrade procedurer på en lokal instans.

Om du använder en lokal SQL Server-instans kan du börja med steg 1 och gå igenom den här självstudien till slutet. Om du använder en SQL Server-fjärrinstans måste du dock först se till att när du felsöker loggas du till utvecklingsdatorn med ett Windows-användarkonto som har en SQL Server-inloggning på fjärrinstansen. Dessutom måste både den här databasinloggningen och databasinloggningen som används för att ansluta till databasen från ASP.NET program som körs vara medlemmar i sysadmin rollen. Mer information om hur du konfigurerar Visual Studio och SQL Server för att felsöka en fjärrinstans finns i avsnittet Felsökning av T-SQL-databasobjekt på fjärrinstanser i slutet av den här självstudien.

Slutligen förstår du att felsökningsstöd för T-SQL-databasobjekt inte är lika funktionsrikt som felsökningsstöd för .NET-program. Till exempel stöds inte brytpunktsvillkor och filter, endast en delmängd av felsökningsfönstren är tillgängliga, du kan inte använda Redigera och Fortsätt, fönstret Omedelbar blir oanvändbart och så vidare. Mer information finns i Begränsningar för felsökningskommandon och funktioner .

Steg 1: Gå direkt in i en lagrad procedur

Visual Studio gör det enkelt att direkt felsöka ett databasobjekt. Låt oss titta på hur du använder funktionen DDD (Direct Database Debugging) för att gå in i den Products_SelectByCategoryID lagrade proceduren i Northwind-databasen. Som namnet antyder, returnerar Products_SelectByCategoryID produktinformation för en viss kategori; den skapades i handledningen "Använda befintliga lagrade procedurer för Typed DataSets TableAdapters". Börja med att gå till Server Explorer och expandera noden Northwind-databas. Öka sedan detaljnivån i mappen Lagrade procedurer, högerklicka på den Products_SelectByCategoryID lagrade proceduren och välj alternativet Steg till lagrad procedur på snabbmenyn. Detta startar felsökningsprogrammet.

Eftersom den Products_SelectByCategoryID lagrade proceduren förväntar sig en @CategoryID indataparameter uppmanas vi att ange det här värdet. Ange 1, som returnerar information om dryckerna.

@CategoryID Parameter" />

Bild 1: Använd värdet 1 för parametern @CategoryID

När du har angett värdet för parametern @CategoryID körs den lagrade proceduren. I stället för att köras till slutförande stoppar felsökningsprogrammet körningen av den första instruktionen. Observera den gula pilen i marginalen, som anger den aktuella platsen i den lagrade proceduren. Du kan visa och redigera parametervärden genom bevakningsfönstret eller genom att hovra över parameternamnet i den lagrade proceduren.

Bild 2: Felsökningsprogrammet har stoppats vid den första instruktionen i den lagrade proceduren (klicka för att visa bilden i full storlek)

Om du vill gå igenom den lagrade proceduren en instruktion i taget klickar du på knappen Steg över i verktygsfältet eller trycker på F10-tangenten. Den Products_SelectByCategoryID lagrade proceduren innehåller en enda SELECT instruktion, så om du trycker på F10 går du över den enda instruktionen och slutför körningen av den lagrade proceduren. När den lagrade proceduren har slutförts visas dess utdata i utdatafönstret och felsökningsprogrammet avslutas.

Steg 2: Konfigurera webbplatsen för programfelsökning

Det är praktiskt att felsöka en lagrad procedur direkt från Server Explorer, men i många scenarier är vi mer intresserade av att felsöka den lagrade proceduren när den anropas från vårt ASP.NET-program. Vi kan lägga till brytpunkter i en lagrad procedur inifrån Visual Studio och sedan börja felsöka ASP.NET-programmet. När en lagrad procedur med brytpunkter anropas från programmet stoppas körningen vid brytpunkten och vi kan visa och ändra parametervärdena för den lagrade proceduren och gå igenom dess instruktioner, precis som vi gjorde i steg 1.

Innan vi kan börja felsöka lagrade procedurer som anropas från programmet måste vi instruera ASP.NET webbprogrammet att integrera med SQL Server-felsökningsprogrammet. Börja med att högerklicka på webbplatsnamnet i Solution Explorer (ASPNET_Data_Tutorial_74_VB). Välj alternativet Egenskapssidor på snabbmenyn, välj alternativet Startalternativ till vänster och markera kryssrutan SQL Server i avsnittet Felsökningsprogram (se bild 3).

Bild 3: Markera kryssrutan FÖR SQL Server på programmets egenskapssidor (Klicka om du vill visa en bild i full storlek)

Dessutom måste vi uppdatera databasanslutningssträngen som används av programmet så att anslutningspoolen inaktiveras. När en anslutning till en databas stängs placeras motsvarande SqlConnection objekt i en pool med tillgängliga anslutningar. När du upprättar en anslutning till en databas kan ett tillgängligt anslutningsobjekt hämtas från den här poolen i stället för att behöva skapa och upprätta en ny anslutning. Den här pooleringen av anslutningsobjekt är en prestandaförbättring och aktiveras som standard. Men när vi felsöker vill vi inaktivera anslutningspoolning eftersom felsökningsinfrastrukturen inte återupprättas korrekt när man arbetar med en anslutning som togs från poolen.

Om du vill stänga av anslutningspoolning, uppdatera NORTHWNDConnectionString i Web.config så att den innehåller inställningen Pooling=false.

<connectionStrings>
    <add name="NORTHWNDConnectionString" connectionString=
        "Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\NORTHWND.MDF;
            Integrated Security=True;User Instance=True;Pooling=false"
        providerName="System.Data.SqlClient" />
</connectionStrings>

Nu har ASP.NET-programmet konfigurerats så att Visual Studio kan felsöka SQL Server-databasobjekt när det anropas via webbprogrammet. Allt som återstår nu är att lägga till en brytpunkt i en lagrad procedur och börja felsöka!

Steg 3: Lägga till en brytpunkt och felsökning

Öppna den Products_SelectByCategoryID lagrade proceduren och ange en brytpunkt i början av -instruktionen SELECT genom att klicka i marginalen på rätt plats eller genom att placera markören i början av instruktionen SELECT och trycka på F9. Som bild 4 visar visas brytpunkten som en röd cirkel i marginalen.

Bild 4: Ange en brytpunkt i den Products_SelectByCategoryID lagrade proceduren (Klicka om du vill visa en bild i full storlek)

För att ett SQL-databasobjekt ska kunna kopplas från ett klientprogram är det absolut nödvändigt att databasen konfigureras för att stödja programfelsökning. När du först anger en brytpunkt bör den här inställningen aktiveras automatiskt, men det är klokt att dubbelkolla. Högerklicka på NORTHWND.MDF noden i Serverutforskaren. Snabbmenyn bör innehålla ett markerat menyalternativ med namnet Programfelsökning .

Bild 5: Kontrollera att programmets felsökningsalternativ är aktiverat

Med brytpunktsuppsättningen och alternativet Programfelsökning aktiverat är vi redo att felsöka den lagrade proceduren när den anropas från ASP.NET-programmet. Starta felsökningsprogrammet genom att gå till felsökningsmenyn och välja Starta felsökning, genom att trycka på F5 eller genom att klicka på den gröna uppspelningsikonen i verktygsfältet. Detta startar felsökningsprogrammet och startar webbplatsen.

Den lagrade proceduren skapades i självstudiekursen "Använda befintliga lagrade procedurer för Typed DataSets TableAdapters". Dess motsvarande webbsida (~/AdvancedDAL/ExistingSprocs.aspx) innehåller en GridView som visar resultaten som returneras av den här lagrade proceduren. Besök den här sidan via webbläsaren. När du når sidan kommer brytpunkten i den Products_SelectByCategoryID lagrade proceduren att träffas och kontrollen returneras till Visual Studio. Precis som i steg 1 kan du gå igenom de lagrade procedurinstruktionerna och visa och ändra parametervärdena.

Bild 6: Sidan ExistingSprocs.aspx visar ursprungligen dryckerna (klicka om du vill visa en bild i full storlek)

Bild 7: Den lagrade procedurens brytpunkt har nåtts (Klicka om du vill visa en bild i full storlek)

Som visningsfönstret i bild 7 visar är värdet för parametern @CategoryID 1. Det beror på att sidan ExistingSprocs.aspx först visar produkter i kategorin drycker, som har värdet CategoryID 1. Välj en annan kategori i listrutan. Detta orsakar en postback och den lagrade proceduren Products_SelectByCategoryID exekveras på nytt. Brytpunkten nås igen, men den här gången visar parametervärdet det valda objektet från rullgardinslistan.

Bild 8: Välj en annan kategori i listan Drop-Down (Klicka om du vill visa en bild i full storlek)

@CategoryID återspeglar den kategori som valts från webbsidan" />

Bild 9: Parametern @CategoryID visar den kategori som valts från webbsidan (klicka om du vill visa en bild i full storlek)

Felsöka T-SQL Database-objekt på fjärrinstanser

Det är ganska enkelt att felsöka databasobjekt via Visual Studio när SQL Server-databasinstansen finns på samma dator som Visual Studio. Men om SQL Server och Visual Studio finns på olika datorer krävs en noggrann konfiguration för att få allt att fungera korrekt. Det finns två grundläggande uppgifter som vi står inför:

• Kontrollera att inloggningen som används för att ansluta till databasen via ADO.NET tillhör sysadmin rollen.
• Kontrollera att Windows-användarkontot som används av Visual Studio på utvecklingsdatorn är ett giltigt SQL Server-inloggningskonto som tillhör sysadmin rollen.

Det första steget är relativt enkelt. Identifiera först det användarkonto som används för att ansluta till databasen från ASP.NET-programmet och lägg sedan till inloggningskontot sysadmin i rollen från SQL Server Management Studio.

Den andra uppgiften kräver att Det Windows-användarkonto som du använder för att felsöka programmet är en giltig inloggning i fjärrdatabasen. Chansen är dock stor att Det Windows-konto som du loggade in på din arbetsstation med inte är en giltig inloggning på SQL Server. I stället för att lägga till ditt specifika inloggningskonto i SQL Server är ett bättre val att ange ett Windows-användarkonto som SQL Server-felsökningskonto. Om du sedan vill felsöka databasobjekten för en SQL Server-fjärrinstans kör du Visual Studio med autentiseringsuppgifterna för Windows-inloggningskontot.

Ett exempel bör hjälpa till att klargöra saker och ting. Anta att det finns ett Windows-konto med namnet SQLDebug i Windows-domänen. Det här kontot måste läggas till i SQL Server-fjärrinstansen som en giltig inloggning och som medlem i sysadmin rollen. För att sedan felsöka SQL Server-fjärrinstansen från Visual Studio skulle vi behöva köra Visual Studio som SQLDebug användare. Detta kan göras genom att logga ut från vår arbetsstation, logga in igen som SQLDebugoch sedan starta Visual Studio, men en enklare metod är att logga in på vår arbetsstation med våra egna autentiseringsuppgifter och sedan använda runas.exe för att starta Visual Studio som SQLDebug användare. runas.exe tillåter att ett visst program körs under sken av ett annat användarkonto. Om du vill starta Visual Studio som SQLDebugkan du ange följande instruktion på kommandoraden:

runas.exe /user:SQLDebug "%PROGRAMFILES%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe"

En mer detaljerad förklaring av den här processen finns i William R. Vaughnsliftarguide till Visual Studio och SQL Server, Seventh Edition.

Sammanfattning

Förutom att tillhandahålla felsökningsstöd för .NET-programkod tillhandahåller Visual Studio även en mängd olika felsökningsalternativ för SQL Server 2005. I den här självstudien har vi tittat på två av dessa alternativ: Direkt databasfelsökning och programfelsökning. Om du vill felsöka ett T-SQL-databasobjekt direkt letar du upp objektet via ServerUtforskaren och högerklickar på det och väljer Stega in. Detta startar felsökningsprogrammet och stoppar den första instruktionen i databasobjektet. Då kan du gå igenom objektsinstruktionerna och visa och ändra parametervärden. I steg 1 använde vi den här metoden för att gå in i den Products_SelectByCategoryID lagrade proceduren.

Programfelsökning gör att brytpunkter kan anges direkt i databasobjekten. När ett databasobjekt med brytpunkter anropas från ett klientprogram (till exempel ett ASP.NET webbprogram) stoppas programmet när felsökningsprogrammet tar över. Programfelsökning är användbart eftersom det tydligare visar vilken programåtgärd som gör att ett visst databasobjekt anropas. Det kräver dock lite mer konfiguration och konfiguration än direkt databasfelsökning.

Databasobjekt kan också felsökas genom SQL Server-projekt. Vi tittar på hur du använder SQL Server Projects och hur du använder dem för att skapa och felsöka hanterade databasobjekt i nästa självstudie.

Lycka till med programmerandet!

Om författaren

Scott Mitchell, författare till sju ASP/ASP.NET-böcker och grundare av 4GuysFromRolla.com, har arbetat med Microsofts webbtekniker sedan 1998. Scott arbetar som oberoende konsult, tränare och författare. Hans senaste bok är Sams Teach Yourself ASP.NET 2.0 på 24 timmar. Han kan nås på mitchell@4GuysFromRolla.com.