跳到主要內容

發表文章

目前顯示的是 四月, 2009的文章

DBeXpress 的 RecordCount

DBX中的 SQLTable / SQLQuery / SQLDataSet 都有支援「RecordCount」函式(統計資料集合現有多少筆數)

實際在用的時候發現並不是這麼好用,常常 run 到該處就發生例外錯誤(Exception)

不少人認為這是DBX的BUG...

最近閒來沒事在查這方面的資訊,發現原來BCB的HELP中有解釋不能應用的場合

原來DBX的元件是由「TCustomSQLDataSet」繼承「TDataSet」而來

然「TCustomSQLDataSet」有改寫 RecordCount 的些許內容,一般簡易查詢依然可以利用
但如果遇到以下情況則會跳出例外錯誤:

1. The dataset represents stored procedure.
1. 資料集為 Stored Procedure 表示式

2. The dataset represents a query that contains parameters.
2. 資料集為帶有參數查詢的表示式

3. The dataset represents a multi-table join.
3. 資料集為多表合併的表示式

不過HELP中並沒有提到這樣的限制的理由 (汗)

解決的方式有以下兩種:
1. 利用ClientDataSet來處理RecordCount
2.使用SQL的COUNT(*)來統計

以上,做個小參考吧~~~(笑)

DBeXpress的一些觀念

話說DBeXpress是B社強力主推的軟技術之一
但鮮少有資料可供參考

討論它的專書繁中+簡中的…大約4本吧
而有提到的書籍,無一不說DBX的效能好,但…

說效能不錯,那是有條件的!

就先拿BDE來說好了,B社資料連結技術的開山元祖
速度快不快,說真的,在單機架構中,應該是沒有任何的引擎比它快
(就連最新的DBX4也才只比BDE快0.X秒)

缺點:
封裝麻煩

說真的,BDE除了這點外,大概沒其它問題(…是我沒用到過)

而DBX呢?
速度嘛…M$SQL輸ADO(大),單機輸BDE(超大),C/S則還需看BDE的SQL LINK及ODBC效能才有機會勝出…
DBX的效能…或許在5~6版之後能真正超越BDE吧
那,DBX的優勢在哪邊?
1.封裝簡單
  只需要把 MIDAS 及 DBX+DB Client所需的DLL包在一起,直接封裝即可,快速簡單
2.架構明確
  以往習慣BDE的B社愛好者(被逼?),一但必須把原1~2-TIER的架構晉升為N-TIER時,往往會因架構落差太大導致轉換不易
  而DBX採行的則是「準n-tier」架構,讀取資料時採單向取出,寫入資料時則交由DATASNAP方式寫入
各司其職,取「單向取出」及「MIDAS寫入」二者優點,得到最大效能
(慢就是慢在MIDAS,所以效能慢也不能全怪DBX)

提了這麼多,那DBX的架構是什麼東西?

DBX元件 + DataSetProvider + ClientDataSet

這就是完整的DBX架構

某書曾寫DBX + StringGrid的方式簡直是大誤......

N-TIER所用到的元件則是…

(BDE / ADO / DBX) + DataSetProvider |<-Server 切 Client->| (DCOM / Socket) + ClientDataset

如何?有沒有像一點?如此切開就成了n-tier架構

接下來要討論的課題是
這樣的DBX要怎麼在專案中設計?
以下的內容不一定是正規寫法,也歡迎提出討論

1.視時機使用SQLTable/SQLQuery及ClientDataSet操作資料存取元件
  這種方式看起來沒啥不好,在c/s設計上也沒有問題,但在未來移轉到n-tier時,需要變更的地方可不少
(也就是說,仍採用與BDE相同的設計模式)

2.將ClientDataSet直接取代成TTable / TQuery來使用
  把SQLTable及…

在史瓦濟蘭九天的回憶錄(一)

話說去史瓦濟蘭,到底是好,還是不好?說真的,沒一天好,沒有一天是好的!(這就是愛台灣啦!哈哈!)
因為敝公司的業務平日都有在做面子,所以在那邊真的很能感受客戶對我們的善意也看到了當地的好人,當然,壞人也不少啦,但與南非比起來,史國民情算是相當優良的了出發第一天從台灣出發,飛到香港後,等了3小時才搭上預計的班機,當時是晚上,而南非當地則是白天。坐上飛機,發現座位旁沒人,心想真幸運,但沒想到之後坐在我旁邊的居然是位高胖的黑人(多胖?185cm / 120公斤有吧),就是坐著還會卡到我,真是大隻……抵達南非時的機上照片
飛機飛得很快,平均是900km / hr,我覺得就像上演現代版夸父追日一般,當然,太陽沒被我們追到,連月亮都跑得比我們還要快,到最後,我們又被太陽給追上了,呵!「這邊是德本機場!」不遠處的香港旅行團團員盼盼在討論這件事情呃!?這跟我們預計的不太一樣,我們不是應該到約翰尼斯堡嗎?之後的廣播告知:因南非天候不佳,必須先到德本機場等候,等天氣好一點,再飛到目的地。之後我就開始觀查旁邊的大隻佬,呼吸聲真大…下飛機時還會把垃圾丟到我位置前的置物袋……是我太大驚小怪嗎?但…好像是當地的民族性…或許吧

面對小公主的脾氣…

...小公主晚上又發脾氣了…心情實在不太好,上來舒解一下…其實,住在一起之後,我發現,常常只要一接近家中,小公主就很容易被激怒,不知道是我太白目還是小公主脾氣變差還是…
前一秒還是高高興興的,後一秒就大發脾氣,這個不應該做,那個不應該碰…很煩
是不是每個結婚後的家庭都是這樣呢?還是絕對都是我的問題?
開始有點討厭回家了…如果一回家就要吵一架,那幹嘛組一個家庭呢?
當初的決定是否正確呢?可能
小公主也是這樣想的吧

[轉貼]心得分享 : 參數檔 (INI 檔) 處理

來源:心得分享 : 參數檔 (INI 檔) 處理


INI 檔應用的歷史從 Windows 3.1就已存在,雖然它也是文字檔的一種,但它利用「節區(Section)」及「識別字(KeyWord)」觀念,類似資料庫的索引,所以用來當作少量 變數資料的儲存器非常適合,除變數管理容易外尚可做程式流程控制,市售套裝軟體有用 ini 檔來控制其軟體版本例子,其主執行檔可能只有一個,但依 INI 檔設定可開放其全功能版(豪華版)與非全功能版;INI檔案 Size 雖然有 64k的限制,但已足夠存放上百個變數資料;在 32 位元系統上,正統取代 INI 機能的方法為使用 Windows Regist,但為了儲存Windows 作業系統本身的資訊,Regist已夠龐大,如果我們每個應用程式又去 Regist內挖一塊空間當作自己儲藏變數或參數的地方,會讓 Regist變得更龐大更複雜,所以筆者還是建議每個程式都使用自己的INI檔來儲存自己的變數,況且 INI檔不會被淘汰,連 Linux Kylix 下都看得到其蹤影

■ 應用實例

假設程式中需要紀錄目前發票號碼(invo_no)、交易序號(tran_no),而每次交易完都要將這兩個變數值加1,若程式從頭到尾都不關機,那沒有 問題,程式會記錄目前的發票號碼及交易序號已排到幾號;但若程式中途有關機後,下次開機,程式怎知發票號碼及交易序號已排到幾號?所以除了將變數資料存於 資料庫中外,更簡單的方法就是使用INI檔來記錄變數值,在程式重新啟動時再將變數值取回,所以該INI檔內容可能長得如下:

[Varible]
invo_no=00000005
tran_no=3

其中,用中括號刮起來的Variable就是「節區(Section)」名稱(可自訂),而其內的 INVO_NO、TRAN_NO則稱為「識別字(KeyWord)」(可自訂);不可有相同名稱的兩個節區(Section),但不同的節區中可有相同名 稱的識別字(KeyWord),取用時按節區(Section)索引分開取用,如下圖:

[Varible]
invo_no=00000005
tran_no=3

[Varible_2]
invo_no=00000007
tran_no=5

■ 程式實例

接下來我們介紹使用 INI 檔來儲存或取回變數的方法,在程式中要使用 INI 檔有幾個步驟:

1.…