2,735
社区成员
发帖
与我相关
我的任务
分享务虚讨论：VFP 中的远程数据访问方案
将来是我提出：
ado 和通过odbc支持的passth ，remote view的优势和缺点？如何选择使用？是否可以通过类的封装是这三种方式协调配合？
ado 和通过odbc支持的passth ，remote view的优势和缺点？如何选择使用？是否可以通过类的封装是这三种方式协调配合？
...全文
请发表友善的回复…
发表回复
coolyylu 2002-11-03
- 打赏
- 举报
你把你的qq告诉我，有空互相讨论
hxcj 2002-11-02
- 打赏
- 举报
我同意ODBC速度不低于其他连接方式的的观点，虽然我只在VFP6下读取（不写到远程数据）数据。
例如我在VFP下通过ODBC建立远程试图，只在需要使用的时候使用select * from database!view to tabl的方式访问远程数据，其读取速度并不低于用PB编写的通过直接连接的方式某些程序。
另外上述观点中我不支持使用大量临时表的做法，甚至是层层嵌套的使用。这对查询速度影响太大！
例如我在VFP下通过ODBC建立远程试图，只在需要使用的时候使用select * from database!view to tabl的方式访问远程数据，其读取速度并不低于用PB编写的通过直接连接的方式某些程序。
另外上述观点中我不支持使用大量临时表的做法，甚至是层层嵌套的使用。这对查询速度影响太大！
net_steven 2002-11-02
- 打赏
- 举报
coolyylu(将来是我) : 有没有私有datasession互访的例子给我一个？
wbd21@21cn.com,先谢了！
wbd21@21cn.com,先谢了！
st_2000 2002-11-01
- 打赏
- 举报
大家继续说吧，我在看。。。。。。
fbilo 2002-11-01
- 打赏
- 举报
大家别的都说的很好，只是对ODBC和OLE DB的关系有点误解，请注意：OLE DB绝非ODBC的升级版，也并没有什么革命性的优势！在操作关系型数据库的性能、效率并没有区别，至少，现在还从没看到过哪个资料说OLE DB访问远程数据比ODBC快的，相反，我们自己做过的许多测试表明，ODBC操作远程数据的速度远超过我们的想象，基本上没有性能的瓶颈——通常我们认为ODBC访问远程数据的速度只受网络带宽的限制！
与ODBC相比，OLE DB的优势在于访问非关系型数据源的能力，所谓非关系型数据源指的是HTML文件、Outlook 数据、文本文件这样的东西。ADO则是提供了一套完整的能够访问各种 OLE DB数据源的面对对象化的接口。微软提倡在所有的MS 开发工具中都使用ADO来操作OLE DB，因此，VFP不可能再自己另搞一套。
与ODBC相比，OLE DB的优势在于访问非关系型数据源的能力，所谓非关系型数据源指的是HTML文件、Outlook 数据、文本文件这样的东西。ADO则是提供了一套完整的能够访问各种 OLE DB数据源的面对对象化的接口。微软提倡在所有的MS 开发工具中都使用ADO来操作OLE DB，因此，VFP不可能再自己另搞一套。
xiaowei_2002 2002-11-01
- 打赏
- 举报
关注ing...
net_steven 2002-11-01
- 打赏
- 举报
颇有深度的讨论，获宜非浅，学习。只是还不太理解“通过交换DataSessionID”
解决两个工作期数据访问问题，回去研究一下。希望继续有好dd砸过来！
解决两个工作期数据访问问题，回去研究一下。希望继续有好dd砸过来！
coolyylu 2002-10-21
- 打赏
- 举报
to rushmore ：
你说的有道理 。的确vfp在数据处理这一块面向对象的特性还不特别明显。vfp中，唯一一个用于存储数据的对象，就是通过scatter name oDataObject产生的数据对象 ，这个对象类似结构一样，其实应该不叫对象 ，只有成员变量 ，引用方式类似对象的引用 ，这个对象没有方法。好像以session类为数据单位 ，来代替sctter name 产生的对象（一般包含这个对象的引用，然后在session的子类加入特殊的方法） ，从而实现一些数据处理的机制 ，这个方法好像可行 ，但是没有真正的在大的系统里试验。
我也同意CursorAdapter是cursor的子类的猜测 ，因为我觉得CursorAdapter在功能上提供了接口 ，那么就是说在vc＋＋里面重载了DataSource 这个属性（其实对应vc＋＋，属性就是方法） ，提供了一些转换能力 ，如果我们自己写这个类，类似从xml选择数据 ，产生临时表的接口，那么通过xmltocursor ,产生一个大的临时表 ，然后再从这个临时表执行selectcmd的语句选择出一个临时表。。临时从ado里筛选出数据的思想是一致的，等拿到vfp8 beta可以看看转换的速度 ，这是很关键 ，自己的封装的类速度上比不上自带的类。
自从vfp引入数据工作期以后 ，带来很多好处，但是在系统的结构上也引起了变化。对于两个拥有不同工作期的对象在交换数据时，通过交换DataSessionID可以使到对象A可以处理对象B所在的工作期 ，应该这样子将 ，对象永远是在当前工作期中工作 ，处理数据.
你说的有道理 。的确vfp在数据处理这一块面向对象的特性还不特别明显。vfp中，唯一一个用于存储数据的对象，就是通过scatter name oDataObject产生的数据对象 ，这个对象类似结构一样，其实应该不叫对象 ，只有成员变量 ，引用方式类似对象的引用 ，这个对象没有方法。好像以session类为数据单位 ，来代替sctter name 产生的对象（一般包含这个对象的引用，然后在session的子类加入特殊的方法） ，从而实现一些数据处理的机制 ，这个方法好像可行 ，但是没有真正的在大的系统里试验。
我也同意CursorAdapter是cursor的子类的猜测 ，因为我觉得CursorAdapter在功能上提供了接口 ，那么就是说在vc＋＋里面重载了DataSource 这个属性（其实对应vc＋＋，属性就是方法） ，提供了一些转换能力 ，如果我们自己写这个类，类似从xml选择数据 ，产生临时表的接口，那么通过xmltocursor ,产生一个大的临时表 ，然后再从这个临时表执行selectcmd的语句选择出一个临时表。。临时从ado里筛选出数据的思想是一致的，等拿到vfp8 beta可以看看转换的速度 ，这是很关键 ，自己的封装的类速度上比不上自带的类。
自从vfp引入数据工作期以后 ，带来很多好处，但是在系统的结构上也引起了变化。对于两个拥有不同工作期的对象在交换数据时，通过交换DataSessionID可以使到对象A可以处理对象B所在的工作期 ，应该这样子将 ，对象永远是在当前工作期中工作 ，处理数据.
rushmore 2002-10-21
- 打赏
- 举报
To 将来是我：
我们一直说，VFP 对数据的处理是面向过程的，其实这话的核心就是对 Cursor 的处理是过程化的。
另外 VFP 里有一个 Cursor 类，这个东西与 Cursor（光标）的关系是很微妙的，按常理说一个 Cursor 类的实例对应一个 cursor 光标，但是 VFP 里不是这样的，cursor 类实例指向一个 cursor 光标，但不包含 cursor 光标。所以在对象化开发时，传递 cursor 类实例并不能一并传递 cursor 光标！！！
另外 cursor 光标是数据工作期相关的，如果在对象化开发时，两个对象使用不同的数据工作期，传递 cursor 光标是很困难的事情！
归根到底，VFP 是这样理解这个问题的：
cursor 类的生命周期、作用范围参照普通对象的模式。
cursor 光标的生命周期、作用范围是根据数据工作期的，数据工作期严格屏蔽 cursor 光标！
作为对象，cursor 类实例虽然可以自由传递，但是它不包含数据集合！
我觉得，CursorAdapter 是 Cursor 类的一个变种（子类，可能 VFP 不会明说）。所以他继承了 cursor 类的特性，例如 能够与加入数据环境……
如果是这样，CursorAdapter 产生的 cursor 光标与 cursorAdapter 的对象实例的关系就像 cursor 对象与 cursor 光标那样！
我们一直说，VFP 对数据的处理是面向过程的，其实这话的核心就是对 Cursor 的处理是过程化的。
另外 VFP 里有一个 Cursor 类，这个东西与 Cursor（光标）的关系是很微妙的，按常理说一个 Cursor 类的实例对应一个 cursor 光标，但是 VFP 里不是这样的，cursor 类实例指向一个 cursor 光标，但不包含 cursor 光标。所以在对象化开发时，传递 cursor 类实例并不能一并传递 cursor 光标！！！
另外 cursor 光标是数据工作期相关的，如果在对象化开发时，两个对象使用不同的数据工作期，传递 cursor 光标是很困难的事情！
归根到底，VFP 是这样理解这个问题的：
cursor 类的生命周期、作用范围参照普通对象的模式。
cursor 光标的生命周期、作用范围是根据数据工作期的，数据工作期严格屏蔽 cursor 光标！
作为对象，cursor 类实例虽然可以自由传递，但是它不包含数据集合！
我觉得，CursorAdapter 是 Cursor 类的一个变种（子类，可能 VFP 不会明说）。所以他继承了 cursor 类的特性，例如 能够与加入数据环境……
如果是这样，CursorAdapter 产生的 cursor 光标与 cursorAdapter 的对象实例的关系就像 cursor 对象与 cursor 光标那样！
liuri璇玑 2002-10-21
- 打赏
- 举报
好文，留个脚印，呵呵
coolyylu 2002-10-21
- 打赏
- 举报
To rushmore ：
谢谢。看着这两篇文章很精彩。vfp8的确解决了在vfp7封装多种数据源的问题。要在vfp7里象CursorAdapter这个类封装多种数据源，的确不容易。
这个类和vfp6，vfp7的cursor类在应用上的区别和共同特性应该好好研究。
另外我发现这个类是不带数据工作期的，数据是默认开放的。最后的结果形成一个临时表 ，如果还有对应一个recordset是最好了。可以从两方面更新数据。。如果没有这些功能都需要自己来封装。。
谢谢。看着这两篇文章很精彩。vfp8的确解决了在vfp7封装多种数据源的问题。要在vfp7里象CursorAdapter这个类封装多种数据源，的确不容易。
这个类和vfp6，vfp7的cursor类在应用上的区别和共同特性应该好好研究。
另外我发现这个类是不带数据工作期的，数据是默认开放的。最后的结果形成一个临时表 ，如果还有对应一个recordset是最好了。可以从两方面更新数据。。如果没有这些功能都需要自己来封装。。
rushmore 2002-10-21
- 打赏
- 举报
MS 早就嚷着要改进 VFP 对 SQL Server 的支持。
有的人只是简单的以为，这种改进只针对 SQL Server，这时不对的——VFP 是 Windows 平台下通用的数据库开发系统，除了针对 DBF 系列有特别的优化以外，一般不会偏于其他某一个数据库！
在我们猜测 VFP 8 对远程数据访问（不使用“对 SQL Server 的支持”）的改进时，我原先的想法是这样的：
可能一：提供一种基于 OLE DB 的全新的解决方案（类似于用 OLE DB 代替远程视图和SPT 用的 ODBC）
可能二：像 VB 6 那样的程度提供对ADO支持。
我本人偏向第一种情况！
……
VFP 8 beta 发布以后，看了一些文档，发现我的预测是错误的！MS 并没有像我期望的那样更换 VFP 访问远程数据的基础引擎（我的两种猜测都是用 OLE DB 换 ODBC ，只是表现不同），MS 的方案更平和，提供了更好的向下兼容性。这就是 CursorAdapter 类，这时一个新的 base class,我对他的认识概括起来是一句话：
&& 提供一种标准接口封装VFP现有的 5 种数据访问方案！！！
所谓 4 种数据访问方案，是这样理解的：
1.传统的 访问 DBF 系列数据的方式：use table...
2.传统的基于 ODBC 的远程视图
3.传统的基于 ODBC 的 SPT
4.基于 OLE DB 的 ADO
5.基于 XML 的 COM 组件或者 Web Service
6.各种自定义方式
所以，远远不止 5 种！
CursorAdapter 核心功能就是提供任意数据源到传统 VFP Cursor(游标、光标)的转换，这种转换时需要用户自己进行的，它的特色是转换的代码可以很规整的嵌入这个 CursorAdapter 中，这就是前面说的：一种标准接口！
可以这样认为，在任意数据源到 cursor 的转化过程中，CursorAdapter 什么都没有作，一切还是用户自己用代码完成，该对象只是给出了一个完美、统一的借口封装！
看几个例子：
例一：本地数据
Define CLASS CustomersData as CursorAdapter
*-- Let's define the DataSourceType as "Native" (VFP data)
DataSourceType="Native"
*-- Let's define the name of the alias that should be created.
Alias="curCustomers"
*-- Let's define the command that will generate the data to fill the cursor.
SelectCmd = "select * from Customer"
Procedure Init
*-- Once the object is created, let磗 fill the cursor.
this.CursorFill()
EndProc
EndDefine
使用：
oCustomersData = CreateObject("CustomersData")
Browse
例二（SPT）：
Define CLASS CustomersData as CursorAdapter
*-- Now, we want to define the type of the data source as ODBC
DataSourceType="ODBC"
Alias="curCustomers"
*-- We can define a "Cursor Schema"
CursorSchema = ;
"customerid c(5),companyname c(30),contactname c(30),"+;
" contacttitle c(30), address c(30), city c(30), country"+;
" c(30)"
SelectCmd = ;
"select customerid, companyname, contactname, "+;
" contacttitle, address, city, country from Customers"
*-- Remember the CursorSetProp() function? :)
Tables = "Customers"
KeyFieldList = "customerid"
UpdatableFieldList = "companyname"
UpdateNameList = "companyname customers.companyname"
Procedure Init
*-- Add a property at run-time that holds a Connection Handle.
This.AddProperty('Connection',;
SQLSTRINGCONNECT(;
"Driver=SQL Server;Server=(local);"+;
"Description=Northwind, Int Security;"+;
"DATABASE=Northwind;uid=sa;pwd=;"))
*-- The data source is our Connection Handle
This.DataSource = This.Connection
This.CursorFill()
EndProc
EndDefine
例三（WEB Service）：
Define CLASS WishListData as CursorAdapter
*-- Time to set the source type to "XML"!
DataSourceType="XML"
Alias="curWishList"
Procedure Init
*-- Set the SelectCmd property to the method
*-- that will return some XML data.
This.SelectCmd = "this.GetXml()"
*-- Fill the cursor.
This.CursorFill()
EndProc
Procedure GetXml
*-- Access our beloved UT磗 Web Service over ther Internet
*-- and get some data, Sir!
loUniversalThread=Createobject("mssoap.soapclient30")
loUniversalThread.mssoapinit(;
"http://www.universalthread.com/WebService/VisualFoxPro.wsdl")
lcUsername='MyUser'
lcPassword='MyPassword'
loUniversalThread.Login(lcUsername,lcPassword)
lcXML=loUniversalThread.GetWishList(DATE()-20)
RETURN lcXML
EndProc
EndDefine
例四：(ADO)
Define CLASS CustomersData as xCursor
Procedure Init
*-- Our Source Type now is "ADO"
This.DataSourceType = "ADO"
*-- We磍l add a property to store an ADO Connection object.
This.AddProperty('oConn',;
NewObject("ADODB.Connection"))
*-- And another property to store an ADO RecordSet object.
This.AddProperty('oRS',;
NewObject("ADODB.Recordset"))
*-- We磍l set the Connection String for the Connection object,
*-- as we磖e quite used to.
This.oConn.ConnectionString = ;
"Provider=SQLOLEDB.1;"+;
"Initial Catalog=Northwind; Data Source=lassalanotebook;uid=sa;pwd=;"
*-- ...and open the connection.
This.oConn.Open()
*-- Let磗 set this newly created connection as the Active Connection
*-- for our RecordSet object.
This.oRS.ActiveConnection = This.oConn
*-- ...and set the RecordSet as the data source for this Cursor Adapter.
This.DataSource = This.oRS
*-- This is our command to bring our data.
This.SelectCmd = ;
"select customerid, companyname, contactname, "+;
"contacttitle, address, city, country from customers"
*-- And fill up our Cursor with data, big boy!
This.CursorFill()
EndProc
EndDefine
这些代码是从UT里Copy过来的，等大家拿到 VFP 8 beta 以后再仔细研究此对象，我敢肯定，这个 cursorAdapter 是以后我们经常讨论的话题，无论多么复杂的代码放在眼前，既注意点：它只不过 提供一种标准接口封装VFP现有的 5 种数据访问方案,这样就抓住了问题的本质和精髓！
另外，CursorAdapter 还支持数据环境，这样就可以集成最新的技术到真正的开发中去了！
有的人只是简单的以为，这种改进只针对 SQL Server，这时不对的——VFP 是 Windows 平台下通用的数据库开发系统，除了针对 DBF 系列有特别的优化以外，一般不会偏于其他某一个数据库！
在我们猜测 VFP 8 对远程数据访问（不使用“对 SQL Server 的支持”）的改进时，我原先的想法是这样的：
可能一：提供一种基于 OLE DB 的全新的解决方案（类似于用 OLE DB 代替远程视图和SPT 用的 ODBC）
可能二：像 VB 6 那样的程度提供对ADO支持。
我本人偏向第一种情况！
……
VFP 8 beta 发布以后，看了一些文档，发现我的预测是错误的！MS 并没有像我期望的那样更换 VFP 访问远程数据的基础引擎（我的两种猜测都是用 OLE DB 换 ODBC ，只是表现不同），MS 的方案更平和，提供了更好的向下兼容性。这就是 CursorAdapter 类，这时一个新的 base class,我对他的认识概括起来是一句话：
&& 提供一种标准接口封装VFP现有的 5 种数据访问方案！！！
所谓 4 种数据访问方案，是这样理解的：
1.传统的 访问 DBF 系列数据的方式：use table...
2.传统的基于 ODBC 的远程视图
3.传统的基于 ODBC 的 SPT
4.基于 OLE DB 的 ADO
5.基于 XML 的 COM 组件或者 Web Service
6.各种自定义方式
所以，远远不止 5 种！
CursorAdapter 核心功能就是提供任意数据源到传统 VFP Cursor(游标、光标)的转换，这种转换时需要用户自己进行的，它的特色是转换的代码可以很规整的嵌入这个 CursorAdapter 中，这就是前面说的：一种标准接口！
可以这样认为，在任意数据源到 cursor 的转化过程中，CursorAdapter 什么都没有作，一切还是用户自己用代码完成，该对象只是给出了一个完美、统一的借口封装！
看几个例子：
例一：本地数据
Define CLASS CustomersData as CursorAdapter
*-- Let's define the DataSourceType as "Native" (VFP data)
DataSourceType="Native"
*-- Let's define the name of the alias that should be created.
Alias="curCustomers"
*-- Let's define the command that will generate the data to fill the cursor.
SelectCmd = "select * from Customer"
Procedure Init
*-- Once the object is created, let磗 fill the cursor.
this.CursorFill()
EndProc
EndDefine
使用：
oCustomersData = CreateObject("CustomersData")
Browse
例二（SPT）：
Define CLASS CustomersData as CursorAdapter
*-- Now, we want to define the type of the data source as ODBC
DataSourceType="ODBC"
Alias="curCustomers"
*-- We can define a "Cursor Schema"
CursorSchema = ;
"customerid c(5),companyname c(30),contactname c(30),"+;
" contacttitle c(30), address c(30), city c(30), country"+;
" c(30)"
SelectCmd = ;
"select customerid, companyname, contactname, "+;
" contacttitle, address, city, country from Customers"
*-- Remember the CursorSetProp() function? :)
Tables = "Customers"
KeyFieldList = "customerid"
UpdatableFieldList = "companyname"
UpdateNameList = "companyname customers.companyname"
Procedure Init
*-- Add a property at run-time that holds a Connection Handle.
This.AddProperty('Connection',;
SQLSTRINGCONNECT(;
"Driver=SQL Server;Server=(local);"+;
"Description=Northwind, Int Security;"+;
"DATABASE=Northwind;uid=sa;pwd=;"))
*-- The data source is our Connection Handle
This.DataSource = This.Connection
This.CursorFill()
EndProc
EndDefine
例三（WEB Service）：
Define CLASS WishListData as CursorAdapter
*-- Time to set the source type to "XML"!
DataSourceType="XML"
Alias="curWishList"
Procedure Init
*-- Set the SelectCmd property to the method
*-- that will return some XML data.
This.SelectCmd = "this.GetXml()"
*-- Fill the cursor.
This.CursorFill()
EndProc
Procedure GetXml
*-- Access our beloved UT磗 Web Service over ther Internet
*-- and get some data, Sir!
loUniversalThread=Createobject("mssoap.soapclient30")
loUniversalThread.mssoapinit(;
"http://www.universalthread.com/WebService/VisualFoxPro.wsdl")
lcUsername='MyUser'
lcPassword='MyPassword'
loUniversalThread.Login(lcUsername,lcPassword)
lcXML=loUniversalThread.GetWishList(DATE()-20)
RETURN lcXML
EndProc
EndDefine
例四：(ADO)
Define CLASS CustomersData as xCursor
Procedure Init
*-- Our Source Type now is "ADO"
This.DataSourceType = "ADO"
*-- We磍l add a property to store an ADO Connection object.
This.AddProperty('oConn',;
NewObject("ADODB.Connection"))
*-- And another property to store an ADO RecordSet object.
This.AddProperty('oRS',;
NewObject("ADODB.Recordset"))
*-- We磍l set the Connection String for the Connection object,
*-- as we磖e quite used to.
This.oConn.ConnectionString = ;
"Provider=SQLOLEDB.1;"+;
"Initial Catalog=Northwind; Data Source=lassalanotebook;uid=sa;pwd=;"
*-- ...and open the connection.
This.oConn.Open()
*-- Let磗 set this newly created connection as the Active Connection
*-- for our RecordSet object.
This.oRS.ActiveConnection = This.oConn
*-- ...and set the RecordSet as the data source for this Cursor Adapter.
This.DataSource = This.oRS
*-- This is our command to bring our data.
This.SelectCmd = ;
"select customerid, companyname, contactname, "+;
"contacttitle, address, city, country from customers"
*-- And fill up our Cursor with data, big boy!
This.CursorFill()
EndProc
EndDefine
这些代码是从UT里Copy过来的，等大家拿到 VFP 8 beta 以后再仔细研究此对象，我敢肯定，这个 cursorAdapter 是以后我们经常讨论的话题，无论多么复杂的代码放在眼前，既注意点：它只不过 提供一种标准接口封装VFP现有的 5 种数据访问方案,这样就抓住了问题的本质和精髓！
另外，CursorAdapter 还支持数据环境，这样就可以集成最新的技术到真正的开发中去了！
rushmore 2002-10-21
- 打赏
- 举报
下次讨论 VFP 8 带来的新气象
rushmore 2002-10-21
- 打赏
- 举报
站在 VFP 7 的立场看 ADO:
一般我不会选择 ADO 作为访问远程数据的解决方案，原因是这样的：
VFP 只是把 ADO 看作 COM 组件来支持，并没有集成 ADO到VFP 里去，ADO的 Recordset与VFP 的 Cursor 是相互独立的（虽然VFPCOM 组件可以做到一些转换，但远远不行）。这样在开发中就带来了一系列的麻烦，最主要的是数据绑定问题，我们不容易做到这个，开发难度就大大提高。
再来看看 ADO 的优势，ADO通过 OLE DB 访问数据，并且 ADO 比 ODBC 更新，所以只有过人之处。例如，访问ADO 能够得到 SQL Server 存储过程的返回值；ADO 对 两进制大对象有专门的解决方案；
另外，ADO 的 recordset 是一个 com 对象，所以在多层开发上，多个逻辑层次交换数据集合时，Recordset 比 VFP 的 Cursor 有极大的优势；cursor 在 VFP 里受 DataSession 的 影响，而 Recoreset 不会；VFP 的 cursor 对象并不能包含 cursor 游标的数据集。
所以，我以为 讨论 ADO 在 VFP 的优劣，核心是这两个：ADO 本身的特性；VFP 仅把 ADO 作为 COM 对象看待！
我的看法是，如果无界面的多层组件开发，ADO 可以用；而界面开发， ADO 的效果不佳，慎用作数据绑定等核心用途。
一般我不会选择 ADO 作为访问远程数据的解决方案，原因是这样的：
VFP 只是把 ADO 看作 COM 组件来支持，并没有集成 ADO到VFP 里去，ADO的 Recordset与VFP 的 Cursor 是相互独立的（虽然VFPCOM 组件可以做到一些转换，但远远不行）。这样在开发中就带来了一系列的麻烦，最主要的是数据绑定问题，我们不容易做到这个，开发难度就大大提高。
再来看看 ADO 的优势，ADO通过 OLE DB 访问数据，并且 ADO 比 ODBC 更新，所以只有过人之处。例如，访问ADO 能够得到 SQL Server 存储过程的返回值；ADO 对 两进制大对象有专门的解决方案；
另外，ADO 的 recordset 是一个 com 对象，所以在多层开发上，多个逻辑层次交换数据集合时，Recordset 比 VFP 的 Cursor 有极大的优势；cursor 在 VFP 里受 DataSession 的 影响，而 Recoreset 不会；VFP 的 cursor 对象并不能包含 cursor 游标的数据集。
所以，我以为 讨论 ADO 在 VFP 的优劣，核心是这两个：ADO 本身的特性；VFP 仅把 ADO 作为 COM 对象看待！
我的看法是，如果无界面的多层组件开发，ADO 可以用；而界面开发， ADO 的效果不佳，慎用作数据绑定等核心用途。
