【問題描述】 1.我有5間店每一間店都有獨立的SQL SERVER 且每間店的 table 結構 都一樣 2.總公司這裡也有一個跟每間店的table struct 、SQL SERVER 一樣 3.現在要做的一件事就是『資料彙整的動作』， 用SQL SERVER 的資料更新作業排程，作彙整的動作， 但是只能特定時間、時段作動作，能不能做到即時online的動作、或做法ㄋ 例如：收銀台代號稱作 a 每間店的db稱作 b 總公司的db稱作 c 【請問有啥辦法】 1. a在收銀、結帳時，可以立即更新 b、c兩各資料庫ㄋ。 2. 若欲將所有資料作成同一個，也就是說每間店沒有獨立的db，全部都連到c，這又有一個問題產生ㄌ， 如c所在地停電、斷線則各店亦停擺，這是不備允許的。 3. 若c所在地區不幸停電、斷線，那每間店又可以獨立作業 (因a可以寫入b，但c所在地已恢復供電時，b又要將有異動之資料寫入c)。 4. 若獨立寫一之程式來作定時的資料彙整的動作，又跟SQL SERVER的排程一樣不能即時。 【需求是】 1.當a收銀台作結帳動作時，可以同時寫入b和c或者稍微等一下等系統有空閒時在作傳輸， 且不能發生類似下列的情形喔！ 例如： 當 某甲 從資料庫查出 該品項庫存為 10 當 某乙 也從資料庫查出 該品項庫存為 10 但甲動作比較快 先結帳3個ㄌ 該品項庫存剩下 7 但是乙的畫面上還是10個阿 當乙結帳2個時 該品項應該剩下 5 而不是8(可能因為採用updata) 的錯誤情形發生 也有可能斷線好幾天喔！ 資料要從斷線的那一天哪一筆開始自動彙整到c喔！ 2.在過帳的時候，這種情形比較容易發生，尤其是每間店要做過帳時，如何避免過帳時有資料不一致的情形發生ㄋ。 3.由於目前使用的方式為 Client/Server 的方式，並非 3 層式架構，未來將以 3 層式架構 來重新規劃 或者是如何讓AP server 跟 AP sever 之間相互作溝通ㄋ 請問這該如何做到ㄋ，或其做法、該朝哪方向去著手ㄋ 以上均為內部區域網路 ----------------------------- 感謝各位大大，在百忙之中抽空看這篇文章，不管您有無意願、方法欲 告知於我，我都非常的感謝各位 謝謝您 ^^ 不好一思 打擾了 ^^"

MS SQL Server 有提供 複寫(Replication) 的功能, 你可以去看看這方面的資料. (交易式或合併式的複寫或許可解決你的問題) 以下摘錄 SQL Server 線上說明的部分內容: 快照式複寫 交易式複寫 合併式複寫 =================================== [快照式複寫] 快照式複寫可以精確地將資料以其特定時點的樣子散發出去，且不監視此資料的更新。若要複寫不常變更的資料或是不需隨時更新值 (低延遲) 的情況下，利用快照式複寫是最好的方法。在進行同步化的時候，會產生整個快照集並傳送至「訂閱者」。 適合使用快照式複寫的時機如下： 資料大多屬於靜態資料且不常變更。在變更的情況下，需要發行整份新副本至「訂閱者」。 即使資料副本過期一陣子也可以接受。 ©1988-2002 Microsoft Corporation. All Rights Reserved. =================================== [交易式複寫] 使用交易式複寫時，一開始會將資料的快照集套用在「訂閱者」端，然後當「發行者」端有資料修改時，則會捕捉個別的交易並傳播至「訂閱者」端。 交易式複寫的適用時機如下： 您希望一發生累加式更新時，能立即傳播給「訂閱者」。 您希望交易能依照 ACID 屬性進行。 「訂閱者」與「發行者」之間的連線穩定及/或頻繁時。 交易式複寫使用交易記錄檔來捕捉已發行資料表中資料的累加式變更。Microsoft® SQL Server™ 2000 監視 INSERT、UPDATE 及 DELETE 等陳述式或其他的資料修改，並將這些變更儲存到散發資料庫中，此資料庫將做為可靠的佇列。接著會將這些變更傳送給「訂閱者」，並以其發生的相同順序套用。 ©1988-2002 Microsoft Corporation. All Rights Reserved. =================================== [合併式複寫] 合併式複寫是指將資料從「發行者」散發到「訂閱者」的處理，並允許「發行者」及「訂閱者」無論在連線或離線的狀況下均能進行更新，然後於連線時再合併各站台之間的更新資訊。 合併式複寫的適用時機如下： 多個「訂閱者」需要經常更新資料，並將其變更傳送給「發行者」和其他「訂閱者」。 「訂閱者」需要接收資料、離線變更資料，稍後同步變更「發行者」和其他「訂閱者」。 ©1988-2002 Microsoft Corporation. All Rights Reserved.

如果你用DELPHI的话，可以考虑使用 N-ITER 的结构。 不会经常变动的数据，可以用 TClientDataSet.LoadFromFile的方式，从本地的DISK上取。 销售的数据，需要立即更新 SQL SERVER的数据，则将 TClientDataSet.Delta传递给服务器，由服务器的 Application Server将Delta来更新 SQL Server. 如果断线，则可以等待线路通常的时候，再将 Delta 传递到服务器去更新 SQL Server。当然，在 SQL Server里就不可能在更新数据提交之前，知道更新了。比如库存的总量就不会立即减少了。 把本地的 TClientData里的数据保存到本地的Disk File里。当线路通畅的时候才把Delta提交给服务器。这就是所谓的“公文包”模式。

我個人的看法: 依你所說的方向應較偏向系統的規劃方面, 在程式的設計上應該不太會造成你需求上的困擾才對 所以我認為應先從系統的一些資料流程先下手 這樣的話有時在處理程式的技巧上就不會很花時間了 希望能對你有幫助

個人看法:    我講一個大家都不講的真正答案. 不可能, 也辦不到. 你的做法把你自己逼進死胡同了. 為何不每家切一個 DB , 過帳也不會有問題. (庫存總表另外放總公司,或其他一個地方) 還說會好幾天連不上線, 我咧...............沒辦法. 發表人 - kant 於 2003/07/21 01:45:29

------
Kant

以下資料來自大陸: 中國計算機報 sql server 7．0的資料複製 左洪 資料複製作爲一種重要而有力的資料庫技術使得企業範圍的資料和存儲過程的分佈變得簡單。sql server 7．0提供了完備的複製功能。通過使用複製功能，用戶可以産生資料的拷貝，移動這些資料拷貝到任何其它的地方，並自動化地同步資料，以便分散式環境下的多個資料拷貝保持相同的資料值。sql server的複製功能具有相當的靈活性，這使得在同一台伺服器的資料庫間或依賴網路互連的多台伺服器間可以方便地實現複製。 複製的設計要求 由於應用的多樣性，想要通過一種方案來解決所有問題是不可能的，因此sql server提供了多種資料複製技術以便量體裁衣地適應特定應用的特殊需求。其中，每種技術都將産生不同的好處，也會有不同的限制和約束，這依賴于應用的特定需求。我們可以從三個角度來考慮複製的設計要求：事務的一致性、各站點的自主性和分割資料以避免衝突。當然，不同的分散式應用的需求將依據上述三個角度中的一個或多個角度而變化。 複製的上下文中，事務的一致性意味著在複製完成後，任何參與複製的各站點數據與所有事務只在一個站點上發生所最終形成的資料相同。對於分散式應用中的資料複製來說，至少存在三種可能的事務一致性級別，分別是立即完成的一致性、可延遲完成的一致性和彙聚模式。 各站點的自主性反映了一個站點上的操作對其他站點的影響。如果一個站點能夠執行特定的交易，而且獨立於同其連接的其他站點以及其他站點中的操作狀態，那這種能力被稱爲完全的站點自主性。 分割資料以避免衝突的方法可以賦予用戶自己對交易一致性的控制。用戶可以將資料分割成不同的部分，並將它們部署在多個站點。當然，這樣做將缺乏事務一致性的保證，但並不意味著交易不完整。用戶通過設計適當的應用規則，完全可以使每一個參與複製的站點確保部署的資料最終滿足事務一致性要求。 複製模型的主要部件 基於對複製技術的設計要求，sql server提供了強有力的複製模型。複製模型由出版者、分發者、訂閱者、文章、出版物以及推與拉模式的訂閱組成。 出版者通常是一台伺服器，它可以在複製中爲其他伺服器提供資料。除了需要標識需要被複製的資料以外，出版者還要監視資料的改變並維護站點內所有出版物的資訊。任何將要被複製的資料元素都有一個出版者，儘管它可以被許多的訂閱者更新或被其他訂閱者再一次出版。訂閱者是存儲複製品（資料）和接收資料更新的伺服器。在較早的版本中，資料更新通常只發生在出版者身上。然而在sql server 7．0中，訂閱者被允許進行資料更新。此後，一個訂閱者亦可以成爲出版者，以便爲其他訂閱者提供複製服務。分發者是一台維護著分發資料庫的伺服器。但在每種sql server 7．0複製的類型中，分發者都將充當不同的角色。 出版物由一系列的文章組成，這裏的文章實際上是一組將被複製的資料集合。一篇文章可以是一個表、幾個資料列、某些行，當然也可以是一個存儲過程。一個出版物可以由多篇文章組成。訂閱者只能訂閱出版物而不能訂閱一個出版物中的獨立的文章。在這一點，sql server 7．0與之前版本相比有所修改。 使用推訂閱模式，出版者將向訂閱者“推”資料的改變，而無須訂閱者顯式地發出複製請求。這種方式將複製的控制權保留在出版者手中，在實現近似即時的資料複製應用中是明顯的最優方案。而對於拉訂閱模式，訂閱者向出版者定期／不定期地請求資料更新。對於有大量訂閱者的複製來說，“拉”模型更加適合，尤其是訂閱者需要通過窄帶線路連接出版者時。另外，出版物可以同時支援推和拉訂閱模式。 複製的類型 sql server提供了三種主要的複製類型：快照類型、事務類型和合併類型。一個複製過程除了需要常規的部件以外，還需要兩個或多個複製代理。複製代理主要有：快照代理、日誌讀取代理、分發代理和合併代理。 快照代理準備資料庫構架和被出版的表、存儲過程的初始資料檔案，存儲快照在分發者上，並在分發資料庫中記錄同步狀態的資訊。每個出版物都有自己的快照代理，它運行在分發者上並連接著出版者。日誌讀取代理將被標記爲需要複製的事務，從出版者的事務日誌中移到分發資料庫。每一個使用事務性複製的被出版資料庫均有自己的日誌讀取代理，它運行在分發者上並連接出版者。分發代理將分發資料庫中保持的事務和快照任務直接移動到訂閱者。當推訂閱被創建時，每個爲立即同步而建立的事務性出版物和快照出版物均擁有自己的分佈代理，它運行在分發者上並與訂閱者相連。不需要立即同步的事務性和快照出版物將在一對出版者／訂閱者間共用分發代理，它運行在分發者上並與訂閱者相連。而對於拉訂閱模式來說，快照和事務性出版物都擁有運行在訂閱者上分佈代理，而不是運行在分發者上的。合併代理通常應用於合併出版物，它可以在最初快照生成後，移動和協調新增加的資料改變。 快照複製就像拍照片一樣，一次記錄下被出版資料的資訊。在複製過程中，訂閱者被整個資料集更新。所以，快照複製將發送所有的資料給訂閱者，而不是僅僅發送被改變的資料。當然，如果文章非常大，複製將需要極大的網路資源用於資料傳輸。所以，再使用快照複製時應該綜合考慮整個資料集的大小和資料是否經常被改變。快照複製是最簡單的複製類型，它可以確保可延遲完成的一致性，另外，如果訂閱者並不更新資料的話，它也提供了高度的自主性。 sql server的事務性複製可以支援兩種類型的物件複製：表和存儲過程。用戶可以在一個出版物中，定義一篇文章，它可以基於一個表中的部分或全部的資料。與表物件的情況類似，用戶可以選擇一個或多個存儲過程作爲被複製的文章。如果使用合適的話，基於存儲過程的複製將會使應用具有更好的性能，例如可以大大減少網路的通訊量。事務性日誌使用事務日誌來監視文章中的資料改變。 合併複製監視源資料庫中的改變，並同步出版者和訂閱者的資料值，其中無論是出版者還是訂閱者均可以更新資料。在合併複製中，出版者是創建出版物的伺服器。儘管出版物由出版者創建，當出版者同訂閱者發生衝突時，出版者並不會自動地成爲主宰衝突的一方。衝突的主宰者可以由用戶定義的條件來決定。與此類似，目的資料庫中的資料改變將被告知源資料庫。合併複製涉及快照代理和合併代理的參與。快照代理將準備包含有被出版資料表的結構與資料的快照文件，在分發者上存儲這些文件，並在分發者的分發資料庫中記錄同步任務。合併代理應用存儲在出版資料庫表中的初始快照任務於訂閱者。它也合併在最初快照被建立後增加的資料改變，並依據用戶配置的規則或使用用戶自定義的解決方法來協調衝突。 複製工具 replication wizards極大地簡化了開發、實現和維護複製的步驟。其中，configure publishing and distribution wizard被用於幫助用戶將一台伺服器標識爲分發者，並可以選擇標識其他的複製部件；create publication wizard可協助用戶創建出版物；push subscription wizard可協助用戶從一台伺服器上將出版物“推”到一個或多個伺服器甚至伺服器組上；pull subscription wizard可協助用戶從一台伺服器上的出版物“拉”到其他伺服器的資料庫中；disable publishing and distribution wizard可協助用戶在一台伺服器上禁止出版、分發；replication conflict viewer可協助用戶查看和解決合併複製過程中發生的衝突。 通過使用sql server enterprise manager，用戶可以跨多台伺服器建立一個完整的複製環境。sql server enterprise manager使用replication monitor來監視事先計劃的四種複製代理（快照代理、日誌讀取代理、分發代理和合併代理）的處理過程。replication monitor也維護了任務的列表、佇列和歷史記錄，這對於解決複製中出現的問題是非常有用的。另外，replication monitor也提供了一種簡單的方法，用於爲複製事件設置報警。當一個事件發生時，replication monitor會自動地回應，同時可以執行一個用戶定義的任務，也能向指定的管理員發送e－mail或一個傳呼消息。 sql server 7．0作爲一個分散式資料庫系統，複製是一個非常重要的部件。同時，由於此版本對移動計算的支援，複製功能及其工具更是必不可少。儘管sql server 7．0依然沿用了sql server 6．5中的“出版－訂閱”的模式描述，但其複製類型被擴展到三種不同的類型，他們正是基於一致性同自主性的比例來定義的。通過對應用靈活地使用複製，用戶可以獲得強大的功能。無論是對企業內的分散式資料庫系統，基於移動計算的資料庫應用，還是olap應用，sql server 7．0均可以執行更好的複製服務。 Kant

------
Kant

您可以參考宣揚電腦股份有限公司所使用EEP作出來的POS產品

不妨利用三層式架構來解決問題 APServer與APServer之間協同作業 當系統規模擴大時，公司內部的Application Server可能不只一台，或是台灣、大陸兩地之間的系統是透過兩台Application Server來協調運作時，EEP除了提供內建異質資料庫之間同步的機制外，也提供APServer與APServer之間協同作業。 【說明】 1. 由Client端或是Schedule啟動ApServer中的Method2。 2. Method2為APServer1中的一個函式Method。 3. Method2方法中使用CallRemoteMethod方式至APServer2中找到Method5，依據Method5的內容來處理遠方的資料。假設Method2的內容如下： procedure TsInv04010_SEL.GetRemoteDataCallMethod(Params: Variant; out ReturnVal: Variant); var Cust_no:String; vOutput:Variant; begin Cust_no:=Params[0]; vOutput:=ServiceManager1.CallRemoteMethod( '168.192.2.2', 'sInv02010', 'GetCust_name', VarArrayOf([Cust_no])); ReturnVal:=vOutput; end; 4. Method5內容如下: //傳入客戶編號取得客戶名稱 procedure TsInv02010_SEL.GetCust_nameCallMethod(Params: Variant; out ReturnVal: Variant); var cust_no:string; aQuery:TQuery; begin cust_no:=Params[0]; try ServiceManager1.CreateQuery(Database1.AliasName, aQuery); aQuery.close; aQuery.Sql.Clear; aQuery.Sql.Add('SELECT CUST_NAME'); aQuery.Sql.Add('FROM CUSTOMER'); aQuery.Sql.Add('WHERE CUST_NO=''' cust_no ''''); aQuery.Open; ReturnVal:=VarArrayOf([aQuery.FieldByName('CUST_NAME').AsString]); finally aQuery.Free; end; end; 5. 取得資料庫資料回傳給ApServer2。 6. ApServer2將資料傳給ApServer1。 7. ApServer1將資料傳給Client或是寫回資料庫。

提問者您好:


以上回應是否已得到滿意的答覆？


若已得到滿意的答覆，請在一週內結案，否則請在一週內回覆還有什麼未盡事宜，不然，
將由版主(尚無版主之區域將由副站長或站長)採自由心證,選擇較合適之解答予以結案處理，
被選上之答題者同樣會有加分獎勵，同時發問者將受到扣 1 分的處分。不便之處，請見諒。


有問有答有結案，才能有良性的互動，良好的討論環境需要大家共同維護，感謝您的配合。

------
我是機器人,我不接受簡訊.