但是當我注意到使數據具有移動性和Web性需要付出多大努力時，我開始懷疑那些廠商所宣傳的---就連菜鳥也能通過點擊幾下鼠標就可以編寫一個web化的事務處理系統---的目標到底需要多久才能實現。是的，如今確實出現了一些這樣開發出來的程序，尤其是涉及業務處理的程序。但是要想那些非IT人員都能夠通過簡單的鼠標點擊拖拽就能夠編寫出能和專業IT人員編寫的程序相媲美的程序，則還需要事先完成很多工作。
挑戰：這些事先所要完成的工作并不能通過簡單的點擊拖拽操作完成。
而不同的項目所需的努力程度也不盡相同。比如一個不帶有歷史遺留問題的全新項目，所要付出的代價比帶有歷史遺留問題的項目少很多。盡管如此，將各個部分結合起來也不是僅靠一個鼠標就能做到的，有時甚至讓某個組件能正常工作都是一個挑戰。
很多企業都具有遺留系統。不論他們想將系統Web化、移動化還是采用別的什么方法改進系統，跨越新舊系統間的差距，將其融合在一起所付出的努力要比開始一個全新的項目困難得多。一旦到了不得不改變的地步，成本將會大大增加。Web服務技術的高手會告訴你“如果你的Web服務是基于XML的，那么改變起來相對要容易很多，成本也會降低�！倍鳺eb服務都支持這種“由集成標準帶來的成本降低”。不幸的是，很多時候并不只有標準問題，這里還涉及到哪個組件屬于Web服務，哪些組件不是Web服務，以及該如何處理它們。雖然前景美好，但我們只能用舊有設備(不是鼠標)來實現向未來轉變的目的。
一個可以解決問題的方法(雖然可能不太實用)，就是從同一個供應商那里購買全部產品。這當然會讓一切都運行的很好。
在我的項目中，我使用VBA將郵件處理功能集成到Outlook 2003中。這個項目的目標很簡單：讀取郵件后，會以一種比較公式化語言來回復郵件。當我發現Outlook具有可編程特點后，我就開始使用這個功能了。過了幾天，我在以前處理20-30封郵件的時間已經可以處理上百封郵件了。而且我還將包括郵件在內的很多數據存入了Microsoft Access數據庫中。
不久后，這些數據庫中的看似多余的數據發揮出了它的價值。比如我可以快速找到與某個公司對應的聯系人員�，F在很多廠商都依靠公關公司與媒體接洽，通過我的系統，我可以方便的查看哪個PR公司是為哪家廠商服務的，以及PR公司里的某個人員具體負責哪家公司。如果我需要找到某個讀者的信息，也可以通過簡單的數據查詢來找到相應的信息，比如查找我聯系過的對Java有興趣的讀者。
這套系統不但可以完成所有我希望完成的功能，還能完成別人的需求。當我將這套系統展示給別人看時，他們都說“我也需要這套系統，什么時候我能有這套系統�！睆墓δ苌险f，我的系統相當完備。但從技術角度上說，如果允許多用戶使用我的程序，我還需加以改進。另外，除了我的項目，肯定很多人也有類似的項目。開始的時候項目也許很小，但當其他人看到這個項目可以大大提高工作效率后，項目就有改進的需求了。讓我們將數據查詢擴展到企業局域網或者互聯網上。讓我們可以使數據庫多用戶進行更新，包括企業網外的用戶。讓我們可以在路上也能訪問系統….另外，我們可以讓數據和軟件自動分發。
這樣，最開始只是為了通過少量的腳本來溝通Microsoft Outlook 和Access，不但可以適合我，更可以適合其它用戶。
在數據庫方面，Access是我唯一的遺留問題(VBA是另一個遺留問題，將被VB.NET取代)。Access雖然簡單，但對于我這種企業級的應用項目來說有些馬力不足。而我的優勢是不用擔心其它的合作標準，我可以標準化一個企業的數據庫技術，以便保證數據和中央數據服務器(采用Web接口或Web服務器)的同步，以及與移動或固定設備(筆記本、手機、臺式機)同步。
大部分數據庫公司都提供多種表格以便與其它數據庫同步。比如iAnywhere(Sybase的一個部門)的MobiLink數據庫同步技術，帶有廠商提供的腳本，采用Adaptive Server Anywhere (ASA)實現桌面或手機設備與Oracle、IBM、以及 Microsoft的數據庫同步。
由于iAnyWhere的數據庫技術在移動解決方案方面的強度和成熟性，我偏向于在客戶端使用這種技術。iAnyWhere的移動數據庫服務器(ASA以及一小部分UltraLight)，可以用在PocketPC 以及PalmOS上，并支持存儲過程以及觸發機制(僅ASA)，并可以同步客戶/服務器結構，通過基于Web的開發而不是基于應用程序的開發，為企業提供數據同步和移動訪問能力(利用iAnyWhere的 AvantGo技術)。
針對中央服務器，我本來打算選擇IBM、 Oracle或者 Microsoft的數據庫作為中央數據存儲，而采用ASA的客戶端設備。但是當我閱讀了iAnywhere的技術文檔后發現，在采用ASA的情況下，不論是手持設備、工作站還是服務器，都沒有很好的同步解決方案。同樣，我也排除了Microsoft的SQL Server，因為我覺得這有些大材小用。ASA可以用于各種操作系統，在我的Red Hat Linux 9(Pentium II 處理器，192 MB內存)系統中，它可以流暢的運行。當然，如果我采用了它，下一步就是如何獲取更大的效益。
在選擇數據庫時，我很擔心自己會將Access拋棄，因為這意味著我將要遷移舊有的數據，同時還必須改寫代碼以適應新的數據庫。雖然現在我已經把這兩方面事情都辦妥了，但并沒有我想象的那么簡單。
在其他數據庫供應商中，Sybase提供了相應的升級工具用來從MS-Access遷移到iAnyWhere的ASA或ASA的高端—Sybase的 Adaptive Server Enterprise。我遇到的第一個問題是該升級工具并不支持Access 2003。因此我的工作不得不停止下來。直到Sybase的升級工具支持了Access 2003，我才重新開始了自己的項目。這個新的升級工具不但可以將Access中的表格和數據導入ASA，還可以將Access中的指針指向ASA的數據庫，而不僅僅是轉換基于JET的表格(Access 使用的是JET引擎數據庫)。升級工具還可以復制基于JET的數據庫，并將其重新命名，一旦升級后的數據庫無法正常工作，用戶可以方便的恢復基于Access的數據庫。
在我看來，Access比很多數據庫服務器都具有更好的兼容性，尤其是在設計表格、指定主鍵和目錄以及生成關聯方面。而Sybase提供的升級工具不但不支持我設計的表格，還不兼容某些數據。盡管如此，但由于它的升級效果，我還是很樂意使用它來處理我的數據庫。
Sybase公布的另一個問題是目前升級工具還只能導入數據表格，而不能導入查詢(ASA中將查詢稱為“view”)。查詢的魅力在于，對于一個應用程序來說，查詢實際上就像一個數據表。與在代碼上處理數據表關系不同，有了處理查詢，就可以不通過復雜的關系與外部代碼或應用程序。比如，我的某些下拉菜單是受查詢控制的，而不是靠數據表本身。你可以想象我的VBA代碼是如何工作的---采用Microsoft ADO接口訪問數據庫，查找不存在的查詢(通過升級工具升級后)。因此，我不得不通過Sybase Central程序手動重新建立查詢。
重建查詢后，我重新運行應用程序。結果VBA的debugger彈出了一個以前從未出現過的錯誤，從錯誤解釋看，是Visual Basic方法(recordset.update)將一個永久錯誤數據載入了記錄中。至于到底是哪里錯了，我也不是很清楚。為了能在VBA環境外重建這個錯誤情況，我又在Sybase Central中使用一系列SQL語句試圖進行同樣的升級，但卻沒有出現任何錯誤。因此，我又回到應用程序中，將采用VB內建的建立、更新以及提交方法屏蔽掉，并采用SQL語句代替，來觀察每一行代碼的運行結果。
結果錯誤又出現了。
實際上SQL高手都知道問題出在哪里：當用SQL語句建立了一個新的記錄后，必須運行另一個SQL命令(@@IDENTITY)，然后才能讓新建立的紀錄自動產生記錄號。而VB并不需要這個額外的步驟。幸好Sybase的技術支持給我提供了一些與VB功能相似的代碼范例，讓我可以成功地解決這個問題。但是現在，我需要面對的是將全部代碼都進行類似的修改，這令我有一種喜憂參半的感覺。一方面，我真的不想重新改寫全部的代碼;另一方面，在改寫SQL代碼時又讓我想到是否有可能使用別的編程語言來提高程序的可移植性。比如，采用微軟的C#(我比較不想嘗試)或Java(如果我想將程序推向非Windows平臺時)。
ASA與我的VB代碼間的抵觸使我確實為難了一陣。我向Sybase的技術支持人員詢問有關問題，但他們明確的告訴我，從現有的信息看，ASA不兼容我的代碼唯一的原因就是我的代碼不符合SQL的ANSI標準。技術人員建議我在使用ASA處理數據記錄時關掉ANSI兼容性。這個建議非常有用。不過我仍然趨向于使用自己的SQL語句。
當我作完這一切時，仍然沒有進入設想的同步階段。我甚至還沒有對這個獨立的單用戶程序進行多用戶化、web化、Web服務化以及移動化改造的解決方案。不管怎樣，我還算是在正確的道路上，因為我對程序的這種改變絕對是值得的。
在這期間，我的門上一直貼著一張字條，寫著“這不是一個僅靠點擊拖拽就可以實現的編程區域，菜鳥勿進�！�
文章來源于領測軟件測試網 http://www.kjueaiud.com/
