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