Delphi的Post和ApplyUpdate

參加DELPHI XE10的發表會後，就一直在忙公司的工作，沒時間上來寫文章。這期間看到了許多Delphi同好在其他論壇討論XE10的APP問題，看樣子XE10這次在APP的支援上，還是有不少狀況。
最近碰上了一位新進的DELPHI同好，他說他老是無法把資料存起來，幫忙Debug才發現是他Post和ApplyUpdate沒有弄懂。所以上來說明一下這二者的區分。
一般Post是把資料存到我們的記憶體，表示我們的資料更改完成，但是並沒有存回後端真正的資料庫，等到我們下ApplyUpdate時才把資料存回後端的資料庫。那為什麼要分這二個動作呢?
因為在修改資料時，不一定只改一筆Record，例如修改明細資料時，通常我們會修改很多筆才一起存回後端，那修改一筆時，如果要檢查資料，這時就需要在Post檢查資料是否正確了，所以Post是檢查一筆資料的好時機。
那Applyupdate存回資料庫是很多筆資料的異動，這時就適合做整體的檢查，例如明細資料的金額是不是和上方的總金額相同等。如果沒有例外，就真的更新資料庫了。
剛入門的Delphi人員常會覺得這二個指令很麻煩，是不是可以合在一起。可是用久了，就會知道這種方式對實務解決問題有很大的幫助。
在此提供新進人員做參考。

XE10發表會感想

上星期同事Download XE10回來試玩，系統需求居然要60G，這也太大了。所以在參加這次的XE10發表會，心中就覺得應該有很多改變，應該有很多新功能。

不過聽完李維和張子仁二位大師的報告後，覺得X E10並沒有加入太多的新功能。這並不是說二位大師說的內容不夠精彩；事實上這次研討會的內容非常的多，時間感覺也很長，而且過程好像在趕進度，就怕會談不完。那為什麼會覺得沒有太多新功能。因為我覺得XE10在完善先前做的功能。以前XE8有加入3D動畫製作、虛擬實境、IOT等新的應用技術，這次也用了許多的新技術，但是都是在強化使用者的操作感受，例如Compiler速度加快，IDE介面強化等。

這也許是個好消息，做過程式設計師的人都知道，如果要在相同的時間內完成多樣的程式需求，BUG就會很多，常有測試不完整的情形。如果不用對新功能做太多的支援，那就有更多的時間來對先前有BUG或不方便的地方做改善。而XE10給我的感覺就是這樣。

Delphi在XE5之後，每次推出新版本，為了配合要完成Android或iOS的版本更新，做了很多的配合動作，往往Bug就很多，通常都要到Update 1才會穩定。希望這次XE10能夠讓使用者第一次上手就覺得有品質。

響應式網頁設計

因為Google的大力推動，響應式網頁設計(Responsive Web Design)最近非常熱。為了在Google的SEO能提升排名，公司的業務對於這項技術是大力的推動。於是公司的工具網站就被列為改善重點，成為筆者的首要工作之一。

經過三個星期的努力，加上不知如何計算的時間投入，終於做出了一個自己可以接受，別人不知道怎麼想的響應式網頁。

如果你有興趣，可以用手機和PC分別上一下網站  http://tools.hotzsoft.com/ 比較一下二者的不同。

比較好玩的是，為了能如期完成這個工作，筆者用Delphi後端程式來產生前端的響應式HTML網頁。因為程式規則只要訂好，只要測試好一個HTML，其他的HTML網頁就不用逐一測試了，這也是程式的好處。

Delphi Create Form

無意間看到 K TOP 一篇 form create form 再 create form 正確寫法? 的文章，原來以前是這樣做的。剛好最近有客戶問到這個問題，於是就寫了一些作法給Delphi新人做參考。(有時覺得目前Delphi的新進人員蠻可憐的，可以參考的資料不是很多，不像以前Delphi全盛時期，到書店滿滿的一整櫃，可以隨便挑適合自己程度的書看)。

如果有興趣的朋友，就參考看看吧 開啟另一個Form 。

上乘讀者只看想法，中乘讀者想看作法，下乘讀者老是想看一堆程式碼。

最近因緣際會，重讀DELPHI元老級高手 陳寬達 先生的古灰級書籍， Delphi 深度歷險 。其中有一段話筆者覺得說的非常好。對於這句話，引用如下：

對於書籍的範例程式，我是這樣認為的：上乘讀者只看想法，中乘讀者想看作法，下乘讀者老是想看一堆程式碼。

想法要變成作法，需要對電腦運作的方式有深入的瞭解，才能產生要運作的程式邏輯。作法變程式碼，則是對所選的語言的瞭解。這邊應該就是對DELPHI的瞭解。

筆者的工作，一直都在資料庫這個領域。所以久了也就非常習慣用以前的解決方式來解決眼前的問題，反正程式用COPY的最快。累積的經驗不就是為了能快速的解決問題嗎?程式為什麼要有LIBERY，就是要縮短解決問題的時間，不是嗎?

不過這種只做COPY的行為好像比下乘讀者做法還差。程式的世界一直在改變，也許筆者在接新案的同時，也要回想一下以前的解決方式是不是有更好的解決方式。

練功是永無止境的。

關帳討論

筆者最近為了客戶的關帳，寫了一篇有關企業關帳作業的一些小做法，有興趣的朋友可以參考一下。

資料關帳

多層式架構的更新

DELPHI的最大討論區(就筆者的感覺)，應該就是K TOP了，近日看了一篇文章  面對快速持續改善的多層架構系統要如何規劃版本更新架構呢？  覺得很有趣，於是就做了一些回應，想不到一些淺見還得到大家的討論，所以說明一下本人的程式更新方式。還請大家多多指教。

首先，我們會把程式做一些分類，然後做一些存放程式位置的規定。

接下來，會有一個共同的檔案管理區，這個區域存放大家寫的程式，當個人要修改程式時，就要從這個區域CHECK OUT程式，這時程式就得屬CHECK OUT的人了，除非該名程式人員把程式更新CHECK IN，否則是不可以更動的。這樣才不會有程式互改的情形發生。

因為DELPHI這種語言的特性，基本上就是為程式人員設計的，所以大家寫的程式都是在自己的電腦上做測試。在自己Local的開發環境上開發程式是有道理的，因為這時你負責的程式你最大，你可以依自己的方式來解決問題(當然還是要遵守一下大家的規定，例如預設值的EVENT位置、引用適當的公共程式，而不要自己寫一套解決相似問題的程式等)，這樣程式的開發效率最快，DEBUG也很容易。

程式測試OK後，就會把程式上傳到共同的檔案管理區，這時個人的程式就告一段落了。

程式的更新分為AP端和Client端。如果狀況很緊急，程式馬上要用(例如不更新程式就沒辦法發薪水)，那就用平台工具更新資料庫，並把AP程式和Client放上主機。然後請使用者從新進入系統，當使用者使用到更改的功能時，就會自動下載Client端程式，然後用新的程式運作。

至於不緊急的程式，可以等大家都下線時做更新，因為有一堆人做修改，其實也很難知道每一個人改了什麼。但是可以確定，就是在共同管理區的程式是可以正確WORK的。那就用平台工具，把資料庫CREATE一次(平台工具會先比對TABLE，有修改的才做修改)，再把程式全部重BUILD，COPY到主機。這樣更新的工作就完成了。主要是資料庫和AP程式會同步更新，Client端是使用者有用到程式，才比對做更新。

沒有特別好，也很平實，不過會有問題通常都是程式人員程式有BUG，很少是更新的錯誤。