之前在開發一個產品時，發現BDP有個問題： connection string，在design time設定好，加入在執行時期自系統登錄或xml/ini設定檔讀取使用者設定connection string的code，把程式編譯好，加寫資料庫連線設定程式，一起包裝成分發用的安裝檔，然後...... 當使用者把分發用的安裝檔跑過，程式都安裝好了，資料庫連線設定好，程式一跑，程式卻丟exception了：它在InitializeComponents時，還是用我在design time給的connection string試著去連資料庫。InitializeComponents裡頭的東西都是IDE/designer生出來的，要我手動去改那邊的code來變更connection string是沒道理的；可是我不這麼做的話，又一定會碰到那個exception. 又如果我把data adapter的LiveData設為false，我所依賴的一些在design time讀到的資料庫表格欄位定義就全丟了；即使如此，只要我程式的使用者那邊沒有原始design time connection string指定的資料庫，程式還是照樣丟exception給我看。 個人認為這是一種很嚴重的設計缺失，因為對於100%電腦傻瓜來說，他的電腦環境內一定沒有資料庫的。我的安裝程式把MSDE安裝問題也都解決了，結果要用BDP開個連線去create database時卻因為上段那個問題碰壁了。 如果我是BDP的設計者，就會考慮讓BDP提供一個GetConnectionString的event，讓開發人員能夠攔截那個event來提供runtime決定的connection string。

引言: 之前在開發一個產品時，發現BDP有個問題： connection string，在design time設定好，加入在執行時期自系統登錄或xml/ini設定檔讀取使用者設定connection string的code，把程式編譯好，加寫資料庫連線設定程式，一起包裝成分發用的安裝檔，然後...... 當使用者把分發用的安裝檔跑過，程式都安裝好了，資料庫連線設定好，程式一跑，程式卻丟exception了：它在InitializeComponents時，還是用我在design time給的connection string試著去連資料庫。InitializeComponents裡頭的東西都是IDE/designer生出來的，要我手動去改那邊的code來變更connection string是沒道理的；可是我不這麼做的話，又一定會碰到那個exception. 又如果我把data adapter的LiveData設為false，我所依賴的一些在design time讀到的資料庫表格欄位定義就全丟了；即使如此，只要我程式的使用者那邊沒有原始design time connection string指定的資料庫，程式還是照樣丟exception給我看。 個人認為這是一種很嚴重的設計缺失，因為對於100%電腦傻瓜來說，他的電腦環境內一定沒有資料庫的。我的安裝程式把MSDE安裝問題也都解決了，結果要用BDP開個連線去create database時卻因為上段那個問題碰壁了。 如果我是BDP的設計者，就會考慮讓BDP提供一個GetConnectionString的event，讓開發人員能夠攔截那個event來提供runtime決定的connection string。

了解問題, 但不清楚您的程式架構, 您說會發生 exception, 但什訊息內容是什麼? 一般 connection string 都是固定的, 怎麼會用 "xml/ini設定檔讀取使用者設定" ? Chris

單獨執行時是這樣的錯誤窗： xxxxx.exe - Common Language Runtime偵錯服務 應用程式已經發生無法處理的例外狀況。 處理序識別碼=0x**** (****)，執行緒識別碼=0x**** (****)。 在IDE內會看到元件初始化失敗。 至於connection string為何要動態讀取，我覺得這個問題問得很有意思。 作專案的話，會需要動態讀取connection string的機率大概接近沒有。 做產品就不是這樣了吧？考慮下面的設計： 1. 首先得確定使用者的環境有沒有指定的MSSQL server instance， 如果他沒有裝，他也不會裝，這個產品得替他裝一個MSDE instance， 不然這個產品就形同報廢了。 2. 也有的使用者已經裝好了MSSQL，可是他的電腦使用技巧也不高明， 怕你的產品毀了他本來的MSSQL，要求你另外裝一份MSDE instance。 這個MSDE instance一定沒法命名為MSSQLSERVER的。 你怎麼可能預先在產品設計時，知道他們要用哪個MSSQL/MSDE instance？ 3. 又如果使用者有不特定多數個，分散在不同地方，而這個產品的使用 的資料庫資料會天天更新自外部來源更新，為了省去這群電腦白痴的 麻煩，他們要求使用一個中央管理的MSSQL instance，不在各自的電 腦上安裝一份MSDE。你怎麼可能預先在產品設計時，知道他們把資料 庫裝在哪邊？ 4. InstallShield安裝檔裡頭也包好了MSDE，可是MSDE不提供merge module 啦，所以原始設計是在安裝好的程式第一次跑的時候，去偵測資料庫 連線找不找得到東西，是不是程式要找的那個DB instance，讓使用者 去選擇要不要用事先存在的MSSQL/MSDE instance，或者新裝一份我事 先指定好名字的MSDE。無論如何，使用者怎麼安裝，使用者怎麼選擇， 不是我事先就能在design time設計form、放入BDPConnection元件時 就知道的，使用者的環境十之八九與我的設計環境是不同的。 所以，有沒有必要在InitializeComponents裡頭就去動態讀取BDPConnection 的connection string？有必要，有絕對的必要。如果要我改用其他embedded database，那也不必依賴BDP了。 BDP相關的DataSet/DataAdapter/DataTable在InitializeComponents內會呼叫自己的BeginInit跟EndInit去做非同步的初始化，可是在BDPConnection找不到design time設的connection string指定的資料庫時，它們就直接從InitializeComponents裡頭丟元件初始化失敗的exception出來。這會讓InitializeComponents後頭其他資料庫無關元件的初始化都沒跑到。 BDP用起來是很方便，但是設計上考慮得顯然還不夠周詳。像這種初始化失敗的情形，完全沒留後路丟error event出來給event handler。有經驗的Delphi開發人員在遭遇這種錯誤後，會有自己的應對策略，避免那個CLR偵錯服務的窗子直接就秀在使用者的電腦上。沒經驗的Delphi開發人員，恐怕連自己的程式哪邊丟exception出來的都不清楚。 我真的希望Borland在增加250個行銷人員的同時，能多增加10個開發人員到Delphi team。如果不能增加10個開發人員到Delphi team幫忙fix bug，好歹也再多雇個4到5個同時做開發跟測試的人進Delphi team幫忙debug/test/fix bug吧。

根据我的经验，别用在IDE里拖一个BdpConnection过来的这种方式。    最好是单独用一个unit，自己写Class，把BdpConnection写在里面。这样一切都可以自己控制。    Delphi2005有Bug，会让你拖到IDE里的BdpConnection突然不见了，等等。    我通常会这样写：    

TMyClass=class
private
  FBdpConnection:BdpConnection;
public
  procedure SetConnStr(value:string);
  function GetMyData:DataSet;
end;