bala nemate rašė: >> Tai merge replikacija: serveris (MSSQL2005) publikuoja db, o >> prenumeratoriai (SQLEXPRESS2005) per push/pull (pagal sąlygas ir >> politiką; ar centras pareikalauja duomenų ar prenumeratoriai, kaip jiems >> ten gaunasi, juos į centrą atoduoda) subscription suneša duomenis. >> Tiesa, pull prenumeravimo režime, prenumeratoriuose tai įmanoma tik per >> windows synchonization manager'į, nes SQL2005EXPRESS neturi SQL Server >> Agent'ų. >> >> http://technet.microsoft.com/en-us/library/ms165686(SQL.90).aspx > > nu reiks giliau pasiskaityti, nes pradžioj, permetus akimis, pasirodė, kad > per pull prenumeratorius susisinchronizuoja visus duomenis su publikuojama > db , o man reikia tik kad būtų perdavimas į centrą. Nauji duomenai > atsiranda nutolusiuose kompuose ir yra įdomus tik vietoje (t.y., vienam > filialui neįdomu, kad atsitiko kitame), o centrui reikia viską turėti. Perdavimas į centrą vyksta visuomet, kai vyksta sinchronizavimas, tačiau tai galima daryti dvejopai: a) serveris (centras) pats pareikalauja (inicjuoja) duomenų sinchronizavimą su prenumeratoriais -- push subscription; b) prenumeratoriai patys (kaip jiems patogu/gaunasi ar pagal kažkokį grafiką) inicijuoja duomenų sinchronizavimą -- pull subscription. Dabar dėl antros problemos dalies: jei duomenų bazėje yra stulpelis ID, tai į jį sukris duomenys iš visų prenumeratorių -- tam būtina atitinkama logika/sistema, kad nebūtų konfliktų (tiek DB/PK lygyje, tiek pačioje programoje). Kiekvienam prenumeratoriui tokiu atveju rašomi filtrai/sąlygos -- kokius įrašus, pagal kokius požymius jis turi gauti/siųsti į publikuojamą DB. Kiek man yra tekę susidurti (esu daręs Rivilės replikavimą į filialus), tai programoje/DB kiekvienas nutolęs, pavadinkime, padalinys, ten/tada kur/kai būtina atskirti, kieno tai įrašai, logiškai apibrėžiamas/identifikuojamas atskirtais ID/operacijų skaitliukais; tuomet filtrai/sąlygos yra gana paprastos, kažkas panašaus: „SELECT ... WHERE site_id = x“ -- į/iš centro į konkretų filialą keliauja tik tie įrašai, kurie tenkina sąlygą. Visa tai yra ganėtinai komplikuota, nes replikavimui reikia apmąstyti/paruošti, suderinti ir DB struktūrą ir programos logiką. Jei ji atitinkamai paruošta, tai galima duomenimis keistis gana lanksčiai (kažkas per centrą vaikšto tarp visų filialų, kažkas tik į/iš centro į/iš filialus). Priešingu atveju vargu ar tau tinka merge duomenų replikavimas kaip toks, nes į lentelę centre sukris skirtingi duomenys (viena problemos pusė), o taip pat duomenys vaikščios iš padalinių į padalinius per centrą. O jei reikia tik duomenų atsarginių kopijų centre (galbūt ir ne vienoje DB), tai galima tiesiog publikuoti į atskiras DB centre, o iš jų pagal tam tikrą logiką (ir poreikį; jei to reikia) sukelti įrašus į vieną centro DB. Iš trumpo problemos paaiškinimo nesupratau kokia yra ta „tikroji problema“ -- ar turima konkrečioji programa pritaikyta (jau) replikavimui ir jį tereikia paleisti, ar kuriama savo sistema, ar pats išmanai replikavimo principus/technologiją MS kontekste, todėl galbūt visa ši tirada ir bereikalinga/beprasmė.