1.無痛解決BDE升級到ADO，BDE升級到DBExpress與ADO升級到DBExpress。 2.64-bit編譯器。讓Delphi的設計師與投資者，可以搶搭64bit升級的產品 週期。 3.解決因為版本升級而無法使用舊的VCL元件問題。 如果大家對於以上的看想贊同的話，請多多回應。 謝謝。 讓大家都有更好的開發環境，讓資源投到正確的方向。 歡迎光臨神奇力量網 http://www.688.idv.tw/

------
歡迎光臨神奇力量網

http://mpn.adsldns.org/

引言: -->1.無痛解決BDE升級到ADO，BDE升級到DBExpress與ADO升級到DBExpress。 -->2.64-bit編譯器。讓Delphi的設計師與投資者，可以搶搭64bit升級的產品 -----週期。 -->3.解決因為版本升級而無法使用舊的VCL元件問題。 就個人所知,略述一下 針對(1) , 其實就我所知,並沒有所謂"無痛"的解決方案 ; 這麼說並不是衝著您而來(請您諒解) , 因為通常解決一個問題之後總會帶來另一個問題!! 如果ADO可以解決問題 , 那用ADO就好了 ; 就我所知DBExpress才發展沒多久 , 也需要時間與實例去驗證它功能性與可靠性....就和ADO是一樣的(一直在修正) 只能說 , 看Borland需要多久的時間了(針對(2)也是如此)!! 至於 "因為版本升級而無法使用舊的VCL元件問題" ,個人到目前為止是覺得 除非是'沒有Source Code',否則從D3-D7(ps:D8 & D2005 我從不去碰,問題很多) Borland的表現都沒令我失望,我改寫了不少VCL(從D3-D7);所以雖然這些版本 的VCL元件"架構"都有版本更新 , 但從未令我失望過!! 即使是OpenToolsAPI 也是 至於沒有Source Code的東西,你能期待多少? 這一點其實MS 和 Borland 是一樣的; 例如 , 一個沒有Source Code , 用VB(or VC)開發的的OCX元件,碰到需要修改時,你有辦法再重修其就有的功能嗎? 沒辦法吧? 只能望著OCX元件而興嘆!! 用一個元件(COM也好,VCL也好) , 有沒有Source Code就是一個關鍵,如果COM元件可以一直升級 , 那麼你看一看...光是ADO元件更新了幾個版次了? 而解每次的機碼值都不同...所以,再說回來;VCL沒有Source Code !! 幾乎就是限定使用版本了; 畢竟Compiler與函式庫的版本不會一直都不變的您說是嗎? 所以 , Borland與MS都無法替您做到這一點是顯而易見的 , 別做這種超乎常識外的要求.....說這麼多,希望你也能理解!! 努力不一定成功 , 不努力一定不成功!!

技术不同的东西不可能自然平滑升级，因为不存在功能上一一对应。 64bit问题，borland肯定会推出的。不过这取决于对64bit的社会真正需求程度。目前来说64bit并不是那么紧迫，个人感觉硬件上（CPU等）还不能说已经64bit最终熟透了。 对于vcl向下兼容的问题D2005做得很好。不过，对于已经编译代码的兼容，任何厂家都不可能做得更好。毕竟delphi的编译架构不同。好在对源码的支持还是令人满意的。 發表人 - lsu 於 2005/11/13 19:52:04 發表人 - lsu 於 2005/11/13 19:53:04

別模糊了焦點。不管有沒有Source Code，重點是要能解決問題。 總不能提出一個架構，卻沒有讓大家無痛升級的方式， 而要大家花費許多的時間測試新的架構，這是不負責任 的。 64位元可能還沒準備好，但是有任何可以發表新產品，對使用者來說， 可以賺錢的方式，沒有任何一個投資者會想錯過的。就是要想辦法，搶 在第一時間完成，這樣賺錢的機會才會多啊。 歡迎光臨神奇力量網 http://www.688.idv.tw/

------
歡迎光臨神奇力量網

http://mpn.adsldns.org/

引言 -->總不能提出一個架構，卻沒有讓大家無痛升級的方式， -->而要大家花費許多的時間測試新的架構，這是不負責任 -->的。 不知道你指的(架構)是哪一種? 是C/S 轉移到 N-Tier 嗎? 還是Win32轉web? 還是BDE轉ADO? 還是BDE轉DBExpress? 以C/S轉到N-Tier來說 , 我倒是認為Delphi這方面做的還可以接受,唯一詬病的是AppServer的延展性不夠,要夠建一個提供完全自製的AppServer仍需要很多的 經驗...大抵上來說有以下幾種經驗(技術) 1.對Interface與Dispatch等(介面/物件)及其功能有基礎的了解 2.對基本VCL的架構與原件的製作已經有相當的經驗,能夠修改暨有的元件 例如 TSocketConnection,TClientDataset...以及能夠擴展IAppServer介面 ...等等這些技術,否則只能用一些(IAppServer介面中)很基本的功能 3.牽涉到異常龐大的系統 , Package的技術更是需要 ....如何將Package技術 與N-Tier技術進行整合,又是一個技術問題(有實做過的朋友應該知道我所言 為何.....) 還是Win32轉web而言 , 這是Borland表現最不佳的一點 , 直到Intraweb的出現就不願多說,更何況Intraweb也是異常地"複雜" 至於BDE轉ADO,其實也沒啥好談的;Borland只是把ADO的COM物件包裝起來成為VCL 所以只要參考ADO文件,再加上擁有撰寫VCL的經驗,相信還是做得到(or 可以去下載一些 FreeWare 連Source Code都有) 至於BDE轉DBExpress,其實真正的困難應該是穩定性與支援度而已...... 我並沒有模糊焦點,只是想說;這個世上沒有"無痛的過程",除非你不願意自己動手(花錢請外包,這也算是一種痛!!程度不同而已!!); 廠商能提供的,只是很通俗化的解決方案,因為真正決定系統長啥樣子的,是程式設計師;廠商當然不知道每個人要的東西到底是什麼,他們只能就現有的環境;發展出一個架構,然後提供一個通俗的做法......舉個例子像InfoLight的EEP也是一樣啊,它也有它自己的實作方式,真正要去擴展這一切的....還是Programer.... 再說,如果有都不用程式設計師實作的工具,那ACCESS早就取代各位的地位了 誰還要花錢請Programer ? 就好像說"程式有程式碼產生器產生,再由Cmpiler來編譯就好了" 再舉個例,文字檔可以直接無痛升級到Word文件而不流失格式與排版嗎?? 我想為了維持原有的排版位置,你還必須要懂Word的一些功能....不都是一樣的道理?? 還有就是"無痛"的定義其實際模糊又遙遠,更慘的是大家的定義都不一樣?? "痛"的感受也不同....與其把它當作一個實際目標,我倒是願意把它當作理想就好,您覺得呢? 努力不一定成功 , 不努力一定不成功!!

補充一點 , 不要去做新技術的白老鼠 ; 等到大家對新技術已經有口碑;再去努力....先以穩定的技術解決當前的問題就好了!! 努力不一定成功 , 不努力一定不成功!!