在Connection物件中CursorLocation的部份
指的就是使用
那裏的記錄指標
adUseClient：使用用戶端的記錄指標，因此Cursor就用Client端所管理
adUseServer：使用伺服器端的記錄指標，因此Cursor就用Server端所管理
而CursorLocation這個屬性只有在Connection關閉的狀況下才能變更，也就是說Connection開啟了就變成了「唯讀」
CursorLocation的預設值是....adUseServer
這樣的解釋看似很簡單，但背後所代表的涵意就差很大了
這差異一下子也難以解釋清楚，筆者借用了網路上某一篇文章
這篇文章不是筆者的文章，它是來自DBmaker網站：
http://www.dbmaker.com.tw/reference/tools/ado-sgml/x164.html
文章如下
先討論 Recordset 物件的 CursorLocation 特性對其有何影響。 ADO 對游標的處理可以交由 DBMaker 處理(CursorLocation 特性值設為 adUseServer)， 或是交由 ADO 的 Cursor Engine 處理(CursorLocation 特性值設為 adUseClient)。
ADO 2.0 的 Cursor Engine 開啟記錄集的方式是將符合記錄的所有資料， 從資料庫載入到它所在的前端電腦上(請參考"2.5游標與鎖的型態")。 換句話說對記錄集的處理，除非是將資料更新回資料庫， 否則大部份的功能都和後端資料庫系統無關，而由 Cursor Engine 自行處理掉。 既然所有的資料都在前端電腦，就如同 dBase 此類的桌上型資料檔的處理方式一樣， 可以移動游標、可以對記錄集作排序(Recordset 的 Sort 特性， 若有需要 ADO 還會為記錄集建立暫時的索引檔)、支援 Bookmark 特性、 批次更新（每筆更改的記錄暫不反應到後端資料庫內容， 直到執行批次更新(UpdateBatch方法)時，才全部反應回資料庫）等等。
不過使用 ADO 2.0 的 Cursor Engine 有兩點要注意： 第一是整個記錄集經過網路傳到前端電腦，這等待的時間能不能忍受； 第二是整個記錄集都是暫存於記憶體處理， 所以必需保證記錄集的大小不能超過前端電腦可用記憶體的大小(包含實體與虛擬記憶體)。 第一個問題可以用非同步的方法擷取資料，資料傳回的過程中， 讓程式去執行別的工作。 第二個問題其實是可以用前端電腦的檔案系統來暫存超出記憶體所能容納的資料， 不知道將來的版本會不會決解此問題。讀者若有與趣， 可以將 CursorLocation 特性設為 adUseClient， 然後用 Open 方法透過網路向後端資料庫執行查詢表格指令， 並透過網路傳回超過一、二百 M 位元組資料的記錄集。 讀者就會發現透過網路傳回一、二百 M 位元組的資料其實需要一段時間， 而且電腦可用記憶體的容量將逐漸減少直到被耗盡為止。
將 CursorLocation 特性設為 adUseServer， 表示游標的實作是交由 DBMaker 來完成。認識 ODBC 介面的朋友， 對於 ODBC 的 Extended Fetch 的函數應該不陌生， ADO 2.0 的 Server Cursor 就是利用 Extended Fetch 來操作 DBMaker 資料庫。
利用 ADO 存取 DBMaker 3.5，將 CursorLocation 特性設為 Server Cursor 時， 有一些限制請 DBMaker 的使用者注意：
MaxRecords、RecordCount、AbsolutePosition、AbsolutePage、PageSize、PageCount、 Bookmark、Sort等特性沒有作用；
游標型態只支援動態型態(這也是為何上述的特性無法支援的原因)；
查詢指令含有ORDER BY子句所得到的記錄集只能讀無法更新；
不支援批次更新作業；
不支援非同步處理(但ADO提供多線串(thread)的能力來執行非同步的處理)；
不支援多重結果集(即一個執行的SQL指令，不論是查詢命令或是執行預存函數，傳回不只 一個結果集)
