Salut, am o problema de conceptie...anume:
Se da un sediu si un punct de lucru (care probabil vor fi mai multe). La sediu se instaleaza o aplicatie pt gestiunea unor servicii (emitere de contracte) si aceeasi aplicatie se instaleaza si la punctul de lucru. In fiecare locatie va exista un SQL Express 2005 si o conexiune la net (doar la sediu este IP fix, la punctul de lucru IP-ul se modifica...). Contractele emise (in marea lor majoritate se emit la punctul de lucru) vor avea un numar unic crescator - dar unic la nivel de firma! As vrea ca datele sa se centralizeze in serverul de la sediu imediat sau nu neaparat (de acolo se vor exporta catre conta) dar respectind unicitatea numerelor de contract. Cum pot sa fac asta?

Multumesc,
Puiu

La o prima vedere, ai citeva variante simple:
1. Repartizezi plaje de valori pentru punctele de lucru( de la 1 la 1000, de la 1001 la 2000, etc)
Avantaj : usor de facut
 Dezavantaj: refaci plajele daca vreunul depaseste
2. Punctul de lucru cere de la sediu un numar( acela insereaza un "fake"contract si ii intoarce numarul) pe care il scrie
Avantaj: unicitate garantata
Dezavantaj: se blocheaza daca nu ai conexiune internet
3. Renunti la numar unic si lasi ceva de genul Contract numarul  <Punct_De_Lucru>_<Numar> - care e unic. Faci replicare intre servere si identifci contractul prin GUID.
Avantaj : usor de implementat
Dezavantaj : Nu stiu daca businessul iti da voie sa renunti la numar, dar, dupa cite stiu eu, contractul trebuie sa fie identificat unic  - si respecta cerinta - si nu neaparat printr-un numar...

---

Ignat Andrei
http://serviciipeweb.ro/iafblog

Pentru mutatul contractelor n-ar fi nevoie de replicare ci se poate implementa service broker - lucru posibil si intre servere SQL Express 2005; in ceea ce priveste unicitatea numerelor de contract as face o regula : concatenez la codul numeric al contractului un cod de pct de lucru apoi o data, de exemplu , PCT1-03122008-0001 , adica pct de lucru nr 1 , la data de azi 03.12.2008 si cu nr 1 , pe langa unicitate stii si de unde si cand a venit contractul

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Clientul trebuie sa plece de la punctele de lucru cu contractul in mina? Atunci punctul de lucru trebuie sa emita numarul de contract independent chiar daca nu poate contacta centrul, si in general asta se rezolva encodind in numarul contractului locatia care la emis (de. ex. 'contractul 12-301' unde 12 este codul locatiei, 301 este numarul serial emis la locatia 12). 'Numerele' sint varchar nu int. Sint unice pe firma pentru ca sint unice la locatie + codul locatiei este unic. Spre exemplu numerele de conturi de banca contin astfel de coduri in ele.
E permis sa ai lipsa in serii? Asta trebuie sa intrebi pe cei de le Legal, nu pe conta. Daca nu e permis, e destul de complicat, trebuie sa te asiguri ca salvarea unui nou contract este comisa in baza de date inainte de a adauga unul nou, altfele ramii cu gauri in caz de rollback, si trebuie sa blochezi stergerile (ex. sa folosesti un cimp 'is_deleted').

Cit despre exportul de date, daca potzi instala un VPN atunci poti face replication si e probabil cel mai simplu de configurat si folosit, si va scala pina la citeva zeci de centre. Exista restrictii de licenta in replication pentru Express (poate fi numai subscriber), deci vei fi fortat sa ai pull Merge replication, chiar daca Transactional cu push de la puncte de lucru era clar mai buna dpdv al overhead-ului de replicare.

Daca nu poti instala un VPN sau ai prea multe puncte pentru ca replicarea sa fie viabila, atunci trebuie sa faci sincronizarea de mina via WebServices call (unserviciu http la centru apelat de puncte) si ramine sa rezolvi 'doar' problema de retry ca sa obtii semantici de 'exactly-once'.  Service Broker itzi rezolva problemele de retry si ordonare ('exactly-once-in-order'), dar daca adresa de IP a punctelor se schimba prea des o sa ai probleme cu routing-ul.

Daca centrul poate sa tolereze delay-uri mari (ex. o zi) pina primeste update-urile de la puncte atunci potzi face ceva gen un 'in-house'  log-shipping de la puncte la centru in fiecare noapte, transfer prin FTP de ex, urmat de job-uri de SSIS la centru care sa consolideze datele.

---

http://rusanu.com

numerele de contract trebuie sa fie consecutive si fara 'lipsuri'. Contractele anulate trebuie sa poata fi listate. Cred ca pina la urma, cel mai simplu ar fi daca nu s-ar mai folosi servere la punctele de lucru si s-ar lucra direct in serverul de la sediu....cu dezavantajele de rigoare... Daca compurile de la pct de lucru si sediu sint cu XP Home pe ele, ce ar trebui sa folosesc pt a face VPN intre ele? Nu se pune problema sa se achizitioneze un server autentic - e criza!!

Poti incerca o replicare cu service broker,pentru sql express nu stie de replicare.Iti poti defini update triggers pe tabele de lucru de la care vrei sa se replice datele catre centru ,iar in cadrul trigerului deschizi un queue service broker si trimiti mesajul sub forma de xml.Vezi pe blogul lui remus ca are o aplicatie asemanatoare

---

Secolul XXI ori va fi religios ori nu va fi deloc

crestinul:

sql express nu stie de replicare

Nu baga strimbe. Express stie de replicare foarte bine: http://msdn.microsoft.com/en-us/library/ms165700(SQL.90).aspx
Exista restrictii, dar nu inseamna ca nu stie.

---

http://rusanu.com

rremus:

crestinul:

sql express nu stie de replicare

Nu baga strimbe. Express stie de replicare foarte bine: http://msdn.microsoft.com/en-us/library/ms165700%28SQL.90%29.aspx
Exista restrictii, dar nu inseamna ca nu stie.

Asa e .Scuze!

---

Secolul XXI ori va fi religios ori nu va fi deloc