ClientDataSet在EOF後可以取值嗎?

當我們在一個ClientDataSet取值時，如果該ClientDataSet已經EOF了，那ClientDataSet.FieldByName('KEY').AsString可以取值嗎?

答案是可以，它會是最後一筆的值。所以在做二個ClientDataSet比較時，別忘了在EOF時要做特別判斷，例如給'zzz'這種最大值，否則常會造成誤判，變成另一ClientDataSet的值被忽略了。

合久必分，分久必合

很久以前用DBASE資料庫的時候，當時一個檔案有2M的限制，所以考量到資料量的關係，於是把筆數多的資料，區分為不同類型的檔案。例如料品基本檔就依型態，原料叫ITEM1，一般物料叫ITEM2，半成品叫ITEM3，成品叫ITEM4等等。這樣就可以減少單一TABLE筆數過大的問題。

不過到了SQL，資料庫的容量大大提昇了，用WHERE條件來區分料品型態其實是一件很容易的事。於是為了減少程式碼，就把先前的檔案合併成一個，用一個分類碼來做區分，這樣原先要個別寫四隻程式維護，變成只要寫一隻就行了。

這種方式行之有年，大家也覺得很正常，資料庫大真的很方便，程式不用再像以前一樣考慮TABLE合併的問題。不過筆者最近碰到一個案例，就是前面說的料品檔一分為四的情形。可能是從舊程式資料轉上來，因為資料的關係，沒辦法合併到相同的TABLE，這下要查詢挑選全部的資料就麻煩了。

事實上在很多情況也必須把不同TABLE的資料合併讓操作人員挑選，例如付款時，付款的對象可能是廠商，但如果客戶也會有付款的情形呢?當然有人會在廠商檔建立客戶編號，當作付款對象，不過如果員工也會有付款情形呢?好像這樣加也不是好方法。

這是用SQL資料庫提供的VIEW就很方便了，利用UNION把先前分開的TABLE整合在一起，就可以讓操作人員挑選了
以下就是把客戶檔 G_CUST、廠商檔 P_VEND 和員工檔 PUB_EMP 建立成 v_PUB_ID_HQ

Create View vPUB_ID_HQ AS
Select  '1' AS FG_OBJECT,ID_CUST AS ID_HQ,NM_CS,NM_CONTACT,NN_TEL,NN_FAX,AR_MAIL FROM G_CUST
UNION
Select  '2' AS FG_OBJECT,ID_VEND AS ID_HQ,NM_CS,NM_CONTACT,NN_TEL,NN_FAX,AR_MAIL FROM P_VEND
UNION
Select  '3' AS FG_OBJECT,ID_EMP AS ID_HQ,NM_EMP AS NM_CS,NM_CONTACT,NN_TEL,NULL AS NN_FAX,AR_EMAIL AS AR_MAIL  FROM PUB_EMP

這樣以後 SLECT * FROM v_PUB_ID_HQ，就會出現合併的資料，讓使用者挑選了

用WHERE條件把大資料區分成需要的小資料，用UNION把不同TABLE的資料合併成大資料。二種方式讓你設計的資料庫結構更有彈性。

欄位資料取得的速度

如果要取得G_CUST的檔案中的AR_DLV欄位，用G_CUST.FieldByName('AR_DLV').AsString和G_CUSTAR_DLV.AsString(直接用欄位取值)那一個比較好?
以前筆者都採用G_CUST.FieldByName('AR_DLV').AsString，主要的原因是1.看起來很直覺2.不用抓欄位設定3.如果欄位或來源有更改不用重抓。
不過最近在做程式大量計算時，發現當資料量一多，檔案的欄位在多年功能變動加大的努力上，也成長了不少，結果速度就有點拖下去了。改用第二種方式後，速度明顯的提升了，原因是用欄位取值是直接取，FieldByName則要跑一下迴圈，判斷是AR_DLV欄位後，才給值，所以雖然FieldByName的彈性大，但是速度就被犧牲了。
所以在設計程式時，也許要考量一下這二種不同的方式，依程式特性來做取捨。提供給Delphi同好做參考。

文字自動序號的寫法

先前看過林壽山先生寫的 DBGrid顯示流水號方式 內容是用Integer的方式來做序號的產生。不過在我接觸的專案中，一般都是用文字來做序號，例如0001。主要是因為在排序時，會比較方便做處理，在顯示上也比較美觀。所以在此提供一下文字自動序號的解法。
首先在要文字自動序號的明細檔的DataSet建一個AggregateField欄位，如下圖

最重要的是在 Expression 加上MAX(NO_SEQ)。NO_SEQ就是我們要自動序號的文字欄位。

接下來在DataSet(本例為jdsG_SOS) 的 AfterInsert Event中加上 jdsG_SOSNO_SEQ.AsString := AutoSEQ(jdsG_SOSMAXSEQ.AsString);

而AutoSEQ這個Function的程式碼如下

function AutoSEQ(MaxSEQ : String):String;
const
  NOSize =4;
var
  I : Integer;
  NO : String;
begin
  NO := '';
  for I := 1 to NOSize-1 do NO := NO+'0';
  if Length(MaxSEQ)>0 then
  begin
    I := StrToInt(MaxSEQ)+1;
    NO := NO+IntToStr(I);
    NO := Copy(NO,Length(NO)-NOSize+1,NOSize);
  end
  else
  begin
    NO := NO+'1';
  end;

這樣在執行時，就可以看到NO_SEQ會出現0001這樣的序號了，如果修改為0003，接下來的序號也會變成0004。
希望提供的方式對DELPHI愛用者有幫助。

Delphi缺的那一塊

Delphi在APP的領域，目前可說是發光發熱。大家也都覺得embarcadero會利用整合iOS、Android的平台開發，而讓Delphi重返昔日榮耀之路。這樣的方向應該也沒錯，畢竟在WEB這個領域，被.NET的佔有率給打趴了。

不過就商業運用來說，Delphi在WINDOWS介面的程式發展是相當不錯的，特別是在資料庫的領域方面。舉凡國內大廠鼎新的ERP和正航的大套系統，都是用DELPHI開發的。結果在WINDOWS開發的系統，在WEB這一塊必須用ASP、.NET開發，然後APP再回到DELPHI來做，感覺中間就缺了一段。

APP的程式運用能補足Delphi在WEB缺失的這一塊嗎?或許再往後一二年才知道結果如何吧！

你下的SQL在同一個Tranction中嗎?

最近都在為資料庫做一些程式設計。在處理的過程中，發現了一個問題。我們在處理資料時，如何確定我們下的SQL是在同一個Tranction中?一般我們都是在DataModule中用ADOConnection來連資料庫，那如果我們在ADOQuery或其他元件的AfterInsert、AfterPost時，是否還在Tranction中?

查了一下，發現ADOConnection.InTransaction可以確認一下是否在同一個Tranction中。在寫程式或Debug時，可以方便來確定程式資料更新遇到 RollBack時，是否會回覆到安全同步的狀態。

Delphi WebService 明顯不足

  日前利用Delphi Web Service 與 DOT NET 的 Server 溝通. 才知道原來DOT NET 有兩種: BasicHttpBinding和WsHttpBinding 溝通模式.

     可惜Delphi 只支援  BasicHttpBinding 並不支援WsHttpBinding. 許多Server 端的應用會受限.

期待未來delphi 能都支援.

BDE is gone

參加Embarcadero的研討會，聽到了很多新技術的發表，雖然覺得很有未來。不過比較震撼的是從李維大師的口中確認BDE要退場了。雖然BDE不再支援的消息早在數年前就聽說了，不過在DELPHI的技術研討會上公開說明，還是覺得BDE的末日就近在眼前了。
雖然目前大部分客戶都用ADO做資料庫的連接，不過有些客戶都還是用BDE，因為N年前ADO還不穩時，都是靠BDE撐了下來。為了這些未更新的客戶，我覺得應該上網查一下。結果發現有BDE64供下載http://softadvice.informer.com/Download_Bde_64_Bits_Windows_7.html，馬上去DOWNLOAD了一份備用。在此分享給大家，也許在你系統未升級到目前Embarcadero大力推薦的FireDAC前，可以提供你系統比較充裕的時間做資料庫連線的更新。

Delphi未來可在Linux上運行

上周五RAD studio XE7台北技術研討會中，Embarcadero的開發主管John Tomas提到：「未來的目標是將支援跨平台的領域延伸至Linux，以後將會支援開發Linux Server端的程式。」

聽到這消息我非常開心，這代表現在我們寫的程式碼未來可以在更多OS運作。從iOS 到Android未來到Linux，Embarcadero這幾年持續強化IDE的功能，更新的速度及強度都很夠，希望可以讓更多人加入，並瞭解Delphi是一個很方便很強大的程式語言。

Delphi工程師難找嗎?

前幾天客戶要我們公司接外包案，不過因為我們公司的人力已經排到明年六月了，所以無法再接新的外包案。於是客戶問我們可否幫他找人，他已經找二個月找不到人了。

Delphi工程師真的那麼難找嗎?是因為學Delphi的人少?需要Delphi工程師的工作太多?依據市場需求理論不是需求大於供給，就會有高額的利益讓供給端提昇供給的意願嗎?

我查了一下Delphi的學習網站和教育機構，發現這部分的環境還真的不多。到書局去找Delphi的入門書，還找不到。也許這就是Delphi工程師供需失衡的原因吧。希望有學術機構或公司願意進入Delphi教學的領域，讓找Delphi工程師變一件容易的事。

DELPHI出XE7了

對於DELPHI的愛好者來說，DELPHI出版本是考驗心臟強度的重大時刻。對於DELPHI新加的功能當然是一件喜悅的事，特別是新加的功能能改善目前程式的時候。不過有新功能就會讓程式增胖，特別是用不到太多新功能，程式確長大了不少，心情就有點給它 ....。
比較麻煩的是新版本讓目前的程式有狀況時，那就是加班調程式的日子到了。程式碼一多，工作量就少不下來，最麻煩的就是資料的邊界值不容易找，一定要到USER碰上了才查的出來。
不過有新版本就代表著進步。期待發表會的到來。