Tárolt eljárások hibakeresése (C#)

által Scott Mitchell

PDF letöltése

A Visual Studio Professional és a Team System kiadásai lehetővé teszik töréspontok beállítását és a tárolt eljárásokba való lépését az SQL Serveren belül, így a tárolt eljárások hibakeresése olyan egyszerű, mint az alkalmazáskód hibakeresése. Ez az oktatóanyag bemutatja a tárolt eljárások közvetlen adatbázis-hibakeresését és alkalmazáskeresését.

Bevezetés

A Visual Studio gazdag hibakeresési élményt nyújt. Az egér néhány billentyűleütésével vagy kattintásával töréspontok használatával leállíthatja a program végrehajtását, és megvizsgálhatja annak állapotát és vezérlési folyamatát. Az alkalmazáskód hibakeresése mellett a Visual Studio támogatja a tárolt eljárások hibakeresését az SQL Serveren belül. Ahogyan a töréspontok is beállíthatók egy ASP.NET kód mögötti osztály vagy üzleti logikai réteg osztály kódjába, úgy a tárolt eljárásokban is elhelyezhetők.

Ebben az oktatóanyagban áttekintjük, hogyan lépünk be a Visual Studióban található Kiszolgálókezelőből származó tárolt eljárásokba, és hogyan állíthatjuk be azokat a töréspontokat, amelyek akkor lépnek érvénybe, amikor a tárolt eljárást meghívják a futó ASP.NET alkalmazásból.

Megjegyzés:

Sajnos a tárolt eljárásokat csak a Visual Studio Professional és Team System verzióiban lehet lépésről lépésre követni és hibakeresést végezni. Ha a Visual Web Developert vagy a Visual Studio standard verzióját használja, örömmel olvassa el a tárolt eljárások hibakereséséhez szükséges lépéseket, de ezeket a lépéseket nem tudja replikálni a gépére.

Az SQL Server hibakeresési fogalmai

A Microsoft SQL Server 2005 úgy lett kialakítva, hogy integrációt biztosítson a Common Language Runtime (CLR) alkalmazással, amely az összes .NET-szerelvény által használt futtatókörnyezet. Ezért az SQL Server 2005 támogatja a felügyelt adatbázis-objektumokat. Vagyis létrehozhat adatbázis-objektumokat, például tárolt eljárásokat és User-Defined Függvényeket (UDF-eket) egy C#-osztály metódusaként. Ez lehetővé teszi, hogy ezek a tárolt eljárások és UDF-ek a .NET-keretrendszerben és a saját egyéni osztályaikban használják a funkciókat. Az SQL Server 2005 természetesen támogatja a T-SQL-adatbázisobjektumokat is.

Az SQL Server 2005 hibakeresési támogatást nyújt mind a T-SQL, mind a felügyelt adatbázis-objektumok számára. Ezeket az objektumokat azonban csak a Visual Studio 2005 Professional és Team Systems kiadásokban lehet hibakeresésre. Ebben az oktatóanyagban megvizsgáljuk a T-SQL-adatbázisobjektumok hibakeresését. A következő oktatóanyag a felügyelt adatbázis-objektumok hibakeresését mutatja be.

A SQL Server 2005 T-SQL és CLR hibakeresés áttekintése blogbejegyzés a SQL Server 2005 CLR integrációs csapatából kiemeli az SQL Server 2005-objektumok Visual Studióból való hibakeresésének három módját:

• Közvetlen adatbázis-hibakeresés (DDD) – a Kiszolgálókezelőből bármilyen T-SQL-adatbázis-objektumba léphetünk, például tárolt eljárásokba és UDF-ekhez. Az 1. lépésben vizsgáljuk meg a DDD-t.
• Alkalmazás hibakeresése – beállíthatunk töréspontokat egy adatbázis-objektumon belül, majd futtathatjuk a ASP.NET alkalmazást. Az adatbázis-objektum végrehajtásakor a töréspont le lesz ütve, és a vezérlő át lesz kapcsolva a hibakeresőnek. Vegye figyelembe, hogy az alkalmazás hibakeresésével nem léphetünk be adatbázis-objektumba az alkalmazáskódból. Explicit módon be kell állítanunk töréspontokat azokban a tárolt eljárásokban vagy UDF-ekben, ahol a hibakeresőt le szeretnénk állítani. Az alkalmazás hibakeresését a 2. lépéstől kezdve vizsgáljuk meg.
• Hibakeresés egy SQL Server projektről – A Visual Studio Professional és a Team Systems kiadások tartalmazzák az SQL Server projekt típust, amelyet gyakran használnak felügyelt adatbázis-objektumok létrehozásához. A következő oktatóanyagban megvizsgáljuk az SQL Server-projektek használatát és a tartalom hibakeresését.

A Visual Studio képes a helyi és távoli SQL Server-példányokon tárolt eljárások hibakeresésére. A helyi SQL Server-példány egy olyan példány, amely ugyanazon a gépen van telepítve, mint a Visual Studio. Ha a használt SQL Server-adatbázis nem található a fejlesztői gépen, akkor távoli példánynak számít. Ezekben az oktatóanyagokban helyi SQL Server-példányokat használtunk. A távoli SQL Server-példányon tárolt eljárások hibakereséséhez több konfigurációs lépésre van szükség, mint a helyi példányon tárolt eljárások hibakereséséhez.

Ha helyi SQL Server-példányt használ, az 1. lépéssel kezdheti, és végigvezetheti ezt az oktatóanyagot a végéig. Ha távoli SQL Server-példányt használ, először meg kell győződnie arról, hogy a hibakeresés során a fejlesztői gépen olyan Windows-felhasználói fiókkal van bejelentkezve, amely SQL Server-bejelentkezéssel rendelkezik a távoli példányon. Ezen kívül ennek az adatbázis-bejelentkezésnek és a futó ASP.NET alkalmazásból az adatbázishoz való csatlakozáshoz használt adatbázis-bejelentkezésnek is tagja kell lennie a sysadmin szerepkörnek. A távoli példányok hibakereséséhez a Visual Studio és az SQL Server konfigurálásával kapcsolatos további információkért tekintse meg az oktatóanyag végén a T-SQL Database-objektumok hibakeresését a távoli példányokon.

Végül pedig ismerje meg, hogy a T-SQL-adatbázisobjektumok hibakeresési támogatása nem olyan funkciógazdag, mint a .NET-alkalmazások hibakeresési támogatása. A töréspontok feltételei és szűrői például nem támogatottak, csak a hibakeresési ablakok egy részhalmaza érhető el, a Szerkesztés és a Folytatás nem használható, az Azonnali ablak használhatatlanná válik, és így tovább. További információkért tekintse meg a hibakereső parancsokra és szolgáltatásokra vonatkozó korlátozásokat .

1. lépés: Közvetlen lépés egy tárolt eljárásba

A Visual Studio megkönnyíti az adatbázis-objektumok közvetlen hibakeresését. Nézzük meg, hogyan használhatja a Direct Database Debugging (DDD) funkciót a Products_SelectByCategoryID Northwind-adatbázisban tárolt eljárásba való lépéshez. Ahogy a neve is mutatja, Products_SelectByCategoryID egy adott kategóriára vonatkozó termékinformációkat ad vissza; azokat a Typed DataSet TableAdapters oktatóanyag Meglévő tárolt eljárások használata című oktatóanyagában hozták létre. Először nyissa meg a Kiszolgálókezelőt, és bontsa ki a Northwind adatbáziscsomópontot. Ezután bontsa ki a Tárolt eljárások mappát, kattintson a jobb gombbal a Products_SelectByCategoryID tárolt eljárásra, és válassza a helyi menüben a 'Lépjen be a tárolt eljárásba' lehetőséget. Ezzel elindítja a hibakeresőt.

Mivel a Products_SelectByCategoryID tárolt eljárás bemeneti paramétert @CategoryID vár, a rendszer kéri, hogy adja meg ezt az értéket. Adja meg az 1 értéket, amely adatokat ad vissza az italokról.

@CategoryID paraméter" />

1. ábra: Az 1. érték használata a @CategoryID paraméterhez

A paraméter értékének @CategoryID megadása után a rendszer végrehajtja a tárolt eljárást. Ahelyett, hogy a befejezésig futna, a hibakereső leállítja a végrehajtást az első utasításnál. Figyelje meg a margó sárga nyílát, amely a tárolt eljárás aktuális helyét jelzi. A paraméterértékeket a Figyelő ablakban vagy a tárolt eljárásban a paraméter nevére mutatva tekintheti meg és szerkesztheti.

2. ábra: A hibakereső leállt a tárolt eljárás első utasításában (kattintson ide a teljes méretű kép megtekintéséhez)

Ha egyszerre egy utasítással szeretné végigvezetni a tárolt eljárást, kattintson az Eszköztár Lépésátvétel gombjára, vagy nyomja le az F10 billentyűt. A Products_SelectByCategoryID tárolt eljárás egyetlen SELECT utasítást tartalmaz, így az F10-sel lép át az egyetlen utasításon, és végrehajtja a tárolt eljárást. A tárolt eljárás befejeződése után a kimenete megjelenik a Kimeneti ablakban, és a hibakereső leáll.

Megjegyzés:

A T-SQL hibakeresése az utasítás szintjén történik; nem léphet be egy SELECT utasításba.

2. lépés: A webhely konfigurálása az alkalmazások hibakereséséhez

Bár a tárolt eljárásokat közvetlenül a Kiszolgálókezelőből lehet hibakeresésre használni, sok esetben jobban érdekli a tárolt eljárás hibakeresése, amikor az ASP.NET-alkalmazásból van meghívva. A Visual Studióban töréspontokat adhatunk egy tárolt eljáráshoz, majd elkezdhetjük a ASP.NET alkalmazás hibakeresését. Amikor az alkalmazás meghív egy töréspontokkal rendelkező tárolt eljárást, a végrehajtás leáll a töréspontnál, és megtekintheti és módosíthatja a tárolt eljárás paraméterértékeit, és végiglépkedhet az utasításokon, ahogyan az 1. lépésben is.

Mielőtt elkezdhetnénk az alkalmazásból meghívott tárolt eljárások hibakeresését, meg kell utasítanunk a ASP.NET webalkalmazást, hogy integráljon az SQL Server hibakeresőjével. Először kattintson a jobb gombbal a webhely nevére a Megoldáskezelőben (ASPNET_Data_Tutorial_74_CS). Válassza a Tulajdonságlapok lehetőséget a helyi menüben, válassza a bal oldali Start Beállítások elemet, és jelölje be az SQL Server jelölőnégyzetét a Hibakeresők szakaszban (lásd a 3. ábrát).

3. ábra: Jelölje be az SQL Server jelölőnégyzetét az alkalmazás tulajdonságlapjain (kattintson ide a teljes méretű kép megtekintéséhez)

Emellett frissíteni kell az alkalmazás által használt adatbázis-kapcsolati sztringet, hogy a kapcsolat pooling ki legyen kapcsolva. Ha egy adatbázishoz való kapcsolat lezárul, a megfelelő SqlConnection objektum egy elérhető kapcsolatok készletébe kerül. Adatbázis-kapcsolat létrehozásakor egy elérhető kapcsolati objektum lekérhető ebből a készletből ahelyett, hogy új kapcsolatot kellene létrehoznia és létrehoznia. A kapcsolatobjektumok készletezése teljesítménybeli fejlesztés, és alapértelmezés szerint engedélyezve van. Azonban hibakeresés során ki szeretnénk kapcsolni a kapcsolatkészlet-kezelést, mivel a hibakeresési infrastruktúra nem áll helyre megfelelően, amikor egy készletből vett kapcsolatot használunk.

Ha le szeretné tiltani a kapcsolatkészletezést, frissítse a NORTHWNDConnectionString paramétert Web.config tartalmazza a Pooling=false beállítást.

<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>

Megjegyzés:

Ha befejezte az SQL Server hibakeresését az ASP.NET alkalmazáson keresztül, mindenképpen állítsa vissza a kapcsolatcsoportosítást a Pooling beállítás eltávolításával a kapcsolati sztringből (vagy a Pooling=true értékre állítással).

Ezen a ponton a ASP.NET alkalmazás úgy lett konfigurálva, hogy lehetővé tegye a Visual Studio számára az SQL Server-adatbázisobjektumok hibakeresését a webalkalmazáson keresztüli meghíváskor. Most már csak az marad, hogy töréspontot ad hozzá egy tárolt eljáráshoz, és elkezdi a hibakeresést!

3. lépés: Töréspont hozzáadása és hibakeresés

Nyissa meg a Products_SelectByCategoryID tárolt eljárást, és állítson be egy töréspontot az SELECT utasítás elején. Ehhez kattintson a margóra a megfelelő helyen, vagy helyezze a kurzort az utasítás elejére, és nyomja le az SELECT F9 billentyűt. Ahogy a 4. ábra szemlélteti, a töréspont piros körként jelenik meg a margón.

4. ábra: Töréspont beállítása a Products_SelectByCategoryID tárolt eljárásban (kattintson ide a teljes méretű kép megtekintéséhez)

Ahhoz, hogy egy SQL-adatbázis-objektumot egy ügyfélalkalmazáson keresztül lehessen hibakeresésre beállítani, elengedhetetlen, hogy az adatbázis az alkalmazás hibakeresésének támogatására legyen konfigurálva. Amikor először állít be töréspontot, ezt a beállítást automatikusan be kell kapcsolni, de érdemes duplán ellenőrizni. Kattintson a jobb gombbal a NORTHWND.MDF csomópontra a Kiszolgálókezelőben. A helyi menünek tartalmaznia kell egy Alkalmazás hibakeresése nevű, bejelölt menüelemet.

5. ábra: Győződjön meg arról, hogy az alkalmazás hibakeresési lehetősége engedélyezve van

Ha engedélyezve van a töréspontkészlet és az Alkalmazás hibakeresése lehetőség, készen állunk a tárolt eljárás hibakeresésére, amikor az ASP.NET alkalmazásból hívjuk. Indítsa el a hibakeresőt a Hibakeresés menüben, és válassza a Hibakeresés indítása lehetőséget, nyomja le az F5 billentyűt, vagy kattintson az eszköztár zöld lejátszási ikonra. Ezzel elindítja a hibakeresőt, és elindítja a webhelyet.

A Products_SelectByCategoryID tárolt eljárás a "Meglévő tárolt eljárások használata a Typed DataSet-ek TableAdaptereivel" című oktatóanyag során jött létre. A megfelelő weblap (~/AdvancedDAL/ExistingSprocs.aspx) tartalmaz egy GridView-t, amely megjeleníti a tárolt eljárás által visszaadott eredményeket. Látogasson el erre a lapra a böngészőben. Az oldal elérésekor a tárolt eljárásban a töréspont Products_SelectByCategoryID aktiválódik, és az irányítás visszakerül a Visual Studióba. Az 1. lépéshez hasonlóan végiglépkedhet a tárolt eljárás utasításain, és megtekintheti és módosíthatja a paraméterértékeket.

6. ábra: A ExistingSprocs.aspx lap kezdetben megjeleníti az italokat (kattintson ide a teljes méretű kép megtekintéséhez)

7. ábra: Elérte a tárolt eljárás töréspontját (kattintson ide a teljes méretű kép megtekintéséhez)

Ahogy a 7. ábrán látható Figyelő ablak mutatja, a @CategoryID paraméter értéke 1. Ennek az az oka, hogy az ExistingSprocs.aspx oldal kezdetben az italok kategóriájában jeleníti meg a termékeket, amelynek CategoryID értéke 1. Válasszon másik kategóriát a legördülő listából. Ha ezt teszi, visszahívást okoz, és újra végrehajtja a Products_SelectByCategoryID tárolt eljárást. A töréspont ismét megjelenik, de ezúttal a @CategoryID paraméter értéke a kijelölt legördülő listaelem s CategoryIDértékét tükrözi.

8. ábra: Válasszon egy másik kategóriát a Drop-Down listából (kattintson ide a teljes méretű kép megtekintéséhez)

@CategoryID Paraméter a weblapról kiválasztott kategóriát tükrözi" />

9. ábra: A @CategoryID paraméter a weblapról kiválasztott kategóriát tükrözi (kattintson ide a teljes méretű kép megtekintéséhez)

Megjegyzés:

Ha a Products_SelectByCategoryID tárolt eljárás töréspontja nem jelenik meg a ExistingSprocs.aspx lap megnyitásakor, győződjön meg arról, hogy az SQL Server jelölőnégyzete be van jelölve a ASP.NET alkalmazás tulajdonságai lap hibakeresők szakaszában, hogy a kapcsolatkészletezés le lett tiltva, és hogy engedélyezve van az adatbázis alkalmazás-hibakeresési lehetősége. Ha továbbra is problémákat tapasztal, indítsa újra a Visual Studiót, és próbálkozzon újra.

T-SQL Database-objektumok hibakeresése távoli példányokon

Az adatbázis-objektumok Visual Studióban történő hibakeresése meglehetősen egyszerű, ha az SQL Server-adatbázispéldány ugyanazon a gépen található, mint a Visual Studio. Ha azonban az SQL Server és a Visual Studio különböző gépeken található, akkor gondos konfigurációra van szükség ahhoz, hogy minden megfelelően működjön. Két alapvető feladattal szembesülünk:

• Győződjön meg arról, hogy az adatbázishoz ADO.NET keresztüli csatlakozáshoz használt bejelentkezés a sysadmin szerepkörhöz tartozik.
• Győződjön meg arról, hogy a Visual Studio által a fejlesztői gépen használt Windows-felhasználói fiók egy érvényes SQL Server-bejelentkezési fiók, amely a sysadmin szerepkörhöz tartozik.

Az első lépés viszonylag egyszerű. Először azonosítsa az adatbázishoz való csatlakozáshoz használt felhasználói fiókot az ASP.NET alkalmazásból, majd az SQL Server Management Studióból adja hozzá a bejelentkezési fiókot a sysadmin szerepkörhöz.

A második feladathoz az alkalmazás hibakereséséhez használt Windows-felhasználói fióknak érvényes bejelentkezésnek kell lennie a távoli adatbázisban. Valószínű azonban, hogy a munkaállomásra bejelentkezett Windows-fiók nem érvényes bejelentkezés az SQL Serveren. Ahelyett, hogy hozzáadná az adott bejelentkezési fiókját az SQL Serverhez, jobb választás lenne, ha egy Windows-felhasználói fiókot jelölne ki SQL Server hibakeresési fiókként. Ezután egy távoli SQL Server-példány adatbázis-objektumainak hibakereséséhez futtassa a Visual Studiót a Windows bejelentkezési fiók hitelesítő adataival.

Egy példa segíthet tisztázni a dolgokat. Tegyük fel, hogy a Windows-tartományon belül van egy Windows-fiók.SQLDebug Ezt a fiókot érvényes bejelentkezésként és a szerepkör tagjaként kell hozzáadni a sysadmin távoli SQL Server-példányhoz. Ezután a Távoli SQL Server-példány Visual Studio-ból történő hibakereséséhez az SQLDebug felhasználóként kell futtatnunk a Visual Studio-t. Ezt úgy teheti meg, hogy kijelentkezik a munkaállomásunkról, bejelentkezik SQLDebug, majd elindítja a Visual Studiót, de egyszerűbb megoldás, ha a saját hitelesítő adatainkkal jelentkezik be a munkaállomásra, majd runas.exe felhasználóként elindítja a SQLDebug Visual Studiót. runas.exe lehetővé teszi egy adott alkalmazás végrehajtását egy másik felhasználói fiók leple alatt. A Visual Studio SQLDebug elindításához írja be a következő parancsot a parancssorba:

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

A folyamat részletesebb ismertetését William R. VaughnHitchhiker-útmutatója a Visual Studióhoz és az SQL Server hetedik kiadásához című témakörben találja.

Megjegyzés:

Ha a fejlesztőgép a Windows XP Service Pack 2 rendszert futtatja, konfigurálnia kell az internetkapcsolat tűzfalát a távoli hibakeresés engedélyezéséhez. Az SQL Server 2005 hibakeresésének engedélyezése című cikk megjegyzi, hogy ez két lépésből áll: (a) A Visual Studio gazdagépén fel kell vennie Devenv.exe a kivétellistát, és meg kell nyitnia a TCP 135-portot, és (b) A távoli (SQL) gépen meg kell nyitnia a TCP 135-portot, és fel kell vennie sqlservr.exe a kivételek listájára. Ha a tartományi szabályzat megköveteli a hálózati kommunikációt az IPSec-ben, meg kell nyitnia az UDP 4500 és UDP 500 portokat.

Összefoglalás

A .NET-alkalmazáskód hibakeresési támogatása mellett a Visual Studio számos hibakeresési lehetőséget is kínál az SQL Server 2005-höz. Ebben az oktatóanyagban két lehetőséget vizsgáltunk meg: a Közvetlen adatbázis hibakeresését és az alkalmazások hibakeresését. Egy T-SQL-adatbázisobjektum közvetlen hibakereséséhez keresse meg az objektumot a Kiszolgálókezelőben, majd kattintson rá a jobb gombbal, és válassza a Lépés be lépése lehetőséget. Ez elindítja a hibakeresőt, és leáll az adatbázis-objektum első utasításán, ekkor végiglépkedhet az objektum utasításain, és megtekintheti és módosíthatja a paraméterértékeket. Az 1. lépésben ezt a megközelítést használtuk a Products_SelectByCategoryID tárolt eljárásba való lépéshez.

Az alkalmazás hibakeresésével a töréspontok közvetlenül az adatbázis-objektumokon belül állíthatók be. Ha egy ügyfélalkalmazásból (például egy ASP.NET webalkalmazásból) meghív egy töréspontokat tartalmazó adatbázis-objektumot, a program leáll, amint a hibakereső átveszi a feladatátvételt. Az alkalmazás hibakeresése azért hasznos, mert egyértelműbben mutatja meg, hogy egy adott adatbázis-objektumot milyen alkalmazásművelet indít el. Azonban egy kicsit több konfigurációt és beállítást igényel, mint a Közvetlen adatbázis hibakeresése.

Az adatbázis-objektumok az SQL Server-projekteken keresztül is hibakeresést végezhetnek. A következő oktatóanyagban áttekintjük, hogyan használhatja az SQL Server-projekteket felügyelt adatbázis-objektumok létrehozására és hibakeresésére.

Boldog programozást!

Tudnivalók a szerzőről

Scott Mitchell, hét ASP/ASP.NET-könyv szerzője és a 4GuysFromRolla.com alapítója, 1998 óta dolgozik a Microsoft webtechnológiáival. Scott független tanácsadóként, edzőként és íróként dolgozik. Legújabb könyve a Sams Teach Yourself ASP.NET 2.0 24 óra alatt. Itt érhető el mitchell@4GuysFromRolla.com.

Előzőkövetkező