次の方法で共有

SQL デバッグの制約

  • [アーティクル]

更新 : 2007 年 11 月

このトピックの内容は、次の製品に該当します。

Edition

Visual Basic

C#

C++

Web Developer

Express

 トピック該当なし トピック該当なし トピック該当なし トピック該当なし

Standard

 トピック該当なし トピック該当なし トピック該当なし トピック該当なし

Pro/Team

 トピック該当 トピック該当 トピック該当 トピック該当

表の凡例 :

トピック該当

対象
トピック該当なし

該当なし
トピックは該当しますが、コマンドは既定では非表示です

既定で非表示のコマンド

SQL デバッグには、一般的な制約がいくつかあります。ここでは、その制約について説明します。

多階層の SQL のデバッグ

  • 多階層のアプリケーションをデバッグする場合、[ステップ イン] を使用して、アプリケーション階層のコード (C#、Visual Basic、または C++) から SQL Server 2005 のコード (T-SQL または SQL CLR) にステップ インすることはできません。この場合、ストアド プロシージャ コードにブレークポイントを設定し、[続行] (F5) をクリックして、ブレークポイントまでのコードを実行します。[カーソル行の前まで実行] を使用して、ブレークポイントを使用せずに目的のポイントに到達することもできます。注意が必要なのは、SQL Server 2005 階層内では、T-SQL コードと SQL CLR コードの間で、相互にステップ インできるという点です。

  • また、ストアド プロシージャ コードから、ストアド プロシージャを呼び出した階層にあるコードに戻るような、逆方向でのステップ実行もできません。アプリケーション階層に戻った後にデバッグを続行するには、アプリケーション コードで、ストアド プロシージャが呼び出されたポイントの後に、ブレークポイントを設定します。

  • 接続プール機能は、パフォーマンスを向上させるためのテクニックです。アプリケーションがデータ接続を終了するときには、SQL Server の接続を完全に終了せず、アプリケーションが接続をもう一度開こうとしたときに再利用可能なプールを維持します。ただし、接続プールを利用して接続を再度確立した場合、SQL デバッグは再度有効になりません。

    デバッグ中は、接続プールを一時的に無効にすることをお勧めします。これを行うには、SQL Server への接続に使用する接続文字列で、「Pooling=false」と設定します。デバッグを完了した後、接続文字列からこの属性を削除すると、既定で接続プールが有効になります。

  • マネージ アプリケーションは、.NET Data Provider for SQL Server を利用して SQL Server データ ソースに接続できます。この方法は、OLE DB または ODBC で接続する場合よりもパフォーマンスが向上します。マネージ デバッグと SQL デバッグのどちらも、同じデバッガ セッションで実行できます。

    マネージ アプリケーションの実行中にデバッガを使ってアプリケーションに接続する場合は、実行するデバッグの種類を選択します。SQL デバッグを実行する場合は、SQL デバッグを選択します。SQL CLR コードをデバッグする場合は、マネージ デバッグを指定します。

  • 実行中のアプリケーションに接続した後に SQL デバッグを実行できます。ただし、デバッグできるのは、[アタッチ] が完了した後に作成したデータベース接続だけです。そのため、アプリケーションからストアド プロシージャの呼び出しに時間がかかっていると、ストアド プロシージャを呼び出した接続にアタッチできません。アプリケーションへの接続を完了した後にストアド プロシージャを呼び出した新しい接続の場合のみ、アタッチできます。

  • OleDbDataAdapter との間に確立された接続を通じてデバッグしている場合は、ブレークポイントにヒットした後で長時間待機すると、接続がタイムアウトになる場合があります。このタイムアウト後に、たとえば [デバッグ] メニューの [続行] を選択してデバッグの継続を試行すると、実行は継続されずデバッガは終了します。これは予測どおりの動作です。OleDbDataAdapter は、SqlDataAdapter とは異なり、タイムアウト発生時に例外をスローしないため、デバッガが終了します。この問題を回避するには、OleDbDataAdapter を使用する場合にタイムアウト値を高い数値に設定します。

    .NET Framework データ プロバイダのタイムアウト値の設定については、.NET Framework クラス ライブラリのドキュメントの「OleDbCommand.CommandTimeout プロパティ」および「SqlCommand.CommandTimeout プロパティ」を参照してください。

    MDAC テクノロジの最新ニュースについては、Microsoft Universal Data Access Web サイト (https://msdn2.microsoft.com/ja-jp/library/default.aspx) を参照してください。

他の制約

  • デバッグの対象となるようにトリガを発生させる必要があります。トリガを直接デバッグすることはできません。トリガを発生させるストアド プロシージャでデバッグを開始するようにします。

  • ランタイムのデバッグでは、一連の subselect (union 内など) で、ネットバッファがすべて使用される可能性があります。そのため、通常は正しく機能するコードでも、デバッグ中に停止することもあります。詳しいデータを取得するには、RecordSet.MoveNext と RecordSet.NextRecordSet を使用します。

  • ストアド プロシージャの名前に引用符が含まれている場合、デバッガのエラー メッセージが表示されます。詳細については、「名前に引用符を含むプロシージャをデバッグするときのエラー」を参照してください。

  • キャッシュされた値は、自動的には変更されません。SQL インタープリタによってキャッシュされたローカル変数またはパラメータへの変更は、SQL ステートメントをステップ実行する間隔で反映されるとは限りません。値を変更しても、一度もキャッシュが更新されない場合があります。キャッシュされた値を強制的に更新することはできません。変数の値をキャッシュするか、または SQL ステートメントの実行や参照ごとに値を動的に読み込むかは、SQL Server の実行計画で決まります。詳細については、SQL Server 2005 の "SHOWPLAN" に関するドキュメントを参照してください。

  • ストアド プロシージャをデバッグしながら、ネイティブの SQL Server プロセスにアタッチすることはできません。

参照

概念

デバッガのセキュリティ

SQL のデバッグ

デバッガのコマンドと機能に関する制約