TDataSetProvider 的一個 Bugs

追 VCL Code 才找到問題主因……

procedure TDataPacketWriter.AddIndexDefs(DataSet: TDataSet; const Info: TInfoArray);
...
        { Get the DEFAULT_ORDER }
        if not (poRetainServerOrder in Options) then
          DefIdx := (DataSet as IProviderSupport).PSGetDefaultOrder // EListError: List index out of bounds (-1)
        else
          DefIdx := nil;
...

但裡頭是組合語言，我已經沒辦法了，只能回避囉！

延伸閱讀：

• DBCommon.pas 雖然有 BUG ，但裡頭值得研究
• TClientDataSet.RefreshRecord doesn't work anymore for JOINED queries
• TCustomADODataSet.PSGetDefaultOrder ignores 'Order By' CommandText clause

TByte 和 TByteDynArray 的轉換

TByteDynArray 同等 TByte

意外發現 TBytesStream 這個類別

但發現不能做 TBytesStream.Create(TByteDynArray)
不過卻可以寫成這樣：
TBytesStream.Create(TByte(TByteDynArray))

據說後來有改正這個缺點。

see also:

• TBytes has no type info
• Can TBytes, TByteDynArray, Array of Bytes be safely typecasted to each other?

Delphi 和 CB 的雲端技術，安全嗎？

在「都加密了，還怕什麼?」這篇有提到關於雲端技術常被探討的安全性議題。

可以知道

• 只要採用合適的加密法以及自訂的傳輸方式，可以使雲端應用更安全。
• 不是公開制定的協議，被駭客盯上的可能性機乎為零。

或許以 DataSnap 這種小眾市場上，稍加封裝就可以讓安全性大幅提升。

當然，Borland / EMBT 如果有開後門的話就另當別論了（笑）

REST DataSnap: Server Methods Lifecycle 的差別之處

REST DataSnap 的 Server methods Lifecycle 有：Session, Invocation, Server 三種選項。


Session:
每個 IP 只會固定配置一個實體，直到 Client 離線後釋放。


Invocation:
每次連線都會配置一個新的實體，到 Client 離線後釋放。


Server:
只有一個實體，給所有 Client 使用，類似 Com-based 的 Threading Model : Apartment




其它的教學連結：

Delphi Labs: DataSnap XE - Server Methods Lifecycle         

DelphiLabsDataSnapLifecyclePart1        

DelphiLabsDataSnapLifecyclePart2

DataSnap 製作 DB Connection Pool 的範例

ID: 28097, Sharing DB Connection in DataSnap with different Server Classes

例用泛型技巧來儲存 TSQLConnection。真是長見聞了！

※以 TDSServer DataSnap + Delphi XE 製作。

關於ClientDataSet.Filiter的Trim補充

Delphi in Depth: ClientDataSet 愛好者Cary Jensen在他的部落格上有回應我對Trim參數的問題。

寫得好詳盡，在這邊存個傳送門：Using Trim in ClientDataSet Filters

Firebird 版本選擇：Classic, SuperClassic, SuperServer

Firebird 官方說明文件：Classic, SuperClassic or Superserver?

Classic：

連線方式採 1 程序(Process)對應 1 連線，單一程序崩潰時並不影響其它連線。

SuperClassic、SuperServer：

• 採 1 程序對應所有連線，該程序如果崩潰即所有連線都會異常。
• 承上，崩潰後該程序會自動重啟。

資源分配上：

SuperServer ＞ SuperClassic ＞ Classic。
(※SuperServer 還多了一個作弊緩衝區)

只有 Classic 和 SuperClassic 能同時連線。

SuperServer 在 Windows 下預設只採用第一個認到的核心。必須到 firebird.conf 設定 CpuAffinityMask。

本機連線：

只有 Classic 和 SuperClassic 提供，有安全性的問題，但搭配單機版應用程式下非常實用。

三款都有各自的特色。
如果還是不知道要用哪個，就下載 SuperClassic 吧。


2015/05/06補充：
謝謝Delphi.KTOP的leveon大提供額外的資訊，還有附圖解說，十分詳盡。
傳送門：Firebird – SuperServer, ClassicServer or SuperClassic?

另外，據說Firebird 3.0之後這三者會合成一個，不知道正式版發行後是不是真的會成真，期待早日釋出。