Najelegantnije i najbezbolnije -> Replication .
E sad pitanje za tebe da li to tvoja baza podrzava .

Mogao bih da resis pomocu neke log tabele koja bi ti belezila sve update,insert i delete upite nad bazom,
koji bi se posle toga slali u nekom odredjenom vremenskom intervalu na server, i da belezis kada je zadnji
put vrsen prenos podataka prema serveru.Kada se prekine konekcija, sve promene ce se i dalje snimati u
tu tabelu na desktop bazi i kada se konekcija vrati automatski ce se preneti na server.

U toj situaciji ubedljivo najelegantnije resenje je replikacija, posle njega full restore desktop baze na serveru. Sve ostalo je samo bespotrebno komplikovanje.

Ako je desktop samo jedan klijent koji upisuje i u oblak onda je najjednostavnije kada zatreba pobrisati bazu u oblaku i prepisati podatek sa dekstopa.

Ako ima vise klijenata stvar je mnogo komplikovanija, mora se raditi na nivou sloga i mora podrzati sinhronizaciju novog sloga, brisanja sloga i izmene postojeceg sloga.

Kako ovo resiti zavisi od dosta toga, a nisi bas detaljisao sa objasnjenjem cemu sve to sluzi i kako treba da radi, koje su platforme na desktopu i u oblaku i slično.

desktop je c# a baza na serveru je mysql, i ima vise korisnika, tako da replication pada u vodu sto mi nije palo napamet.

Odlucio sam se za sledecu varijantu:

kada se izgubi konekcija pocinje da se generise xml koji ce kasnije kada se povrati konekcija da se posalje na web server i da ubaci zaostale recorde u bazu. Cini mi se da je ovo najbezbolnije resenje i da nema potrebe za proverom recorda ako se uradi kako treba.

Svako ko je ikad radio sa bilo kakvom sinhronizacijom podataka zna da je ovo ume da bude nezahvalan i zaeban posao,
koliko god se cini u pocetku da je lagan. Zato i postoji replikacija.

Kao što deerbeer rece replikacija za to i postoji, i veruj mi potrošićeš sate na ovaj prolem a nećeš sigurno uspeti da napraviš bolje i funkcionalnije rešenje nego devovi iz MySQL-a. Ovakve probleme je uvek bolje rešavati na sistemskom (RDBMS) nego na aplikativnom nivou.

ali replikacija je ok ako imam jednog desktop usera, ali sta cemo ako imam 2 desktop usera na razlicitim lokacijama???

Dve baze za jedan posao su generalno loše rešenje, bez obzira gde se one nalazile. A ti ih izgleda imaš i više.

Šta će ti uopšte dve (ili n baza). Dovoljna je jedna, na serveru.

Sve operacije sa podacima se ionako moraju raditi online (u protivnom ti baza na serveru ne treba). Eventualno, unos novih podataka možeš raditi i offline, pa ih kasnije podići na server. Zapiši novi record u neki xml ili ako baš insistiraš u lokalnu bazu, pa kada budeš ponovo online digni ih gore i obriši.

Ne slazem se. Postoji sijaset scenarija i strategija koje favorizuju decentralizovan sistem. To sto svima cloud peni na usta je drugi problem...

Ja se sa tobom slažem.

Ali čovek hoće cloud koji nije cloud?!?

Pa, tehnicki sve sto je sa druge strane internet rutera je cloud (ko se seca prvih distribuiranih tehnickih dijagrama internet je predstavljan kao oblak )

Ne postoji definicija clouda, i svaki cloud provajder ce ti reci da je cloud bas ono sto oni prodaju i svaki cloud advokat ce ti reci da je cloud ono cega su oni fanboji Za neke je to salseforce, za neke amazon services, za trece azure, za cetvrte data.com, itd. U svakom slucaju mnogo marketinskog magljenja pa nije ni cudo sto ljudi ulaze u struku verujuci da je svaki udaljeni server "cloud", jer on to u principu i jeste u izvornom znacenju

U svakom slucaju, on topic, +1 za replikaciju

Slazem se da je cloud buzzword ali mi je onda isto nelogicno kad pocnu da se raspravljaju oblacari i antioblacari. :)
Nego.. da li je uopste moguce ono sto covek zeli... da ima n korisnika sa lokalnim bazama i centralna baza, a da svaki klijent moze da ispadne u proizvoljnom trenutku i dok je offline "skuplja" promene koje ce se naknadno podici u "oblak". Meni to ne pije vodu bas

Moze preko replikacije veoma lako samo sto to povlaci neka dizajnerska resenja koja nisu najoptimalnija u odnosu na single-server scenarija ali su neophodna da bi se izbegle kolizije, npr menadzment auto-identity polja i kljuceva. Konkretna dizajnerska resenja zavise od RDBMSa koji se koristi i od sistema replikacije, OP medjutim nije naveo koju bazu koristi.

Npr, za MSSQL: http://msdn.microsoft.com/en-us/library/ms152543.aspx