我們說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的數據庫是桌面數據庫中最好的，遠端數據暫存其中不僅方便，而且伸縮性強。