初めて投稿させていただきます。
VB初心者ですのでお願いします。

現在、SQLSarverにADOで接続しています。
クライアントは複数です。同時レコード取得もありますので排他をかけてます。
CusorLocationを設定せずに
RecordSetでデータを取得するときにadopenDynamicでレコードカウントを
取得すると-1が返ってきます。
そこでCusorLocationをクライアントに設定しました。
CursorLocationのヘルプを見ても理解に苦しみました。
そこで、CursorLocationをクライアントに設定した場合と
CursorLocationをサーバに設定した場合の違い、メリットをお聞きしたいのです。
よろしくおねがいします。

> CursorLocationのヘルプを見ても理解に苦しみました。
カーソルについてわかってないのなら、
まずヘルプで「カーソル」を読んでみるべきでは？

キーワード
  カーソル
     サーバー カーソル vs. クライアント カーソル

sayさん返信ありがとうございました。
もう一度下記のキーワードで勉強してみます。
ありがとうございました。

もし、ヘルプを見て分らない事があったらもう一度
投稿させていただきます。



> カーソルについてわかってないのなら、
> まずヘルプで「カーソル」を読んでみるべきでは？
>
> キーワード
>   カーソル
>      サーバー カーソル vs. クライアント カーソル

> CusorLocationを設定せずに
その場合、規定値の設定が使われます。
Recordsetの場合は、「ConnectionのCursorLocation」。
Connectionの場合は、「adUseServer」になりますね。

> RecordSetでデータを取得するときにadopenDynamicでレコードカウントを
> 取得すると-1が返ってきます。
adOpenDynamic(ダイナミックカーソル)は、扱いが難しいので、
初心者のうちは手を出さない方が無難かと思いますよ。

たとえば SQL Serverのダイナミックカーソルでは、他のユーザーからのデータ操作が反映されるため、
先ほどまであった行が無くなっていた場合のエラー処理などを、独自に盛り込む必要があります。


> そこでCusorLocationをクライアントに設定しました。
CursorLocationをadUseClientに設定した場合は、CursorTypeプロパティは
adOpenStatic(静的カーソル)専用となります。
(それ以外のCursorTypeを指定しても、無視されます)

adOpenStaticでは、「SELECTした時点でのデータのコピー」が返されますので、
「Openした時点での件数」が、RecordCountプロパティから正しく取得されます。

逆に言うと、adUseServerモードであっても、adOpenStaticであれば
RecordCountプロパティは、常にOpenした時点での件数を返すようになります。

ただしadOpenStaticは、あくまでデータの静的コピーですから、
他のユーザーが追加/編集したレコードはRecordsetには反映されない事になります。
# Requery/Resync/Update等のメソッドを使えば反映されますけど。


> そこで、CursorLocationをクライアントに設定した場合と
adUseClientでは、データの整合性チェックが(クライアントPC上の)ADO側で行われます。
このため、ADOの持つ「Sort プロパティ」などの高機能なカーソルサービスを利用できます。
また、バッチ更新モードを使うことにより、クライアント側で複数レコードを編集しておき、
それを後から、UpdateBatchメソッドで一括して反映させるような使い方さえ可能になります。

ただし、adOpenStaticしか使えなくなるという仕様上、Open時にはデータの静的コピーを
生成する必要があるため、データ件数が多い場合にはパフォーマンスが著しく低下します。


一方、adUseServerでは、任意のCursorTypeを選択できるという利点があります。
(ただしOLE DB Providerが、それらのCursorTypeをサポートしていれば、ですけど)
たとえば、「ファイアホース(消火栓の放水ホース)」とも呼ばれる、大量のデータを
効率よく取得できるモードにするために、CursorType/LockTypeプロパティに
adOpenForwardOnly/adLockReadOnlyを指定する事ができます。

adUseServerでは、カーソル管理はデータベース側で行われますので、
パフォーマンス面では有利になります。ただし、サーバ側でカーソル管理が行われるため、
サーバ側のリソース消費量は増大します。また、データ更新のたびに通信が発生する事に
なりますので、ダイアルアップなどの低速なネットワークの場合は都合が悪いです。


CursorLocation / CursorType / LockType の3プロパティというのは、
それぞれ、意味があって複数のパターンが用意されているものですから、
ヘルプ等で動作を調べた上で、それぞれの違いを「実際に試して」、
どのように使い分けるべきかを良く把握しておいてください。

これらのプロパティは、利用している OLE DB Provider によって、
使用可能な組合せが異なりますので、予め実験して確認しておかないと、
意味の無い組合せを指定してしまう事にもなりかねませんからね。

魔界の仮面弁士さん
詳しく教えていただきありがとうございました。
考えの中に大変プラスになりました。

そこでもう1つ悩んでいる事があります。
CusorLocationをクライアントに設定した場合は
サーバーのレコードの排他orロックは出来るのでしょうか。
1台のクライアントで参照している時は他のマシンからレコードの取得を
拒否させたいと考えています。

もしこの投稿をご覧になりましたらよろしくお願いします。

> サーバーのレコードの排他orロックは出来るのでしょうか。
ROWLOCK, UPDLOCK を使えば OK かと。


> 1台のクライアントで参照している時は他のマシンからレコードの取得を
> 拒否させたいと考えています。
更新せずに参照だけしている場合も、他のユーザを拒否する必要があるのでしょうか?

ペシミシティックロックという意味であれば、adLockPessimistic にて実現できますが、
ユーザの離籍による長時間ロックや、それに伴うデッドロックの原因となりやすいので、
使い所を十分に吟味し、普段はオプティミスティックロックで編集されることをおすすめします。

> 1台のクライアントで参照している時は他のマシンからレコードの取得を
> 拒否させたいと考えています。

楽観的ロックでいいじゃん！
hhttp://blogs.sqlpassj.org/akiraonishi/archive/2004/10/19/5026.aspx

というのが考えのプラスになれば幸いです。

みなさん　ありがとうございます。
色々と実験してみます。