程式寫好, 安裝在客戶電腦上, 經常遇到日後程式有所修改, 也同時修改了資料表結構,
這時我除了必須將新程式複製到客戶電腦上, 也必須手動將客戶的資料表結構予以修改(例如增加一個欄位等等)

有沒有一個元件或程式, 可以輸入資料表的欄位定義, 這個工具就可以拿這些欄位定義資料,
與資料庫目前的資料表欄位進行比對, 遇有不相符的地方, 就自動修改 ?

我當然可以自己寫這樣的程式, 但如果有現成的東西可用, 我就可以省下許多功夫

我覺得很難找得到這種因應特殊需求的元件，自己寫比較快！

同時修改了資料表結構
==>如果一個系統是公司的重要獲利來源，那修改資料結構幾乎是家常便飯。
==>這大家應該都有同感
這時我除了必須將新程式複製到客戶電腦上, 也必須手動將客戶的資料表結構予以修改(例如增加一個欄位等等)
==>這當然不能用人力手動，如果個系統有三十個客戶在用，就算每一個月才改一次Stru，要跑幾次才行，這人力支出誰負擔的起
==>當然要將Stru修改包裝起來，讓有維護合約的客戶自己執行啦
與資料庫目前的資料表欄位進行比對， 遇有不相符的地方, 就自動修改
==>各家有各家的解法，不過我的直覺是你這個作法不好。我們公司就不是這樣作。
==>公司如何作，我就不敢講了。這是各家 之秘。
==>總之，要保護資料，要講究速度，要讓客戶能夠自己執行，要吸引客戶自願簽每年的維護合約
我當然可以自己寫這樣的程式, 但如果有現成的東西可用, 我就可以省下許多功夫
==>如何保存DB-Stru的定義，這簡單，各家有各家的作法，條條大路通羅馬
==>如何檢測客戶現 DB-Stru，這可用Delphi的功能，不過如果你的資料庫跨越的種類太多的話，有時會失敗以致功能不能穩定。我覺得反而乾脆跳過這個思維，不要作這個設計較好。
==>這個功能﹝改資料結構及保護資料﹞不自己寫不行。
==>重點不是每次改Stru，就來個特別的Patch要客戶執行。那會煩死人，而且會有遺漏的。

------
Kevin

編輯記錄

我當然可以自己寫這樣的程式, 但如果有現成的東西可用, 我就可以省下許多功夫
==>別省這些功夫了，要客戶乖乖跟你簽維護合約，這個功能可是個好誘因。

------
Kevin

編輯記錄

與資料庫目前的資料表欄位進行比對
==>當初我也是有你同樣的想法，前幾年我也寫過不少這類的工具。但後來發現客戶資料庫太多種，而Delphi的這類處理好像也有時而窮，用起來總是有問題。就放棄這類的想法與解法。

------
Kevin

kevin2004兄，在緊要關頭究竟還是密而不宣，呵呵。

可以讓客戶執行的，卻又不是patch，那又是什麼呢？讓人不解阿
除非有一個機制可以進行新舊系統的比對
由這個機制進行轉換。

這樣的好處是可以保護資料在轉換失敗的時候
仍舊可以維持舊有系統的正常運作。

緊要關頭究竟還是密而不宣
==>領人薪水，不敢說太多。

有一個機制可以進行新舊系統的比對
==>系統是一直在更新成長，新版本一直在出，DBStru也是不斷在改，一定要有個『自動』維護的機制。
==>在一進系統時就可以作這個比對。如DBStru有變，就提示及...
==>不要等到進了這個Form或那個Form開表開不起來，而讓系統無法執行，誤了客戶的業務，後果很嚴重的
==>光憑這個，就可以吸引客戶簽維護合約的。不能說公司的開支都要由新客戶來支應阿，維護合約的收入至少要佔公司每年收入的很大比例才行。

可以自動修改資料表結構
==>茲事體大，出問題賠不起，千萬不可自動執行。
==>公司裏有套收支的系統只賣不到十萬，有個客戶竟然來抱怨說當了，原來他竟然處理的金額有好幾百億，而竟然只給了我們公司九萬元。實在太賤賣了。後來趕快將FieldType放大了事。
==>遇到這種很有潛力的客戶，自動執行如果出問題而丟了客戶的資料，可能公司都要被逼的關門了。

仍舊可以維持舊有系統的正常運作
==>客戶的業務是絕對不能停頓了，這時要採行很多技巧的。
==>領人薪水，不敢說太多。

------
Kevin

編輯記錄