私はクエリに取り組んでおり、select ステートメントの TSQL "FOR BROWSE" オプションに関する Microsoft からの最小限のドキュメントを見つけました。
カーソルのオプションとして文書化された FOR BROWSE を見たことがありますが、これを使用する良い例や、SELECT ステートメントで FOR BROWSE を使用する理由を見つけることができませんでした。
TSQL SELECT ステートメントで FOR BROWSE を使用する正当な理由は何ですか?
SQL Server 2008 および 2012 を使用しています。
私の知る限り。これは、1 人以上のユーザーが同時に同じソースからデータにアクセスして更新するアプリケーション内で楽観的同時実行制御を実装するためのインターフェイスのようです。また、互換性のあるフロント エンド ライブラリ ( DB-Library ) と連携して動作するようです。ただし、「 For Browse」ステートメントを使用せずに上記のすべてを実現できるため、これはやや非推奨のメカニズムのようです。これは、DB-Library (非推奨の C ライブラリ) 呼び出し " dbopen " の結果である 2 つの DBPROCESS 構造体を作成する必要があることからも確認できます。
さらに、ブラウズ モードには 2 つの DBPROCESS 構造体が必要です。1 つはデータを選択するためのもので、もう 1 つは選択したデータに基づいて更新するためのものです。ソース
DB-Library と組み合わせて "For Browse" クエリを使用する例を次に示します。
最終的には、このメカニズムは下位互換性のためにまだ存在していると結論付けるのが妥当でしょう。したがって、DB-Library を使用して C ベースのクライアントを維持している場合を除き、この SQL " for 句"についてあまり心配する必要はありません。
その他のソース
もう1つの観察
FOR BROWSE で宣言されたカーソルは、OPEN CURSOR 操作中のみ、コミットされていない変更 (カーソルの所有者を含むすべてのユーザーによって行われた) を待機する必要があります。カーソルが開いた後は、その後の変更によってカーソルが待機することはありません。カーソルが再度開かれると、コミットされていない変更によってブロックされる可能性があります。ソース
より詳細なスキーマ情報を取得するには、FOR BROWSE を SQL SELECT ステートメントに追加するか、SQL Server 接続で SET NO_BROWSETABLE ON を使用する必要がある場合があります。
これは、SQL SELECT に FOR BROWSE が追加されていない限り、 ODBC 関数SQLColAttributeによって返される詳細の一部が空の文字列を返すため、アプリケーションが ODBC レイヤーを介して SQL Server と直接または間接的に対話する場合に役立ちます。
たとえば、C++ アプリがlibodbc++を使用し、クエリ SELECT * FROM A, B から結果セットを取得する場合、ResultSetMetaData オブジェクトから列のテーブル名を取得することはできません。ただし、FOR BROWSE を追加すると、テーブル名が正しく入力されます。