Debugowanie procedur składowanych (VB)

Autor : Scott Mitchell

Pobierz plik PDF

Wersje Visual Studio Professional i Team System umożliwiają ustawianie punktów przerwania i przechodzenie do procedur składowanych w programie SQL Server, dzięki czemu debugowanie procedur składowanych jest tak proste, jak debugowanie kodu aplikacji. W tym samouczku przedstawiono bezpośrednie debugowanie bazy danych i debugowanie aplikacji procedur składowanych.

Wprowadzenie

Program Visual Studio zapewnia zaawansowane środowisko debugowania. Za pomocą kilku naciśnięć lub kliknięć myszy można użyć punktów przerwania, aby zatrzymać wykonywanie programu i zbadać jego stan i przepływ sterowania. Oprócz debugowania kodu aplikacji program Visual Studio oferuje obsługę debugowania procedur składowanych z poziomu programu SQL Server. Podobnie jak punkty przerwania można ustawić w kodzie w klasie ASP.NET code-behind lub w klasie warstwy logiki biznesowej, tak samo można je umieścić w procedurach składowanych.

W tym samouczku przyjrzymy się, jak przechodzić do procedur składowanych z poziomu Eksploratora serwera w programie Visual Studio oraz jak ustawiać punkty przerwania, które zostaną aktywowane po wywołaniu procedury składowanej z uruchomionej aplikacji ASP.NET.

Uwaga / Notatka

Niestety procedury składowane można wprowadzać i debugować tylko za pośrednictwem wersji Professional and Team Systems programu Visual Studio. Jeśli używasz programu Visual Web Developer lub standardowej wersji programu Visual Studio, zachęcamy do zapoznania się z instrukcjami niezbędnymi do debugowania procedur składowanych, ale nie będzie można replikować tych kroków na maszynie.

Pojęcia dotyczące debugowania programu SQL Server

Program Microsoft SQL Server 2005 został zaprojektowany w celu zapewnienia integracji ze środowiskiem Uruchomieniowym języka wspólnego (CLR), który jest środowiskiem uruchomieniowym używanym przez wszystkie zestawy platformy .NET. W związku z tym program SQL Server 2005 obsługuje zarządzane obiekty bazy danych. Oznacza to, że można tworzyć obiekty bazy danych, takie jak procedury składowane i funkcje User-Defined (UDF) jako metody w klasie Visual Basic. Dzięki temu te procedury składowane i funkcje zdefiniowane przez użytkownika mogą korzystać z funkcji dostępnych w ramach .NET Framework oraz z niestandardowych klas utworzonych przez użytkownika. Oczywiście program SQL Server 2005 zapewnia również obsługę obiektów bazy danych T-SQL.

Program SQL Server 2005 oferuje obsługę debugowania zarówno dla obiektów T-SQL, jak i zarządzanych baz danych. Te obiekty można jednak debugować tylko za pośrednictwem wersji Visual Studio 2005 Professional i Team Systems. W tym samouczku przeanalizujemy debugowanie obiektów bazy danych T-SQL. W kolejnym samouczku omówiono debugowanie zarządzanych obiektów bazy danych.

Wpis w blogu Omówienie debugowania T-SQL i CLR w programie SQL Server 2005 z zespołu integracji środowiska CLR programu SQL Server 2005 wyróżnia trzy sposoby debugowania obiektów programu SQL Server 2005 z poziomu programu Visual Studio:

• Bezpośrednie debugowanie bazy danych (DDD) — w Eksploratorze serwera możemy śledzić działanie dowolnego obiektu bazy danych T-SQL, takiego jak procedury składowane i funkcje zdefiniowane przez użytkownika (UDF). Przeanalizujemy DDD w kroku 1.
• Debugowanie aplikacji — możemy ustawić punkty przerwania w obiekcie bazy danych, a następnie uruchomić naszą aplikację ASP.NET. Po uruchomieniu obiektu bazy danych punkt przerwania zostanie aktywowany, a kontrola zostanie przekazana do debugera. Pamiętaj, że w przypadku debugowania aplikacji nie możemy przejść do obiektu bazy danych z kodu aplikacji. Musimy jawnie ustawić punkty przerwania w tych procedurach składowanych lub funkcjach zdefiniowanych przez użytkownika, w których chcemy zatrzymać debuger. Debugowanie aplikacji jest badane, począwszy od kroku 2.
• Debugowanie z programu SQL Server Project — wersje Visual Studio Professional i Team Systems obejmują typ projektu programu SQL Server, który jest często używany do tworzenia zarządzanych obiektów bazy danych. W następnym samouczku przeanalizujemy użycie projektów programu SQL Server i debugujemy ich zawartość.

Program Visual Studio może debugować procedury składowane w lokalnych i zdalnych wystąpieniach programu SQL Server. Lokalna instancja SQL Server to taka, która jest zainstalowana na tej samej maszynie co program Visual Studio. Jeśli używana baza danych programu SQL Server nie znajduje się na maszynie dewelopera, jest ona uznawana za wystąpienie zdalne. W przypadku tych samouczków używaliśmy lokalnych wystąpień programu SQL Server. Debugowanie procedur składowanych w zdalnym wystąpieniu programu SQL Server wymaga więcej kroków konfiguracji niż podczas debugowania procedur składowanych w wystąpieniu lokalnym.

Jeśli używasz lokalnej instancji SQL Server, możesz zacząć od kroku 1 i przejść przez ten samouczek od początku do końca. Jeśli jednak używasz zdalnego wystąpienia programu SQL Server, najpierw musisz upewnić się, że podczas debugowania jesteś zalogowany na stacji roboczej deweloperskiej przy użyciu konta użytkownika systemu Windows, które ma login SQL Server na zdalnym wystąpieniu. Ponadto, zarówno ten login bazy danych, jak i login bazy danych używany do łączenia się z bazą danych z działającej aplikacji ASP.NET, muszą należeć do roli sysadmin. Zobacz sekcję Debugowanie obiektów T-SQL Database w wystąpieniach zdalnych na końcu tego samouczka, aby uzyskać więcej informacji na temat konfigurowania programu Visual Studio i programu SQL Server w celu debugowania wystąpienia zdalnego.

Na koniec należy zrozumieć, że obsługa debugowania obiektów bazy danych T-SQL nie jest tak rozbudowana, jak obsługa debugowania dla aplikacji platformy .NET. Na przykład warunki i filtry punktu przerwania nie są obsługiwane, dostępny jest tylko podzbiór okien debugowania, nie można skorzystać z funkcji Edytuj i kontynuować, okno natychmiastowe staje się bezużyteczne i tak dalej. Aby uzyskać więcej informacji , zobacz Ograniczenia dotyczące poleceń i funkcji debugera .

Krok 1. Bezpośrednie przejście do procedury składowanej

Program Visual Studio ułatwia bezpośrednie debugowanie obiektu bazy danych. Przyjrzyjmy się, jak za pomocą funkcji debugowania bezpośredniej bazy danych (DDD) przejść do Products_SelectByCategoryID procedury składowanej w bazie danych Northwind. Jak sama nazwa wskazuje, Products_SelectByCategoryID zwraca informacje o produkcie dla określonej kategorii. Została ona utworzona w samouczku Using Existing Stored Procedures for the Typed DataSet s TableAdapters (Używanie istniejących procedur składowanych dla typów elementów TableAdapters ). Zacznij od przejścia do Eksploratora serwera i rozwinięcia węzła bazy danych Northwind. Następnie przejdź do folderu Procedury składowane, kliknij prawym przyciskiem myszy Products_SelectByCategoryID procedurę składowaną i wybierz opcję Krok do procedury składowanej z menu kontekstowego. Spowoduje to uruchomienie debugera.

Products_SelectByCategoryID Ponieważ procedura składowana oczekuje parametru wejściowego@CategoryID, zostanie wyświetlony monit o podanie tej wartości. Wprowadź wartość 1, która zwróci informacje o napojach.

@CategoryID Parametr" />

Rysunek 1. Użyj wartości 1 dla parametru @CategoryID

Procedura składowana jest wykonywana po podaniu wartości parametru @CategoryID. Zamiast uruchamiać polecenie do ukończenia, debuger zatrzymuje jednak wykonywanie w pierwszej instrukcji. Zwróć uwagę na żółtą strzałkę na marginesie wskazującą bieżącą lokalizację w procedurze składowanej. Wartości parametrów można wyświetlać i edytować za pomocą okna Obserwowanie lub umieszczając wskaźnik myszy na nazwie parametru w procedurze składowanej.

Rysunek 2: Debugger zatrzymał się na pierwszej instrukcji procedury składowanej (kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Aby przechodzić przez procedurę składowaną jeden krok po drugim, kliknij przycisk Przejdź dalej na pasku narzędzi lub naciśnij klawisz F10. Procedura składowana Products_SelectByCategoryID zawiera pojedynczą instrukcję SELECT, więc naciśnięcie F10 spowoduje przejście nad tą instrukcją i zakończenie wykonania procedury składowanej. Po zakończeniu procedury składowanej dane wyjściowe pojawią się w oknie Dane wyjściowe, a debuger zakończy działanie.

Uwaga / Notatka

Debugowanie języka T-SQL odbywa się na poziomie instrukcji; Nie można przejść do instrukcji SELECT .

Krok 2. Konfigurowanie witryny internetowej na potrzeby debugowania aplikacji

Podczas debugowania procedury składowanej bezpośrednio z Eksploratora serwera to jest wygodne, ale w wielu scenariuszach bardziej interesuje nas debugowanie procedury składowanej, gdy jest wywoływana z naszej aplikacji ASP.NET. Możemy dodać punkty przerwania do procedury składowanej z poziomu programu Visual Studio, a następnie rozpocząć debugowanie aplikacji ASP.NET. Gdy procedura składowana z punktami przerwania jest wywoływana z aplikacji, wykonanie zostanie zatrzymane w punkcie przerwania i możemy wyświetlić i zmienić wartości parametrów procedury składowanej oraz przejść przez jej instrukcje, podobnie jak w kroku 1.

Zanim zaczniemy debugować procedury składowane wywoływane z aplikacji, musimy skonfigurować aplikację internetową ASP.NET, aby zintegrować się z debugerem SQL Server. Zacznij od kliknięcia prawym przyciskiem myszy nazwy witryny internetowej w Eksploratorze rozwiązań (ASPNET_Data_Tutorial_74_VB). Wybierz opcję Strony właściwości z menu kontekstowego, wybierz element Opcje uruchamiania po lewej stronie, a następnie zaznacz pole wyboru SQL Server w sekcji Debugery (zobacz Rysunek 3).

Rysunek 3. Zaznacz pole wyboru programu SQL Server na stronach właściwości aplikacji (kliknij, aby wyświetlić obraz pełnowymiarowy)

Ponadto musimy zaktualizować łańcuch połączenia bazy danych używany przez aplikację, aby buforowanie połączeń było wyłączone. Po zamknięciu połączenia z bazą danych odpowiedni SqlConnection obiekt jest umieszczany w puli dostępnych połączeń. Podczas nawiązywania połączenia z bazą danych można pobrać dostępny obiekt połączenia z tej puli zamiast tworzyć i ustanawiać nowe połączenie. Ta pula obiektów połączenia jest ulepszeniem wydajności i jest domyślnie włączona. Jednak podczas debugowania chcemy wyłączyć buforowanie połączeń, ponieważ infrastruktura debugowania nie została poprawnie ponownie utworzona podczas pracy z połączeniem pobranym z puli.

pl-PL: Aby wyłączyć buforowanie połączeń, zaktualizuj NORTHWNDConnectionString w pliku Web.config, aby zawierał ustawienie 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>

Uwaga / Notatka

Po zakończeniu debugowania programu SQL Server za pośrednictwem aplikacji ASP.NET pamiętaj o przywróceniu puli połączeń przez usunięcie Pooling ustawienia z parametrów połączenia (lub przez ustawienie go na Pooling=true ).

W tym momencie aplikacja ASP.NET została skonfigurowana tak, aby umożliwić programowi Visual Studio debugowanie obiektów bazy danych SQL Server, gdy są one wywoływane za pośrednictwem aplikacji internetowej. Wszystko, co pozostaje teraz, to dodać punkt przerwania do procedury składowanej i rozpocząć debugowanie!

Krok 3. Dodawanie punktu przerwania i debugowania

Otwórz procedurę składowaną Products_SelectByCategoryID i ustaw punkt przerwania, najpierw klikając w marginesie przy odpowiednim miejscu na początku wyrażenia SELECT, a następnie umieszczając kursor na początku wyrażenia SELECT i wciskając klawisz F9. Jak pokazano na rysunku 4, punkt przerwania jest wyświetlany jako czerwony okrąg na marginesie.

Rysunek 4: Ustaw punkt przerwania w procedurze składowanej (Products_SelectByCategoryID)

Aby obiekt bazy danych SQL był debugowany za pośrednictwem aplikacji klienckiej, należy skonfigurować bazę danych do obsługi debugowania aplikacji. Po pierwszym ustawieniu punktu przerwania to ustawienie powinno być automatycznie włączone, ale należy dokładnie sprawdzić. Kliknij prawym przyciskiem myszy na węzeł NORTHWND.MDF w Eksploratorze serwera. Menu kontekstowe powinno zawierać zaznaczony element menu o nazwie Debugowanie aplikacji.

Rysunek 5. Upewnij się, że opcja debugowania aplikacji jest włączona

Po ustawieniu punktu przerwania i włączeniu opcji Debugowanie aplikacji możemy debugować procedurę składowaną po wywołaniu z aplikacji ASP.NET. Uruchom debuger, przechodząc do menu Debugowanie i wybierając pozycję Rozpocznij debugowanie, naciskając F5 lub klikając zieloną ikonę odtwarzania na pasku narzędzi. Spowoduje to uruchomienie debugera i uruchomienie witryny internetowej.

Procedura Products_SelectByCategoryID składowana została utworzona w samouczku Using Existing Stored Procedures for the Typed DataSet s TableAdapters (Używanie istniejących procedur składowanych dla typów zestawów danych TableAdapters ). Odpowiadająca jej strona internetowa (~/AdvancedDAL/ExistingSprocs.aspx) zawiera GridView, który wyświetla wyniki zwrócone przez tę procedurę składowaną. Odwiedź tę stronę za pośrednictwem przeglądarki. Po dotarciu do strony przechwytywanie punktu przerwania w Products_SelectByCategoryID procedurze składowanej zostanie uruchomione i kontrola zostanie zwrócona do programu Visual Studio. Podobnie jak w kroku 1, można przejść przez instrukcje procedury składowanej i wyświetlić i zmodyfikować wartości parametrów.

Rysunek 6. Strona ExistingSprocs.aspx początkowo wyświetla napoje (kliknij, aby wyświetlić obraz pełnowymiarowy)

Rysunek 7: Osiągnięto punkt przerwania procedury przechowywanej (Kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Jak pokazuje okno Obserwowanie na rysunku 7, wartość parametru @CategoryID to 1. Dzieje się tak, ponieważ ExistingSprocs.aspx strona początkowo wyświetla produkty w kategorii napojów, która ma CategoryID wartość 1. Wybierz inną kategorię z listy rozwijanej. Spowoduje to wykonanie operacji postback i ponowne uruchomienie Products_SelectByCategoryID procedury składowanej. Punkt przerwania zostanie ponownie trafiony, ale tym razem wartość parametru @CategoryID odzwierciedla wartość wybranego elementu listy rozwijanej CategoryID.

Rysunek 8. Wybieranie innej kategorii z listy Drop-Down (kliknij, aby wyświetlić obraz pełnowymiarowy)

@CategoryID odzwierciedla kategorię wybraną na stronie sieci Web" />

Rysunek 9. @CategoryID Parametr odzwierciedla kategorię wybraną na stronie sieci Web (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Uwaga / Notatka

Jeśli punkt przerwania w procedurze składowanej Products_SelectByCategoryID nie został trafiony podczas odwiedzania strony ExistingSprocs.aspx, upewnij się, że znacznik SQL Server został zaznaczony w sekcji Debugowanie strony właściwości aplikacji ASP.NET, że buforowanie połączeń zostało wyłączone i że opcja Debugowanie aplikacji bazy danych jest włączona. Jeśli nadal występują problemy, uruchom ponownie program Visual Studio i spróbuj ponownie.

Debugowanie obiektów T-SQL Database w wystąpieniach zdalnych

Debugowanie obiektów bazy danych za pomocą programu Visual Studio jest dość proste, gdy wystąpienie bazy danych programu SQL Server znajduje się na tej samej maszynie co program Visual Studio. Jeśli jednak program SQL Server i program Visual Studio znajdują się na różnych maszynach, wymagana jest staranne skonfigurowanie, aby wszystko działało prawidłowo. Istnieją dwa podstawowe zadania, z którymi mamy do czynienia:

• Upewnij się, że identyfikator logowania używany do nawiązywania połączenia z bazą danych za pośrednictwem ADO.NET należy do sysadmin roli.
• Upewnij się, że konto użytkownika systemu Windows używane przez program Visual Studio na komputerze deweloperskim jest prawidłowym kontem logowania programu SQL Server należącym sysadmin do roli.

Pierwszy krok jest stosunkowo prosty. Najpierw zidentyfikuj konto użytkownika używane do nawiązywania połączenia z bazą danych z aplikacji ASP.NET, a następnie z programu SQL Server Management Studio dodaj to konto logowania do sysadmin roli.

Drugie zadanie wymaga, aby konto użytkownika systemu Windows używane do debugowania aplikacji było prawidłowym identyfikatorem logowania w zdalnej bazie danych. Jednak istnieje duże prawdopodobieństwo, że konto Windows, które użyłeś do zalogowania się na stacji roboczej, nie jest ważnym kontem na serwerze SQL Server. Zamiast dodawać określone konto logowania do programu SQL Server, lepszym wyborem byłoby wyznaczenie konta użytkownika systemu Windows jako konta debugowania programu SQL Server. Następnie, aby debugować obiekty bazy danych zdalnego wystąpienia programu SQL Server, należy uruchomić program Visual Studio, korzystając z poświadczeń tego konta logowania w systemie Windows.

Przykład powinien pomóc w wyjaśnieniu rzeczy. Załóżmy, że istnieje konto systemu Windows o nazwie SQLDebug w domenie systemu Windows. To konto musi zostać dodane do zdalnego wystąpienia programu SQL Server jako prawidłowy login i jako członek roli sysadmin. Następnie, aby debugować zdalne wystąpienie SQL Server w programie Visual Studio, musimy uruchomić Visual Studio jako użytkownik SQLDebug. Można to zrobić, wylogowając się z naszej stacji roboczej, logując się ponownie jako SQLDebug, a następnie uruchamiając program Visual Studio, ale prostszą metodą byłoby zalogowanie się do naszej stacji roboczej przy użyciu własnych poświadczeń, a następnie użycie runas.exe polecenia w celu uruchomienia programu Visual Studio jako SQLDebug użytkownika. runas.exe umożliwia wykonanie określonej aplikacji pod pozorem innego konta użytkownika. Aby uruchomić program Visual Studio jako SQLDebug, możesz wprowadzić następującą instrukcję w wierszu polecenia:

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

Aby uzyskać bardziej szczegółowe wyjaśnienie tego procesu, zobacz William R. Vaughn'sHitchhiker's Guide to Visual Studio and SQL Server, Seventh Edition (Przewodnik po hitchhikerach Williama R. Vaughna w programach Visual Studio i SQL Server).

Uwaga / Notatka

Jeśli na komputerze deweloperskim jest uruchomiony dodatek Service Pack 2 systemu Windows XP, należy skonfigurować zaporę połączenia internetowego, aby umożliwić zdalne debugowanie. Artykuł Instrukcje: Włączanie debugowania programu SQL Server 2005 zauważa, że obejmuje to dwa kroki: (a) Na maszynie hosta programu Visual Studio należy dodać Devenv.exe do listy Wyjątki i otworzyć port TCP 135; i (b) Na komputerze zdalnym (SQL) musisz otworzyć port TCP 135 i dodać sqlservr.exe go do listy Wyjątki. Jeśli zasady domeny wymagają komunikacji sieciowej za pośrednictwem protokołu IPSec, należy otworzyć porty UDP 4500 i UDP 500.

Podsumowanie

Oprócz zapewnienia obsługi debugowania kodu aplikacji platformy .NET program Visual Studio udostępnia również różne opcje debugowania dla programu SQL Server 2005. W tym samouczku przyjrzeliśmy się dwóm z tych opcji: debugowaniu bezpośredniej bazy danych i debugowaniu aplikacji. Aby bezpośrednio debugować obiekt bazy danych T-SQL, znajdź obiekt za pośrednictwem Eksploratora serwera, a następnie kliknij go prawym przyciskiem myszy i wybierz polecenie Przejdź do. Spowoduje to uruchomienie debugera i zatrzymanie na pierwszej instrukcji w obiekcie bazy danych, po czym można przechodzić przez instrukcje obiektu oraz wyświetlać i modyfikować wartości parametrów. W kroku 1 użyliśmy tego podejścia, aby przejść do tej procedury składowanej Products_SelectByCategoryID.

Debugowanie aplikacji umożliwia ustawianie punktów przerwania bezpośrednio w obiektach bazy danych. Gdy obiekt bazy danych zawierający punkty przerwań jest wywoływany z aplikacji klienckiej (takiej jak aplikacja internetowa ASP.NET), program się zatrzymuje, ponieważ debuger przejmuje kontrolę. Debugowanie aplikacji jest przydatne, ponieważ bardziej wyraźnie pokazuje, jakie działanie aplikacji powoduje wywołanie określonego obiektu bazy danych. Wymaga to jednak nieco więcej konfiguracji i konfiguracji niż bezpośrednie debugowanie bazy danych.

Obiekty bazy danych można również debugować za pomocą projektów programu SQL Server. W następnym samouczku przyjrzymy się używaniu projektów programu SQL Server i sposobom ich używania do tworzenia i debugowania zarządzanych obiektów bazy danych.

Szczęśliwe programowanie!

Informacje o autorze

Scott Mitchell, autor siedmiu książek ASP/ASP.NET i założyciel 4GuysFromRolla.com, współpracuje z technologiami internetowymi firmy Microsoft od 1998 roku. Scott pracuje jako niezależny konsultant, trener i pisarz. Jego najnowsza książka to Sams Teach Yourself ASP.NET 2.0 w ciągu 24 godzin. Można go uzyskać pod adresem mitchell@4GuysFromRolla.com.

PoprzedniNastępny