利用閒暇之餘讀了僅僅的兩本書，終於對 FireBird 有一定的瞭解。

寫下一點小心得，免得日後給它健忘。....

＃ 事務的隔離與效率有很大的關係。

   在一次測試實務中發現，本身使用 Insert或Append 在新增資料上並無太大的差異，但仍建議使用 Append 方式。

   使用 Generator 與 Stored Procedure 會導致降低效率，尤其 Stored Procedure 不可與 Dataset 使用不

   同的Transaction ，使用不同的 Transaction 導致 FireBird 因需事務隔離效率會降低非常多。寫完這一段我

   都不知道自己在說什麼。唉！

    新增 50000 筆資料   

    FIBPLUS = 7,600 ms

    IBX        =  8,529 ms

    新增 50000 筆資料（GEN_ID，同一事務）

    FIBPLUS =  9,453 ms

    新增 50000 筆資料（GEN_ID，不同事務）

    FIBPLUS = 97,547 ms

    新增 50000 筆資料（GEN_ID，每筆提交）

    FIBPLUS = 162,922 ms

    修改 50000 筆資料（每筆提交）

    FIBPLUS = 127,594 ms

    結論：速度  FIBPLUS 比 IBX 快。在相同條件下。在測試中也發現每次新增資料的速度

         不會因資料筆數變大後而降低效率。

＃ 測試 FireBird 穩定性？

   1.測試  每  5000 交易提交，在提交過程關閉電源後並無異常。

   2.測試新增 50000 筆紀錄，每筆均交易提交，在提交過程關閉電源。測試5次無異常。此時筆數已累積到40W筆資料。

   3.測試新增及修改 50000 筆紀錄，每筆均交易提交，在提交過程強制中斷程式。測試 10 次無異常。

   4.測試修改 50000 筆紀錄，每筆均交易提交，在提交過程關閉電源。測試 2次均導致資料庫損壞。損壞率 100%。

    (令人感到沮喪...)  

   以上均以 FroceWrite狀態下測試。 

   結論：FireBird 在事務更新下，非常容易造成數據損壞。既使使用 GFIX 仍無法修復。

        不清楚是否有改善方法！？

＃ 預儲函數與觸發器非常好用，可利用 Post_Event 回傳給用戶。只是語法不熟悉不易學。

＃ 對於安全性幾點誤會。

    1. 在嵌入式，登入密碼是沒有作用。當然也不見得帳號名稱是沒有作用，雖然使用空白的帳號及密碼

        仍然可以登入，但是是無權限閱讀先前所建立資料表。必須為資料表的擁有者才能修改及閱讀。

        因此當您在建立資料庫時，務必指定一個使用者名稱，可以不必是 SYSDBA 。

    2. 增加安全性，可用 Trigger Database Connect  事件中解決。相信要直接打開大門是有難度地。

        若要更上一層樓。可搭配 UDF 解決。

        可延伸至過濾用戶。如：

        if (exists(select 1 from MON$ATTACHMENTS m 

        where m.MON$ATTACHMENT_ID = CURRENT_CONNECTION and 

        m.MON$REMOTE_ADDRESS = 'XX.XX.XX.XX')) 

        then EXCEPTION disallow;

＃ 自動編號的解決。

   可透過 Generator 生成，可搭配 Trigger 或 預儲函數，看是要在Before Insert 中觸發填入 Gen_ID 或利

   用預儲函數直接再儲存過程中寫入適合 Master-Detail 。

   流水號格式，通常流水號會加上日期做區隔。重點此時無法在  預儲函數 使用 Set Generator 方式重置號碼，

   可利用取巧 Gen_ID(XXXX,-Gen_ID(XXXX,0)); 倒扣回去，當預儲函數中判斷日期不同時。

墨水就一點點，擠不出來，就暫時寫到這...。

結論： 在單機版開發上不建議使用嵌入式 FireBird，太容易資料損壞。雖然可以裝 UPS 不斷電解決，但這樣的東西是比較沒有商機。

純參考。

最後轉向學習 SQLite 中，繼續測試。...