在一些大型的生產(chǎn)管理系統(tǒng)中，往往都會應用到人工錄入歷史數(shù)據(jù)功能，從而對生產(chǎn)數(shù)據(jù)進行系統(tǒng)的管理，這部分的數(shù)據(jù)不能夠在儀表中采集到，只能通過人為的填寫，這部分數(shù)據(jù)不但要存儲到客戶端，還要上傳到服務器端進行顯示，這樣就會引發(fā)一個關鍵問題：如何做到服務器端與客戶端的數(shù)據(jù)同步？下面提供三種解決方案。
第一種：服務器端直接調(diào)取客戶端數(shù)據(jù)。
這種方案制作過程比較簡單，只需要在服務器端針對于相應的客戶端建立一個數(shù)據(jù)源，選擇遠程節(jié)點，并將IP指向客戶端即可。如下圖所示。
其中：主機名/地址為客戶端的IP地址。當這一切配置好之后，只需在自由報表中調(diào)用GetHisDataEx()函數(shù)，在運行的情況下就可以調(diào)取到客戶端的歷史數(shù)據(jù)。GetHisDataEx()函數(shù)的聲明如下：
GetHisDataEx(string DataSource,string VarName,int StartTime,int MilliSecond)。
其中：DataSource要填寫相應客戶端的數(shù)據(jù)源名稱，VarName要填寫該數(shù)據(jù)源下的數(shù)據(jù)庫變量名稱。這樣當系統(tǒng)運行時，在服務器端就可以調(diào)取到客戶端的數(shù)據(jù)了。但這中方案存在一個弊端，即當客戶端停止運行或著客戶端與服務器端通訊終端時，那么在服務器端則看不到客戶端的任何數(shù)據(jù)。
第二種：客戶端直接向服務器端插入歷史數(shù)據(jù)。
這種方案與第一種方案基本類似，需要在客戶端建立一個數(shù)據(jù)源，并指向服務器端，客戶端在保存歷史數(shù)據(jù)時調(diào)用InsertHisDataEx()函數(shù)，該函數(shù)的聲明如下：
InsertHisDataEx(string DataSource,string VarName,real Data,int StartTime,int MilliSec)。其中，DataSource要填寫相應服務器端的數(shù)據(jù)源名稱，VarName要填寫該數(shù)據(jù)源下的數(shù)據(jù)庫變量名稱。這樣在客戶端與服務器端通訊正常的狀態(tài)下，保存動作執(zhí)行時，客戶端就會直接向服務器端插入歷史數(shù)據(jù)。服務器端在報表中調(diào)用GetHisDataEx()函數(shù)就可以調(diào)取到本地相應的數(shù)據(jù)。這種方案的弊端則是增大了客戶端的負荷，會導致客戶端運行速度變慢。優(yōu)點則是在服務器端和客戶端都存有數(shù)據(jù)，相當于做了一次數(shù)據(jù)備份。
第三種：客戶端觸發(fā)服務器端自行保存歷史數(shù)據(jù)。
這種方案制作過程相對于前兩種要復雜一些，首先要在服務器端建立一個數(shù)據(jù)源指向客戶端，并在服務器端建立相應的點關聯(lián)到客戶端的點上。其次，在服務器端數(shù)據(jù)庫全局腳本中編寫一段存儲這些點PV值的歷史數(shù)據(jù)的腳本，通過一個標志位觸發(fā)存儲動作。客戶端在保存歷史數(shù)據(jù)時要把相應點的PV值也做修改，這樣服務器上做了相應關聯(lián)的點的PV值也會跟著做改變。在通過客戶端觸發(fā)服務器端的保存標志位，服務器端就會自行的將這部分數(shù)據(jù)存儲下來，在運行的狀態(tài)下通過報表調(diào)用GetHisDataEx()把歷史數(shù)據(jù)調(diào)取出來即可。還可以在數(shù)據(jù)源高級選項中把數(shù)據(jù)故障恢復勾選上，如下圖所示。即使因通訊中斷，客戶端無法觸發(fā)服務器端的保存標志而導致兩端數(shù)據(jù)不同步，在通訊恢復時，客戶端也會自動的把這部分數(shù)據(jù)長傳到服務器中，這樣就更加全面的保證了兩端數(shù)據(jù)的同步性。
第三種方案完全的解決了第二種方案中增加了客戶端負荷的弊端，也解決了第一種方案中通訊中斷時服務器端看不到之前歷史數(shù)據(jù)的弊端，同時還具備了前兩種方案中不具備的優(yōu)勢：故障數(shù)據(jù)恢復，因此在類似這種的案例中，推薦使用第三種方案。
