| 投稿日 | ： 2005/02/28(Mon) 09:57 |
| 投稿者 | ： 魔界の仮面弁士 |
| Ｅメール | ： |
| ＵＲＬ | ： |
| タイトル | ： むしろCursorTypeプロパティに注意してください |
> 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 によって、
使用可能な組合せが異なりますので、予め実験して確認しておかないと、
意味の無い組合せを指定してしまう事にもなりかねませんからね。