Visual FoxPro 已经过时了吗
恕我直言，这样的问题我真的听腻了。这个问题我听了好几年了。从谣言出现到今天Visual FoxPro的版本已经生了两次变化，就是Visual FoxPro 6.0 与2001年春天推出的Visual FoxPro 7.0。根据微软的官方消息，Visual FoxPro 8（可能是这个名称吧）已经在研发之中了。我不敢保证是否会有Visual FoxPro 9.0（这就像我不敢保证微软是否在那时还存在一样）。可以这样认为，只要不出意外情况（比如微软倒闭、业界发生了重大的变革等），Fox就会平稳地发展！
在国外，一个程序员、一家公司把他们使用的开发工具视作一项投资，作为Visual FoxPro的开发厂商微软公司就必须保护客户的投资权益，这是很基本的商业原则，微软绝对不敢随意淘汰有着50万用户的Fox，除非永远不想赚这50万用户的钱了。
为什么会有Visual FoxPro 要淘汰的传闻呢，我不是很清楚。但这两年微软对Visual FoxPro的不宣传态度却是为这股谣言起到了推波助澜的作用。另外Visual FoxPro 确实是一个容易引起误会的产品，初级用户很容易对它产生“不怎么样的”评判，于是加上那谣言就产生了“Visual FoxPro 就真的要淘汰了”的幻觉了。
为什么说Visual FoxPro 是容易引起误会的产品呢？我总结以下几点原因：
面向对象与面向过程之争
我们说Visual FoxPro是面向对象化的语言，是有根据的。面向对象化的语言必须具备四个特性：抽象（Abstraction）、封装（Encapsulation）、继承（Inheritance）、多态（Polymorphism）。对照一下Visual FoxPro，是不是支持这四大特性！
当然，Visual FoxPro 与C++和Object Pascal 一样都是历史悠久的语言，所以语言中有很多面向过程的语素。我知道很多学校在教学中，只是教导学生们使用Visual FoxPro的面向过程的语言特色，而忽视了面向对象的教学，同样的问题也存在于广大的 Visual FoxPro 程序员中。我们必须明白：不能因为我们没有使用Visual FoxPro面向对象的强大功能，而说Visual FoxPro不是面向对象的语言，这就像不能因为天下雨、没有出太阳，而说太阳被天狗吃掉了——多么的幼稚可笑！
我们知道Visual FoxPro对数据的操作沿用了多年来的面向过程的做法，这与现在流行的开发工具有很大的不同。我觉得，微软这样做是有它的道理的：
第一，面向过程的数据处理，更能发挥XBase语言体系的灵活与随意的特色。这一点，你用过其他的数据库开发工具，然后再用用Visual FoxPro就明白了。
第二，不直接提供面向对象的数据处理组件，不代表不允许用户封装自己的数据处理组件。很多优秀的 Fox程序员，都会自己封装专门数据处理组件，这才是Visual FoxPro编程的高尚境界！
面向记录与面向集合之争
根据笔者的浅薄认知，关系型数据库处理可以分为面向记录操作和面向集合操作。
各种开发工具支持的客户端光标体系就是面向记录操作的，它们支持记录之间的绝对定位，更明白地说就是可以在记录之间导航，诸如：SKIP、GO TOP之类的语句。Visual FoxPro 无疑是此道的绝对高手，20年的语言发展，聚集了大量面向记录的语言要素。这是因为这样，我们才会反复强调：Visual FoxPro的Cursor 体系灵活、强大！
各类大型数据库，如Oracle、SQL Server 是面向集合处理的代表，看看正统的SQL 语言，绝对没有数据导航之说，数据记录之间是平等的，一切都要讲关系、摆条件！
随着技术的发展，人们开始注意到，不能分割这两种对数据的操作方式，于是大型数据库支持了游标语素，Fox也支持符合规范的SQL 语言。
产品定位导致Visual FoxPro变化不易为人们感觉。微软要把Visual FoxPro作为三层构架（或是多层构架）的中间层开发工具。
什么是三层构架呢？第一层是用户界面:它包含了用户界面,让使用者输入,输出,查询等工作；第三层是资料层:它就是用来放资料的地方,一般是指后端数据库，主要有包括 Oracle、SQL Server 等,它主要是提供一个很大的地方,来有规则的存放数据；第二层是商务逻辑层（中间层）:有人要说了：存取资料,直接从第一层跳到第二层可不可以？当然可以,没有人规定不能走捷径,而且从数据库直接抓资料,既快又好,那为什么搞出个第二层呢？
商务规则是经常变化的,比如上班从8 点改为10 点,那电脑怎那么知道老板因为不景气少让大家上二个小时班呢?它一定无法知道,你必须告诉它,这时问题就来了,如果你有很多部电脑,例如:100 台,你就得一部部换新程序。如果这是一个挂在Internet上的网络程序，难道总让用户download新程序不成？
更重要的是，在大量客户存在的环境里，传统的两层构架根本没有能力承担巨大的工作压力，必须通过某种中间系统实现压力平衡，这就是中间层的另一妙用！
中间层是没有图形界面设计的代码编写，并且是OOP方式的代码编写，不仅要熟悉后台数据库的特性，还要考虑前台界面工具的特性，最重要的是商务逻辑的构架，同时还要求懂得IIS、MTS(COM+)、NT的安全设置等复杂枯燥的东西。有趣的是，近年来 Visual FoxPro 的各种改进，更多的是在这些方面下功夫，到了最新版本的Visual FoxPro 7 更是在此方面增加了若干特性，下面就让我用四个问题来说明Visual FoxPro 在开发中间层方面的贡献：
问题一：Visual FoxPro能开发出稳定、有效率的Server程序吗？能，在1999年发布的Visual FoxPro SP 3中微软赋予了Visual FoxPro开发多线程进程的内组件的能力，并增加了新的运行时刻库VFPnT.DLL（n代表版本号），支持其运行，在这个运行库中，删除了大量老式的和界面控制元素，使得它更小巧。但是由于Visual FoxPro6本身不是很稳定（加打SP4或SP5才有所改善），所以这个很棒的功能在Visual FoxPro 6下并不能充分发挥，直到Visual FoxPro 7出现才使它的显示出英雄本色！
问题二：分布式的事务、动态负载平衡怎么实现？Visual FoxPro 7对COM+有很好的支持，借由COM+就可以解决这两个问题了！
问题三：作为Server程序，客户程序怎样与Server交换数据集合？这是Visual FoxPro 6开发的Server程序的致命弱点，我们知道Visual FoxPro是用来处理数据的，但不能与外界自由交换数据集合会大大降低开发、使用以及程序运行效率！在Visual FoxPro 7里我们XML就可以快速、轻易的传递大型数据集合，真正做到数据集的来去自由。现在回想Visual FoxPro 6中我们用的那种“循环+属性”的做法，真有天上与人间的感受！
问题四：能不能让Visual FoxPro开发的Server任由客户使用，叫干什么就干什么？可以的，在Visual FoxPro 7里提供了一个全新的函数：ExecScript()。有了它，就可以一次执行多条客户端送来的符合Visual FoxPro规范的语句：你可以定义变量、做查询、更新数据、修改表结构……
微软确实实践着让Visual FoxPro在中间层运行的承诺。但遗憾的是：由于国内用户的水平、国内软件应用的领域，对大多数Fox Fans 无法感受Visual FoxPro日新月异的变化——对他们来说，Visual FoxPro确实“没有改变”！
Visual FoxPro 只能局限于桌面应用程序的开发吗？
技术在进步，软件技术的应用不断在拓宽，Internet 已经是众多开发工具竞相支持的应用领域。Visual FoxPro 从版本 5 开始不断扩充对Internet的支持，到最新的Visual FoxPro 7 更是增加了对Web Service的支持。我们可以把Visual FoxPro 对Internet的支持分为三大部分：
第一，简单的HTML的转换。Visual FoxPro 自带的“Web 发布”就是这类型的工具，利用HTML和DHTML的模版，支持Visual FoxPro数据的Web化，这是一种全静态的 Web 支持。
第二，适合于企业内部使用的 Active Document 技术。是不是希望快速、简单的把Visual FoxPro应用程序转变为Web 应用程序，这个Active Document 技术就是最佳的选择。它支持 App 程序运行在IE中，它的缺点是：在客户端必须安装Visual FoxPro的运行库、客户端与数据库间依然是紧密的有状态的关系，属于F/S构架——只是界面能够运行在IE之中了。它的开发快速以及它依然基于传统构架，决定了这个技术只能运行在企业内部，一般不能在广域网络中发布。
这技术是Visual FoxPro 6提出的，当时在 Tool 菜单里还有一个专门的菜单项。到了而今的Visual FoxPro 7，这个菜单项已经取消了，但并不是说Visual FoxPro 7 不支持Active Document，只是这种并不出色的技术没有必要再放在醒目的位置了。
第三，基于COM 的 Web 应用。
Visual FoxPro 真正能被用于Web 开发，就是通过 COM 支持的。
这里您要有个认识，作为数据库开发工具，Visual FoxPro 不是FronPage这样的用于开发Web 界面的工具（也许未来的 Visual FoxPro 会支持 Web 界面的开发）。Visual FoxPro 完全是作为 Server 运行在网站的后台，为各种应用提供服务。使用 Visual FoxPro 编写的 COM 组件能够被IIS支持，压在后台进行各种运作——这就是真正意义上的Visual FoxPro 的Web应用，也是典型的多层构架的中间层！
这个阶段，Visual FoxPro 对 Web的支持有可以划分为三个层次：
- FoxISAPI。
这是最先登场的技术，当年 ASP 技术还没有出现的时候，我们在 IIS 里就可以通过 ISAPI 技术实现动态网页开发。 - Web Server
ASP 技术出现了，我们知道 ASP 技术的一大特色就是支持服务器端的组件的应用。用 Visual FoxPro 的编写的 COM 组件就能运行在 IIS 里，供 ASP 调用。 - Web Service
这是 Visual FoxPro 7 的新特性，也是当前最热门的技术。它与Web Service的最大不同就是：Web Server 组件只能通过 ASP 程序调用，而Web Service可以供任何系统在全球范围调用，无论客户端的硬件平台、软件平台，只要它支持SOAP、支持XML就可以了。
更夸张一点说：只要能上网，就可以享用 Web Service 提供的服务！
有人也许会问：我可以用VB、VC++建立对象组件时，为何我要用Visual FoxPro 来建立相同的组件? 微软对这一问题有专门的评论，大意为：快、重复使用性、跨语言重复使用性。“快”是指用Visual FoxPro开发的组件撷取、处理资料都极为迅速，并且Visual FoxPro能够非常迅速的建立字符串。到底有多快，我想数据处理、存取的速度大家平时都领教过了，字符串生成速度我这里有个数据不妨一看，这是台湾的一位高手做的试验——将1M的数据写入文本中，结果VC++ 6.0程序用了3.5秒、VB 6.0程序用了11秒、Java 1.1.5用了24秒、Visual FoxPro 6.0用了7秒；“重复使用性”是指Visual FoxPro具备OOP的功能；“跨语言重复使用性”是指Visual FoxPro编写的对象编译以后成为COM、COM+对象组件，这样就可以在其他语言中使用它了。
不要以为Visual FoxPro是“低端产品",无论从数据库（DBF Base）品质还是开发环境评价Visual FoxPro，它都是一个“高端工具”。
许多人认为Visual FoxPro只能用来开发单用户系统或是文件服务器构架的小型网络系统——这是谬误——这种无知的言论在许多讲C/S、三层构架的书中都有（特别是一些VB、PB、Delphi的数据库编程书）。我可以很负责任的告诉大家完全可以用Visual FoxPro开发C/S结构的系统。这里说的C/S构架绝对是正宗的，不是用什么F/S构架在糊弄大家。在C/S构架中我们常常选择Visual FoxPro作为客户端开发工具，以Oracle、SQL Server等网络数据库压在后台，使用Visual FoxPro内置的Remote View和SPT技术,这样就可以完美地解决问题。这里不能详细展开,只特别介绍Visual FoxPro的本地引擎在开发中的作用。Visual FoxPro的本地引擎特别强大（上文我们说过处理百万条记录不费吹灰之力），我们在设计系统时可以十分简单的将远程数据与本地数据结合，很简单、很有效地控制网络数据流量、提高系统工作效率（我看过不少VB、Delphi、PB的书，他们很少在怎样控制网络数据流量、提高系统工作效率论述，不知是不屑一顾，还是其他什么原因）。
我认为Visual FoxPro的本地引擎在C/S构架下起码有三项伟大的用途。其一：非经常变动数据的本地存储。我国的邮政编码与地区的关系是相对稳定的数据，而且数据量也不是太小，我想总有上千个记录（我没仔细考察过具体情况），我们把这些信息存储在客户端的计算机中，就可以在使用邮政编码及其相关信息时从本地得到数据，这样能使高系统效率同时节省网络资源（这是C/S开发的重要原则），只在邮政编码发生变化时在服务器上统一更新，下载更新客户机上的数据。如果用别的软件实现同样的功能，绝对比Visual FoxPro麻烦而且效果绝对不及Visual FoxPro，这因为Visual FoxPro的数据引擎直接支持远程数据读取，能很好的融合本地数据与远程数据；其二：离线数据包。单位里总有人出差，在千万里路之外能不能拿着笔记本为客户发订单、与客户签合同，就像在自己的办公室一样？当他回到公司时只要把笔记本连到服务器中，发送更新就行了。Visual FoxPro的离线视图是经济且高效安全的方案（当然您可以使用远程拨入或建一个Web网站，这些Visual FoxPro可能干）。其实离线数据包还有一个重要的功能：当下载的数据是大量的（除非万不得已请不要这样设计系统），这种情况下使用离线视图可以数据集自动转化为物理表，充分利用Visual FoxPro的高速与灵活，完成后连线更新后端数据源——一切都很简单。我认为：离线视图绝对是Visual FoxPro在C/S系统中的一个卖点，虽然ADO也支持类似的东西，但肯定不及Visual FoxPro有效率；其三：数据驱动。您是否知道，Visual FoxPro中绝大多数文件格式实际上都是DBF文件，如DBC、SCX、FRX等，他们都可以由Visual FoxPro的本地引擎驱动完成复杂的任务。在设计C/S结构时如果要存储用户设置、自定义文件格式，用Visual FoxPro的本地引擎帮忙绝对比其他软件简单，因为你用的是换汤不换药的方法，但它简单、有效率。
Visual FoxPro 开发C/S系统时，最与众不同的特色就是对远程数据的操控是通过本地数据库来实现的，Remote View、Connection都作为本地数据库的对象被管理起来，完美的衔接本地数据与远程数据。这种在客户端建立远程数据逻辑的做法，与最新的ADO.NET有相似之处！
在三层构架中，Visual FoxPro可以充当任意一层的任务，但本人以为大中型系统的数据库部分应以网络数据库为主。客户端界面用Visual FoxPro也是可以的，但一般限于企业内部，在Internet上我们通常使用IE作为客户界面。在三层构架中Visual FoxPro最胜任中间层的开发,它简单（开发难度与普通的Visual FoxPro项目相差不大）、快速的字符串生成、支持COM技术、它支持（MTS）COM+技术、它支持XML（Visual FoxPro 7.0提供3个与XML有关的函数）、它具有强大本地数据引擎、灵活的数据处理方式、它支持多线程的服务组件的开发。
可能有人要问：用ASP+脚本语言一样可以开发Web系统，何必加个中间层。的确，目前在市面上与多讨论Web的书都直接使用脚本语言来开发整个系统，这是十分不正确的做法，甚至有写书还说硬件越来越快，因此使用脚本语言来开发整个系统并没有什么关系。会说出这样话的作者通常都是没有实际开发Web应用经验的人。脚本语言，如VBScript是一种解释性语言，运行效率很低，他们只合适作为胶水程序。开发Web系统正统的做法是：把应用逻辑编写成COM、DCOM对象，然后用少量的脚本语言来驱动/使用这些对象。这样系统开发时工作量会大一些，但它符合开发任何数据库应用程序的最基本的原则：分离应用逻辑与用户界面。这样系统就会变的容易维护了——你可以经常变换那些胶水程序来改变Web页面，应用逻辑变换时你又可以改变某一个逻辑对象，而不用为杂乱且关系复杂的代码发愁。再者，由于Visual FoxPro是高效、灵活的数据处理语言，任何商业逻辑都可以用它来代码化，并且您可以获得几十倍甚至上百倍于ASP+脚本语言的运行效率，以及更为强健的执行效果。
Visual FoxPro 的语言看上去蛮难的。
人们在赞扬 Visual FoxPro 始终是褒扬他的易学易用，我不同意这种观点（我不知道他们站在什么立场上说话）。我看问题的角度是“成为一名还过得去的 Visual FoxPro 程序员”，我的结论是Visual FoxPro 作为一个开发工具并不是好学的。这不是说Visual FoxPro的语法、概念像C那么繁复，而是指：即使是简单的应用，也要掌握很多Visual FoxPro的概念、语法、函数，可能还要较深入了解OOP——往往让人摸不到深浅。比如，拿数据库系统最重要的功能——查询来讲，Visual FoxPro就“花样繁多”。我曾统计过，不算“List、Browse"等交互式命令，Visual FoxPro起码支持4条命令（Find,Seek,Locate,Select-SQL）、3个函数(Lookup(),Seek(),Indexseek()),（当然其中有的已经淘汰）这些命令的关键字、函数的参数众多，有的要求索引， 有的可以用索引但要求优化索引……而这在VB、Delphi中绝对就只是两三个方法的事情。从上面的例子中如果您只看到了Visual FoxPro的繁杂，那么您就完全错了：在VB、Delphi实现查询功能的原理与Visual FoxPro应是一样的，但他们封装了许多环节，而Visual FoxPro就把许多东西更低阶（当然不如VC++那么低层次，但是已经比使用对象的语言难多了）的展示给我们，所以Visual FoxPro的开发者往往比使用其他的开发工具开发者更会思考、更懂得的数据库开发的真谛，因为工具逼迫他们朝这个方向努力……
用Visual FoxPro有助于提高程序员对数据库概念的理解。许多在Visual FoxPro程序员中不是问题的问题往往成为那些使用对象处理数据的程序员的噩梦。比如在Visual FoxPro中数据缓冲、事务处理都是重要的概念（事实上要干活就必须了解这些东西），在其他开发环境中一味强调方便快速往往忽视程序员的基本概念培养，编出的东西要么效率不高、要么老出问题。读书人都懂得：基本概念、基本理论是命根子，这就是Visual FoxPro带给我们的好处。
有趣的是Visual FoxPro繁、难也就到这个程度了 ，他的学习难度曲线是所有语言中最平稳的——不像在有些语言中，基础开发十分容易，一旦深入却难度很高。在Visual FoxPro中初级应用、中级应用、高级应用的难度差异很小——就是那些似曾相识的语句、易于理解的函数。Visual FoxPro的这种高级应用不太难，初级应用不十分容易的特性，对初入门者来讲是无法体会其中的妙处的，这就造成了Visual FoxPro的不太友好形象；
同时，Visual FoxPro的难度却带来了很多的好处（前文我已谈了很多），Visual FoxPro比其他语言在数据处理上更快速、更灵活，数据处理方式更多、更完备。设想一下用Visual FoxPro开发数据对象时，我们可以使用丰富多彩的语句、函数，实现十分复杂、变化多端的功能，用其他语言开发数据对象，它们的功能只能是建立在已有的数据对象的功能之上（这叫继承），变化就少了，功能就弱了。如果要实现Visual FoxPro的Xbase+SQL 那样灵活、强大的功能恐怕要使用底层的API了——这太可怕了！
OOP不仅是指“面向对象”的开发环境，更是一种开发思想、开发技术，Visual FoxPro 在后者上做得更好。
我们讲过Visual FoxPro完全支持OOP的开发，但有趣的是在数据处理方面，微软实际上没有提供什么现成的对象（FFC是Visual FoxPro 6.0才有的，且封装性、适应性都不尽如人意），这一点我不知是Visual FoxPro的福气还是祸害。说“福气”这将逼迫程序员掌握这门并不太简单的技术（可能用“思想方法”更恰当），而不是简单地使用对象。OOP对于中间层的开发来讲是很重要的，因为COM组件必须是建立在OOP思想上的，要开发这种组件就必须掌握OOP技术；讲“祸害”这使Visual FoxPro变得不易于学习和使用了（就我个人而言，真正体会到“用Visual FoxPro应会编制数据处理对象”这一问题也是在使用了Visual FoxPro好长时间之后的事情了）。事实上现在很多诽谤攻击Visual FoxPro的人都没有深刻的认识这一问题——他们只感到Visual FoxPro用起来不及Delphi、PB、VB容易，但他们从不想该怎样开发数据处理对象，到编写COM组件时就要他们的命了。那些“精英们”大多不懂OOP，他们只懂“点”操作符号——仿佛对象的使用就是OOP，他们有什么资格来批评我们呢？
Visual FoxPro的界面能力真的很差吗？
我认为作为数据库系统的开发工具微软为我们提供的那些内置控件加上十几个附送的ActiveX控件已经够用了。
我们讨论Visual FoxPro控件应从两方面入手，第一就是界面美观问题，再就是数据处理、分析是否方便。很多人很在意的前一个问题，我倒是不以为然——控件不多特别是美化界面的控件不多并不代表Visual FoxPro就开发不出赏心悦目的软件，我的感受是软件界面的专业化程度、高级别的审美、整体的效果要比个别的界面特效重要千万倍，实际效果可要好上千万倍。看看国外用Visual FoxPro编制的程序您就会明白这个道理了；我对Visual FoxPro的不满在于数据处理、分析控件不全，特别是缺少了一批数据分析控件。比如没有可以与数据捆绑的图表控件、没有可以列示捆绑交叉表的表格控件、没有可以捆绑数据的数据透视表格控件……在这个问题上Visual FoxPro确实应该向Delphi、PB等软件学习，这是我们对未来的Visual FoxPro的期望！
Visual FoxPro与OLE DB、ADO
ADO是Windows环境下主流的数据存取的解决方案，那些以对象操作数据的语言基本上都使用ADO实现数据存取，如：VC++、VB、Delphi。在Visual FoxPro的开发环境中好像看不到ADO的影子，是不是Visual FoxPro不支持ADO呢？ADO其实是一组COM对象，Visual FoxPro支持COM，当然支持ADO。
我认为：Visual FoxPro对ADO的支持只是停留在较低的水平。这并不是说Visual FoxPro限制了什么ADO的功能（所有功能都能用），而是指：用起来不方便，不像在VB、Delphi中方便。这种不方便主要体现在ADO的Recordset无法与Visual FoxPro的内置控件捆绑。其原因是：Visual FoxPro 不认识ADO的Recordset，只能将记录逐条读取，而不是一下子认得整个Recordset。这样数据就不能被捆绑了，同时也不能对ADO直接使用Visual FoxPro强大的数据处理功能（ADO是用来存取数据而处理数据还要靠客户软件）。
就象Visual FoxPro使用ODBC连接远程数据源那样，ADO通过OLE-DB与数据提供者对话。 （By the way: Visual FoxPro 7是OLE-DB提供者，这样就可以 通过正宗的OLE-DB驱动程序在其他开发工具中使用ADO存取Visual FoxPro数据了 。）
ADO能为Visual FoxPro带来什么？首先要注意的是：ADO与Visual FoxPro的数据引擎是毫无关系的系统，从某种程度上讲ADO的出现为Visual FoxPro提供了一种全新的远程数据处理方式。
- ADO是多层应用程序中数据集合传递的最好解决方案。如果我们用Visual FoxPro开发了一个中间层系统，用VB开发了用户界面，当中间层要传递一个cursor到VB的客户端就不可以使用Visual FoxPro的cursor或DBF，因为VB不认得他们。使用ADO的Recordset就可以解决问题，因为大家都认得他；Visual FoxPro 只能通过Visual FoxPro 7支持XML后才能弥补Visual FoxPro本地引擎在应用程序传递数据集的不足。
- ADO可以存取非关系型数据库。ADO是微软的Universal Data Access构架的主将，它可以存取Excel等非关系型数据数据库的数据。通过ODBC存取远程数据的Visual FoxPro就无此能力了。但是我使用了ADO存取Excel后很失望，因为连接必须是独占的，所以这种功能带给我们的帮助只是有限的！
- ADO可以弥补Visual FoxPro在远程数据存取时的不足之处。譬如Visual FoxPro不认得SQL Server中nText、nVarchar、nChar等数据类型，但ADO可以。
在Visual FoxPro使用ADO存在如下缺点：
- Visual FoxPro只能通过COM的方式识别ADO的Recordset，不能像表格那样读写它，这样就出现了两个问题：Recordset无法与Visual FoxPro的内置控件捆绑；无法直接使用Visual FoxPro强大的数据处理功能（ADO是用来存取数据而处理数据还要靠客户软件）。
- Visual FoxPro中使用代码实现ADO的全部功能，但代码量大、书写麻烦。
对待以上不足Visual FoxPro开发小组在Visual FoxPro 6推出不久后就发布了一个叫VFPCOM.DLL的组件，可以用它部分解决ADO的Recordset与Visual FoxPro的cursor的转换和ADO事件的绑定 ，Visual FoxPro 更是内置支持 COM 事件绑定。在本文的第一版中，笔者曾有这样的希望：“Visual FoxPro 更具效率的支持ADO”。现在我的看法有了一些改变，我认为在 Visual FoxPro 处理数据，无论是本地、还是远程数据，无论是什么构架的系统，最佳的解决方案认识内置的数据引擎，而不是现在流行的ADO,现在 Visual FoxPro对ADO的支持程度已经足够了！
Visual FoxPro的数据引擎与ADO相比有什么优势呢？
- Visual FoxPro数据引擎系统资源耗用小，ADO毕竟是COM组件要花用更多的资源。
- 作为系统共用组件，使用ADO可能会在不同应用系统中产生ADO的版本问题，这就像我们常遇见的ActiveX的控件版本问题。
- ADO只是数据存取组件，它没有数据处理功能，要处理数据必须使用客户应用程序，如VB、Delphi。Visual FoxPro数据引擎同时支持数据存取、数据处理，我已多次强调Visual FoxPro在这两方面的伟大功能；
- ADO没有本地数据库作为强大的支持，有需要将远端数据暂时存放在物理文件中ADO绝对不及Visual FoxPro。Visual FoxPro的数据库是桌面数据库中最好的，远端数据暂存其中不仅方便，而且伸缩性强。
- 使用ADO从数据源获得数据以后，再要对数据集合进行分组、查询、汇总是非常麻烦的事情，但是Visual FoxPro支持对Cursor的数据处理，我们可以使用绝大多数XBase语言（除了ZAP和Pack之类的表维护语言之外），还可以对Cursor执行SQL语句——这种强大的威力，绝非ADO所能比拟。
开发单机程序时，绝对不要使用ADO，这样做既没开发效率也没运行效率；开发C/S系统时我们应选用Visual FoxPro的SPT和Remote View，它们完全可以很完美的解决问题（已经有很多很多成功经验），不需要舍近求远地使用ADO；在中间层开发时，可以考虑使用ADO，我们为在此种情况下使用ADO的开发效率是蛮高的，因为这时所有的代码都要我们用一句、一句的写出来（在其他开发环境也一样），Visual FoxPro的语法简单再加上Visual FoxPro 7的极为强大Intellisense功能（真的很快并且可以由用户自定义），也许我们还会占些便宜的。
虽然ADO与Visual FoxPro是完全无关的系统，但他们却有共同的母亲——FoxPro 开发小组，原来ADO的光标集（Cursor Engine）是他们开发的。如果你同时了解ADO与Visual FoxPro，你会发现ADO的很多思路与Visual FoxPro一模一样……我总是拿这个典故说服那些不相信Visual FoxPro的人：最流行的ADO的光标集是FoxPro 开发小组写的，有什么理由怀疑Visual FoxPro的数据引擎——它是世界上最棒的！
Visual FoxPro是一种历史悠久的产品，很多用户是从FoxBASE到FoxPro到Visual FoxPro，这样一步一步过来的。历史的积淀多了，历史的包袱也重了——许多程序员往往抓住老产品而忘了深入钻研新产品的新特性，这是一种悲哀。
我遇到许多所谓会使用Visual FoxPro的人，还口口声声叫“Query Design”为“RQBE”，朋友那可是DOS时代的概念了。
很多人不仔细钻研Visual FoxPro，只是从其他工具中看到某项功能，凭空想象就说：Visual FoxPro不支持的。Delphi中特别指出它有异构数据关联能力，比如：父表是SQL Server数据，子表是Access数据，要求建立关联，实现“一多关系”。在Delphi要求使用特别的SQL语法来实现该功能。Visual FoxPro的文档里好像没特别说明这项功能，是不是没有呢？如果你深刻理解Visual FoxPro的远程视图及Cursor的用法，答案很容易得到。事实上，用Visual FoxPro能更直接、简单实现的实现：建两条“连接”、两个“远程视图”，对子表加索引，Set relation to，set skip to……
反过来Visual FoxPro能实现的功能，Delphi的BDE（Delphi的本地引擎）却不能：Visual FoxPro的远程视图能够将多个表关联后的结果集设定为“可更新”，并在数据变动后自动产生Update子句分别更新后台数据。例如：对SQL Server中Pubs数据库建立连接，新建远程视图为：
CREATE SQL VIEW TEST VIEW REMOTE CONNECTION CONNECTION1 AS SELECT Publishers.pub_id, Publishers.pub_name, Titles.title_id, Titles.title, Titles.price, Authors.au_id, Authors.au_lname, Authors.au_fname, Authors.phone, Authors.address FROM dbo.publishers Publishers, dbo.titles Titles, dbo.titleauthor Titleauthor, dbo.authors Authors WHERE Titles.pub_id = Publishers.pub_id AND Titleauthor.title_id = Titles.title_id AND Authors.au_id = Titleauthor.au_id ORDER BY Publishers.pub_id
这是四个表间的关系，算是比较复杂的SQL语句。别担心，这一切在Visual FoxPro只不过是用鼠标在“视图设计器”点击几次就行了。在您对视图进行“添加、删除、修改”并发送更新时， Visual FoxPro会进行分析地智能，产生Update字句分别将变化更新到后端若干个表中。而Delphi的BDE只能对Xbase数据源有此的作用，对其他的数据源都无此功能。Visual FoxPro可以支持所有的ODBC数据源（只要数据源本身支持），如：Oracle、SQL Server，Access……当然在Delphi 5.X中可以通过ADO弥补此缺陷，但Visual FoxPro同样支持ADO。Visual FoxPro的程序员要有这样的信心：Visual FoxPro为我们提供了最好的本地引擎！
古人云：欲善其事、必先利其器。所以我们不要指责工具怎么、怎么，多看看自己用好了没有!