ストアド プロシージャのデバッグ (C#)

作成者: Scott Mitchell

PDF のダウンロード

Visual Studio Professional エディションと Team System エディションを使用すると、ブレークポイントを設定し、SQL Server 内のストアド プロシージャにステップ インできるため、ストアド プロシージャのデバッグがアプリケーション コードのデバッグと同じくらい簡単になります。 このチュートリアルでは、ストアド プロシージャの直接データベース デバッグとアプリケーション デバッグについて説明します。

はじめに

Visual Studio には、豊富なデバッグ エクスペリエンスが用意されています。 数回のキーストロークまたはマウスのクリックで、ブレークポイントを使用してプログラムの実行を停止し、その状態と制御フローを調べることができます。 Visual Studio では、アプリケーション コードのデバッグと共に、SQL Server 内からのストアド プロシージャのデバッグをサポートしています。 ブレークポイントは、ASP.NET 分離コード クラスまたは Business Logic Layer クラスのコード内で設定できるのと同様に、ストアド プロシージャ内にも配置できます。

このチュートリアルでは、Visual Studio 内のサーバー エクスプローラーからストアド プロシージャにステップ インする方法と、実行中の ASP.NET アプリケーションからストアド プロシージャが呼び出されたときにヒットするブレークポイントを設定する方法について説明します。

Note

残念ながら、ストアド プロシージャは、Visual Studio の Professional および Team Systems バージョンでのみステップ インおよびデバッグできます。 Visual Web Developer または Visual Studio の標準バージョンを使用している場合は、ストアド プロシージャをデバッグするために必要な手順の説明を確認することはできますが、コンピューターでこれらの手順を再現することはできません。

SQL Server のデバッグの概念

Microsoft SQL Server 2005 は、すべての .NET アセンブリで使用されるランタイムである共通言語ランタイム (CLR) との統合を提供するように設計されています。 そのため、SQL Server 2005 ではマネージド データベース オブジェクトがサポートされます。 つまり、ストアド プロシージャやユーザー定義関数 (UDF) などのデータベース オブジェクトを C# クラスのメソッドとして作成できます。 これにより、これらのストアド プロシージャと UDF は、.NET Framework および独自のカスタム クラスの機能を利用できます。 もちろん、SQL Server 2005 では T-SQL データベース オブジェクトもサポートされています。

SQL Server 2005 では、T-SQL オブジェクトとマネージド データベース オブジェクトの両方に対するデバッグサポートが提供されます。 ただし、これらのオブジェクトは、Visual Studio 2005 の Professional および Team Systems エディションでのみデバッグできます。 このチュートリアルでは、T-SQL データベース オブジェクトのデバッグについて説明します。 後続のチュートリアルで、マネージド データベース オブジェクトのデバッグについて取り上げます。

SQL Server 2005 CLR 統合チームの「SQL Server 2005 での T-SQL と CLR のデバッグの概要」のブログ記事では、Visual Studio から SQL Server 2005 オブジェクトをデバッグする 3 つの方法が取り上げられています。

• ダイレクト データベース デバッグ (DDD) - サーバー エクスプローラーから、ストアド プロシージャや UDF などの任意の T-SQL データベース オブジェクトにステップ インできます。 手順 1 で DDD について調べます。
• アプリケーション デバッグ - データベース オブジェクト内にブレークポイントを設定し、ASP.NET アプリケーションを実行できます。 データベース オブジェクトが実行されると、ブレークポイントがヒットし、制御がデバッガーに移ります。 アプリケーション デバッグでは、アプリケーション コードからデータベース オブジェクトにステップ インできないことに注意してください。 デバッガーを停止するストアド プロシージャまたは UDF にブレークポイントを明示的に設定する必要があります。 アプリケーション デバッグは、手順 2 以降で確認します。
• SQL Server プロジェクトからのデバッグ - Visual Studio Professional および Team Systems エディションには、マネージド データベース オブジェクトの作成に一般的に使用される SQL Server プロジェクト タイプが含まれています。 次のチュートリアルでは、SQL Server プロジェクトの使用とその内容のデバッグについて説明します。

Visual Studio では、ローカルおよびリモートの SQL Server インスタンスでストアド プロシージャをデバッグできます。 ローカル SQL Server インスタンスは、Visual Studio と同じコンピューターにインストールされているインスタンスです。 使用している SQL Server データベースが開発用コンピューターにない場合は、それはリモート インスタンスと見なされます。 ここまでのチュートリアルでは、ローカル SQL Server インスタンスを使用してきました。 リモート SQL Server インスタンスでストアド プロシージャをデバッグするには、ローカル インスタンスでストアド プロシージャをデバッグする場合よりも多くの構成手順が必要です。

ローカル SQL Server インスタンスを使用している場合は、手順 1 から始めて、このチュートリアルを最後まで進めることができます。 ただし、リモート SQL Server インスタンスを使用している場合は、まず、デバッグ時に、リモート インスタンスに SQL Server ログインがある Windows ユーザー アカウントを使用して開発マシンにログインしていることを確認する必要があります。 さらに、このデータベース ログインと、実行中の ASP.NET アプリケーションからデータベースに接続するために使用するデータベース ログインの両方が sysadmin ロールのメンバーである必要があります。 リモート インスタンスをデバッグするように Visual Studio と SQL Server を構成する方法の詳細については、このチュートリアルの最後にある「リモート インスタンスでの T-SQL Database オブジェクトのデバッグ」セクションを参照してください。

最後に、T-SQL データベース オブジェクトのデバッグ サポートは、.NET アプリケーションのデバッグ サポートほど機能が豊富ではないことを理解してください。 たとえば、ブレークポイントの条件とフィルターはサポートされておらず、デバッグ ウィンドウのサブセットのみを使用できます。[編集して続行] を使用することはできません。イミディエイト ウィンドウは役に立ちません。 詳細については、「デバッガーのコマンドと機能に関する制限事項」を参照してください。

手順 1: ストアド プロシージャに直接ステップ インする

Visual Studio を使用すると、データベース オブジェクトを簡単に直接デバッグできます。 ダイレクト データベース デバッグ (DDD) 機能を使用して Northwind データベースの Products_SelectByCategoryID ストアド プロシージャにステップ インする方法を見てみましょう。 その名前が示すように、Products_SelectByCategoryID は特定のカテゴリの製品情報を返します。これは、「型指定された DataSet の TableAdapters に既存のストアド プロシージャを使用する」のチュートリアルで作成されました。 まず、サーバー エクスプローラーに移動し、Northwind データベース ノードを展開します。 次に、[ストアド プロシージャ] フォルダーにドリルダウンし、Products_SelectByCategoryID ストアド プロシージャを右クリックし、コンテキスト メニューから [ストアド プロシージャにステップ イン] オプションを選択します。 これにより、デバッガーが起動します。

Products_SelectByCategoryID ストアド プロシージャは @CategoryID 入力パラメーターを必要とするため、この値を指定するように求められます。 「1」と入力すると、飲料に関する情報が返されます。

@CategoryID パラメーター" />

図 1: @CategoryID パラメーターに値 1 を使用する

@CategoryID パラメーターの値を指定すると、ストアド プロシージャが実行されます。 ただし、デバッガーは、完了まで実行するのではなく、最初のステートメントでの実行を停止します。 余白にある黄色の矢印に注目してください。ストアド プロシージャの現在の位置を示しています。 パラメーター値の表示と編集は、ウォッチ ウィンドウで行うか、ストアド プロシージャのパラメーター名にマウスを合わせて行うことができます。

図 2: ストアド プロシージャの最初のステートメントでデバッガーが停止した (フルサイズの画像を表示するにはクリックします)

ストアド プロシージャを一度に 1 つのステートメントでステップ実行するには、ツール バーの [ステップ オーバー] ボタンをクリックするか、F10 キーを押します。 Products_SelectByCategoryID ストアド プロシージャには 1 つの SELECT ステートメントが含まれているため、F10 キーを押すと、1 つのステートメントがステップ オーバーされ、ストアド プロシージャの実行が完了します。 ストアド プロシージャが完了すると、その出力が [出力] ウィンドウに表示され、デバッガーが終了します。

Note

T-SQL デバッグはステートメント レベルで行われます。SELECT ステートメントにステップ インすることはできません。

手順 2: アプリケーション デバッグ用に Web サイトを構成する

サーバー エクスプローラーからストアド プロシージャを直接デバッグすることは便利ですが、多くのシナリオでは、ASP.NET アプリケーションから呼び出されたときにストアド プロシージャをデバッグすることに関心があります。 Visual Studio 内からストアド プロシージャにブレークポイントを追加し、ASP.NET アプリケーションのデバッグを開始できます。 ブレークポイントを持つストアド プロシージャがアプリケーションから呼び出されると、ブレークポイントで実行が停止し、手順 1 で行ったのと同様に、ストアド プロシージャのパラメーター値を表示および変更し、そのステートメントをステップ実行できます。

アプリケーションから呼び出されるストアド プロシージャのデバッグを開始する前に、ASP.NET Web アプリケーションに SQL Server デバッガーと統合するように指示する必要があります。 まず、ソリューション エクスプローラーで Web サイト名 (ASPNET_Data_Tutorial_74_CS) を右クリックします。 コンテキスト メニューから [プロパティ ページ] オプションを選択し、左側の [スタート オプション] 項目を選択し、[デバッガー] セクションの [SQL Server] チェック ボックスをオンにします (図 3 を参照)。

図 3: アプリケーションのプロパティ ページの [SQL Server] チェック ボックスをオンにする (フルサイズの画像を表示するにはクリックします)

さらに、接続プールが無効になるように、アプリケーションで使用されるデータベース接続文字列を更新する必要があります。 データベースへの接続が閉じられると、対応する SqlConnection オブジェクトが使用可能な接続のプールに配置されます。 データベースへの接続を確立するときに、新しい接続を作成して確立する必要なく、このプールから使用可能な接続オブジェクトを取得できます。 この接続オブジェクトのプールによりパフォーマンスが向上し、既定で有効になっています。 ただし、デバッグ時には、プールから取得された接続を使用して操作すると、デバッグ インフラストラクチャが正しく再確立されないため、接続プールを無効にする必要があります。

接続プールを無効にするには、設定 Pooling=false が含まれるように Web.config の NORTHWNDConnectionString を更新します。

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

Note

ASP.NET アプリケーションを使用して SQL Server のデバッグが完了したら、接続文字列から Pooling 設定を削除 (または Pooling=true に設定) して、接続プールを復元してください。

この時点で、Web アプリケーションを介して呼び出されたときに Visual Studio が SQL Server データベース オブジェクトをデバッグできるように、ASP.NET アプリケーションが構成されています。 後は、ストアド プロシージャにブレークポイントを追加し、デバッグを開始するだけです。

手順 3: ブレークポイントの追加とデバッグ

Products_SelectByCategoryID ストアド プロシージャを開き、適切な場所にある余白をクリックするか、SELECT ステートメントの先頭にカーソルを置いて F9 キーを押して、SELECT ステートメントの先頭にブレークポイントを設定します。 図 4 に示すように、ブレークポイントは余白に赤い円で表示されます。

図 4: Products_SelectByCategoryID ストアド プロシージャにブレークポイントを設定する (フルサイズの画像を表示するにはクリックします)

クライアント アプリケーションを使用して SQL データベース オブジェクトをデバッグするには、アプリケーション デバッグをサポートするようにデータベースを構成する必要があります。 ブレークポイントを最初に設定すると、この設定は自動的にオンになりますが、ダブルチェックすることをお勧めします。 サーバー エクスプローラーで NORTHWND.MDF ノードを右クリックします。 コンテキスト メニューで、[アプリケーションのデバッグ] という名前のメニュー項目が有効になっているはずです。

図 5: [アプリケーションのデバッグ] オプションが有効になっていることを確認する

ブレークポイントが設定され、[アプリケーションのデバッグ] オプションが有効になっているので、ASP.NET アプリケーションから呼び出されたときにストアド プロシージャをデバッグする準備ができました。 デバッガーを起動するには、[デバッグ] メニューに移動し、[デバッグの開始] を選択するか、F5 キーを押すか、ツール バーの緑色の再生アイコンをクリックします。 これにより、デバッガーが開始され、Web サイトが起動します。

Products_SelectByCategoryID ストアド プロシージャは、「型指定された DataSet の TableAdapters で既存のストアド プロシージャを使用する」チュートリアルで作成されました。 対応する Web ページ (~/AdvancedDAL/ExistingSprocs.aspx) には、このストアド プロシージャによって返された結果を表示する GridView が含まれています。 ブラウザーでこのページにアクセスします。 ページに到達すると、Products_SelectByCategoryID ストアド プロシージャのブレークポイントがヒットし、制御が Visual Studio に返されます。 手順 1 と同様に、ストアド プロシージャのステートメントをステップ実行し、パラメーター値を表示および変更できます。

図 6: ExistingSprocs.aspx ページが最初に飲料を表示 (フルサイズの画像を表示するにはクリックします)

図 7: ストアド プロシージャのブレークポイントに到達 (フルサイズの画像を表示するにはクリックします)

図 7 のウォッチ ウィンドウに示すように、@CategoryID パラメーターの値は 1 です。 これは、ExistingSprocs.aspx ページに最初に CategoryID の値が 1 の飲料カテゴリの製品が表示されるためです。 ドロップダウン リストから別のカテゴリを選択します。 これにより、ポストバックが発生し、Products_SelectByCategoryID ストアド プロシージャが再実行されます。 ブレークポイントが再びヒットしますが、今回は @CategoryID パラメーターの値に選択したドロップダウン リスト項目の CategoryID が反映されます。

図 8: ドロップダウン リストから別のカテゴリを選択する (クリックするとフルサイズの画像を表示します)

@CategoryID パラメーターに Web ページから選択されたカテゴリが反映される" />

図 9: @CategoryID パラメーター に Web ページから選択されたカテゴリが反映される (フルサイズの画像を表示するにはクリックします)

Note

ExistingSprocs.aspx ページにアクセスしたときに Products_SelectByCategoryID ストアド プロシージャのブレークポイントにヒットしない場合は、ASP.NET アプリケーションのプロパティ ページの [デバッガー] セクションで [SQL Server] チェック ボックスが有効になっていること、その接続プールが無効になっていること、およびデータベースの [アプリケーションのデバッグ] オプションが有効になっていることを確認します。 それでも問題が解決しない場合は、Visual Studio を再起動してやり直してみてください。

リモート インスタンスの T-SQL データベース オブジェクトのデバッグ

SQL Server データベース インスタンスが Visual Studio と同じコンピューター上にある場合、Visual Studio を使用したデータベース オブジェクトのデバッグは非常に単純です。 ただし、SQL Server と Visual Studio が異なるマシン上に存在する場合は、すべてが正常に動作するように慎重な構成が必要です。 次の 2 つの主要なタスクに直面します。

• ADO.NET 経由でデータベースに接続するために使用されるログインが sysadmin ロールに属していることを確認します。
• 開発用マシン上の Visual Studio によって使用される Windows ユーザー アカウントが、sysadmin ロールに属する有効な SQL Server ログイン アカウントであることを確認します。

最初の手順は比較的簡単です。 まず、ASP.NET アプリケーションからデータベースへの接続に使用するユーザー アカウントを特定し、SQL Server Management Studio からそのログイン アカウントを sysadmin ロールに追加します。

2 番目のタスクでは、アプリケーションのデバッグに使用する Windows ユーザー アカウントがリモート データベースでの有効なログインである必要があります。 ただし、ワークステーションにログオンした Windows アカウントが SQL Server での有効なログインではない可能性があります。 特定のログイン アカウントを SQL Server に追加するのではなく、何らかの Windows ユーザー アカウントを SQL Server デバッグ アカウントとして指定することをお勧めします。 その後、リモート SQL Server インスタンスのデータベース オブジェクトをデバッグするために、その Windows ログイン アカウントの資格情報を使用して Visual Studio を実行します。

例を使って、作業を明確にします。 Windows ドメイン 内に SQLDebug という名前の Windows アカウントがあるとします。 このアカウントを、有効なログインとして、および sysadmin ロールのメンバーとして、リモート SQL Server インスタンスに追加する必要があります。 次に、Visual Studio からリモート SQL Server インスタンスをデバッグするために、Visual Studio を SQLDebug ユーザーとして実行する必要があります。 これを行うには、ワークステーションからログアウトし、SQLDebug として再度ログインしてから Visual Studio を起動します。ただし、より簡単な方法は、独自の資格情報を使用してワークステーションにログインしてから、runas.exe を使用して Visual Studio を SQLDebug ユーザーとして起動することです。 runas.exe を使用することで、別のユーザー アカウントを装って特定のアプリケーションを実行できます。 SQLDebug として Visual Studio を起動するには、コマンド ラインで次のステートメントを入力します。

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

このプロセスの詳細については、William R. Vaughn 氏の『Hitchhiker s Guide to Visual Studio and SQL Server, Seventh Edition』を参照してください。

Note

開発用コンピューターで Windows XP Service Pack 2 が実行されている場合は、リモート デバッグを許可するようにインターネット接続ファイアウォールを構成する必要があります。 SQL Server 2005 のデバッグを有効にする方法に関する記事では、次の 2 つの手順が必要になることが説明されています。(a) Visual Studio ホスト コンピューターで例外リストに Devenv.exe を追加し、TCP 135 ポートを開く必要があること。(b) リモート (SQL) コンピューターで、TCP 135 ポートを開き、例外リストに sqlservr.exe を追加する必要があること。 ドメイン ポリシーにより IPSec 経由でネットワーク通信を行う必要がある場合は、UDP 4500 と UDP 500 のポートも開く必要があります。

まとめ

Visual Studio では、.NET アプリケーション コードのデバッグ サポートを提供するだけでなく、SQL Server 2005 のさまざまなデバッグ オプションも提供しています。 このチュートリアルでは、データベース ダイレクト デバッグとアプリケーション デバッグの 2 つのオプションについて説明しました。 T-SQL データベース オブジェクトを直接デバッグするには、サーバー エクスプローラーでそのオブジェクトを見つけて右クリックし、[ステップ イン] を選択します。 これにより、デバッガーが起動し、データベース オブジェクトの最初のステートメントで停止します。その時点で、オブジェクトのステートメントをステップ実行し、パラメーター値を表示および変更できます。 手順 1 では、このアプローチを使用して Products_SelectByCategoryID ストアド プロシージャにステップ インしました。

アプリケーション デバッグを使用すると、データベース オブジェクト内でブレークポイントを直接設定できます。 ブレークポイントを持つデータベース オブジェクトがクライアント アプリケーション (ASP.NET Web アプリケーションなど) から呼び出されると、デバッガーが引き継いでプログラムが停止します。 アプリケーションのデバッグは、特定のデータベース オブジェクトが呼び出される原因となるアプリケーション アクションをより明確に示すので便利です。 ただし、ダイレクト データベース デバッグよりも少し多くの構成とセットアップが必要です。

データベース オブジェクトは、SQL Server プロジェクトを使用してデバッグすることもできます。 次のチュートリアルでは、SQL Server プロジェクトと、それらを使用してマネージド データベース オブジェクトを作成およびデバッグする方法について説明します。

プログラミングに満足!

著者について

7 冊の ASP/ASP.NET 書籍の著者であり、4GuysFromRolla.com の創設者である Scott Mitchell は、1998 年から Microsoft Web テクノロジに取り組んでいます。 Scott は、独立したコンサルタント、トレーナー、ライターとして働いています。 彼の最新の本は サムズは24時間で2.0 ASP.NET 自分自身を教えています。 にアクセスするか、ブログを使用して にアクセスmitchell@4GuysFromRolla.comできます。これは でhttp://ScottOnWriting.NET見つけることができます。

前へ次へ