Transact-SQL デバッグの制限事項
このトピックの内容は、次の製品に該当します。
Visual Studio Ultimate |
Visual Studio Premium |
Visual Studio Professional |
Visual Studio Express |
|---|---|---|---|
.gif "kkyhd4yb.DoesApplybmp(ja-jp,VS.100).gif") |
|
|
.gif "kkyhd4yb.DoesNotApplybmp(ja-jp,VS.100).gif") |
Visual Studio デバッガーおよび SQL Server 2005 以降の SQL Server を使用して Transact-SQL をデバッグするときには、多くの一般的な制限事項について考慮する必要があります。SQL Server Management Studio を使用した Transact-SQL のデバッグの詳細については、「Transact-SQL デバッガーの使用」を参照してください。
多階層 SQL デバッグ
多階層アプリケーションをデバッグするとき、[ステップ イン] オプションを使用してアプリケーション層 (C#、Visual Basic、または C++) のコードから SQL Server (Transact-SQL または SQL/CLR) のインスタンスのコードにステップ インすることはできません。代わりに、ストアド プロシージャ コードにブレークポイントを設定して、[継続] (F5) を押し、コードをブレークポイントまで実行します。また、[カーソル行の前まで実行] を使用して、ブレークポイントを使用せずに目的のポイントまで移動することもできます。SQL Server 層内部で、Transact-SQL と SQL/CLR コードの間を自由に移動できることに注意してください。
また、ストアド プロシージャ コードから、そのストアド プロシージャを呼び出した層のコードに戻ることもできません。アプリケーション層に戻った後もデバッグを続行するには、アプリケーション コード内でストアド プロシージャを呼び出したポイントの後にブレークポイントを設定します。
接続プールは、パフォーマンスを向上させるための手法です。アプリケーションがデータ接続を閉じても、SQL Server の接続は完全には閉じられず、プールに保管されます。アプリケーションが後で接続を再度開こうとしたときに、再利用することができます。ただし、接続プールによって接続が再確立されても、Transact-SQL デバッグは再度有効にはなりません。
デバッグ中は、接続プールを一時的に無効にする必要があります。そのためには、SQL Server のインスタンスへの接続に使用する接続文字列に "Pooling=false" を設定します。デバッグが終了したら、接続文字列からこの属性を削除します。これにより、既定で接続プールが有効になります。
マネージ アプリケーションは、SQL Server 用の .NET Framework データ プロバイダーを使用して SQL Server データ ソースに接続することができます。これを使用すると、OLE DB や ODBC で接続する場合よりパフォーマンスが向上します。同じ 1 つのデバッグ セッションで、マネージ デバッグと Transact-SQL デバッグの両方を実行することができます。
マネージ アプリケーションが実行中であり、ユーザーがデバッガーを使用してアプリケーションにアタッチする場合、実行するデバッグの種類を選択することができます。Transact-SQL デバッグを実行するには、Transact-SQL デバッグを選択する必要があります。SQL/CLR コードをデバッグするには、マネージ デバッグも指定する必要があります。
実行中のアプリケーションにアタッチした後に Transact-SQL デバッグを行うことができます。ただし、デバッグできるのは、アタッチを完了した後に作成したデータベース接続だけであることに注意してください。したがって、アプリケーションが、非常に時間のかかっているストアド プロシージャを呼び出すと、ユーザーはそのストアド プロシージャを呼び出した接続にアタッチすることはできません。アタッチできるのは、アプリケーションへの接続が完了した後にストアド プロシージャを呼び出す新しい接続だけです。
OleDbDataAdapter で作成された接続を通じてデバッグしている場合、ブレークポイントをヒットした後に何も操作せず長時間が経過すると、接続がタイムアウトします。このタイムアウト後にも引き続きデバッグを行おうとすると (たとえば、[デバッグ] メニューの [続行] をクリック)、デバッガーは終了します (実行は続行されません)。この動作は想定されているものです。デバッガーが終了するのは、SqlDataAdapter とは異なり、OleDbDataAdapter はタイムアウトが発生しても例外をスローしないからです。この問題に対処するには、OleDbDataAdapter のタイムアウト値を大きくしてください。
.NET Framework データ プロバイダーのタイムアウト値設定の詳細については、.NET Framework クラス ライブラリ ドキュメントの「OleDbCommand.CommandTimeout プロパティ」および「SqlCommand.CommandTimeout プロパティ」を参照してください。
他の制約
トリガーをデバッグするには、起動する必要があります。トリガーを直接デバッグすることはできません。トリガーを起動するストアド プロシージャでデバッグを開始してください。
ランタイム デバッグでは、ネットワーク バッファーが一連のサブセレクト (共用体などの) によって満たされることがあります。その結果、通常は正常に実行されるコードが、デバッグ中は中止されることがあります。データをさらに取得するには、RecordSet.MoveNext と RecordSet.NextRecordSet を使用してください。
ストアド プロシージャの名前に引用符が含まれる場合、デバッガーのエラー メッセージが表示されることがあります。詳細については、「名前に引用符を含むプロシージャをデバッグするときのエラー」を参照してください。
キャッシュされた値は、自動的に変更されません。Transact-SQL インタープリターによってキャッシュされたローカルまたはパラメーターに加えた変更が、Transact-SQL ステートメントをステップ実行しているタイム フレーム内に反映されるとは限りません。値を変更しても、再度チェックされることはない可能性があります。キャッシュされた値を強制的に更新することはできません。キャッシュされた値が存在するのは、各ステートメントまたは参照に対していくつかの変数の値が動的に読み込まれないよう SQL Server 実行計画によって指定されるからです。詳細については、SQL Server ドキュメントで "SHOWPLAN" を検索してください。
SQL Server のネイティブ プロセスにアタッチしながら、同時にストアド プロシージャをデバッグすることはできません。