Ja radim u SQL Serveru 2000 a malo sam i radio u SQL Serveru 2005, ono što znam za SQL server 2000 a tiče se konkurentnosti podataka na samo sql serveru je setovanje isolation levela, ubedjen sam da je ista stvar i na SQL Serveru 2005 a možeš da proveriš u BOLu.

SET TRANSACTION ISOLATION LEVEL opcija

opcija može biti:
read uncommited
read commited
read reapetable
serializable


ono što je bitno je i šta možeš da radiš sa svakom od opcija



Nadam se da ti je ovo trebalo.

Ali gdje uopće da namjestim taj isolation level??

Možeš da ga staviš u stored proceduru, pre nego što eksplicitno kažeš BEGIN TRANSACTION

Evo ti primera pa će ti verovatno biti jasnije

u QA otvori dva nova prozora za pisanje upita, to će simulirati kao da imaš dva konkurentna korisnika sa dve odvojene konekcije

u prvom prozoru iskopiraj sledeći kod, nadam se da imaš pubs bazu.


u drugom prozoru iskopiraj sledeći kod


E sada smo spremni da simuliramo dva konkurentna korisnika.

1. Izvrši prvi skript sve do COMMIT TRAN, taj deo ćemo kasnije da izvršimo.
2. Izvrši ceo drugi skript, videćeš da će se globus vrteti što znači da drugi korisnik čeka da upiše podatke u tabelu koji imaju isti kriterijum za primarni ključ kao select prvog korisnika tj. oba korisnika žele da rade nad istim resursima
3. Sada se vrati na prvi skript i izvrši samo COMMIT TRAN.
4. Vrati se na drugi skript i videćeš u messages da ti je upisan jedan red tj. insert je izvršen ali tek pošto je prvi korisnik commitovao svoju otvorenu transakciju.

E sad malo objašnjenja
Kada se izvši prvi korak to znači da konekciji prvog korisnika je setovan isolation level na serializable i da je otvorio transakciju gledanja odredjenih podataka. Kada drugi korisnik želi da radi nešto sa podacima koji zadovoljavaju kriterijum prvog korisnika tj. drugi korisnik pokušava da insertuje podatke koji počinju BU a za to vreme prvi korisnik je selectovao podatke sa like BU% i pri tome ima otvorenu transakciju i isolation level serializable, a ako pogledaš gornju tablicu u takvoj sitauciji konkuretni korisnik nemože ni da update, insert ni delete podataka već mora da čeka da prvi korisnik ili commituje ili rollbackuje otvorenu transakciju.
Kada se izvrši treći korak tj prvi korisnik je commitovao svoju otvorenu transakciju to znači da više ne drži lockove nad podacima tako da konkuretni korisnik može da izvrši svoj insert i nemora više da čeka.

Nadam se da će ti sada ovo malo više pomoći.


_{[Ovu poruku je menjao dekibre dana 15.06.2007. u 16:21 GMT+1]}

Znači, ovo će vrijediti i u slučaju kada se neka aplikacija kao klijent spaja na bazu?

Rekao sam ti, najbolja varijanta ti je da stavljaš skript u stored procedure i u one procedure koje imaju veći prioritet stavljaš restriktivniji isolation level na taj način se obezbedjuješ da ti konkuretni korisnici nemogu "smetati". Samo dobro prouči gore navedenu tabelu i još bolje pročitaj u BOLu sve o setovanju isolation levela kako bi znao koji ćeš nivo kada da upotrebiš.

@itf
Da razjasnimo nesto - da li se tvoje pitanje odnosi na :
1. Prevlacenje podataka na klijenta-promene na skupu podataka "offline" i zatim postovanju tih promena (ako je neko napravio izmene u podacima sto je ranije prevuceno - ovaj tip "konkurencije"... ) ili
2. Konkutrentan pristup pri samom citanju/pisanju na serveru?

@aleksandarpopov

Ovo su dobra pitanja:
pogotovo batch update korisnika koji rade sa podacima u offline režimu.

Ovako... općenito s Access bazom koristim prvi način. Znači, spojim se batchOptimistic. Uzmem podatke i obrađujem ih u memoriji, a samo na spremanju izmjena se nakratko spajam na bazu. Konkurentnost provjeravam iz klijent aplikacije.

E sad... To isto želim izvesti ali pomoći SQL Server baze, a gornji pristup kao za Access bazu mi ne radi. Meni je sasvim svejedno da li će to biti stalna konekcija ili batchOptimistic, ali želim nešto ovako:

aplikacija: "Dogodila se konkurencija među podacima. Želite li ponovo učitati dataset?"

i ako ja kažem YES, da mi se ponovo učita dataset. I tu je meni najveći problem jer ja ne znam kako bi sa klijent strane uspio detektirati konkurenciju.

Stoga, da li ja mogu u samoj bazi definirati ponašanje klijenata prilikom konkurencije podataka (ono što me najviše zanima), ili baš moram programski u klijent aplikaciji riješiti taj problem već nekako?

BatchOptimistic ti mora raditi nezavisno od baze posto je to fakticki klijentski skup podataka tj. taj dataset nema veze da li je preko ADO komponenti recimo queryja prevuceno sa Access baze ili Ms sql ili PostgreSql ili Oracla potpuno je nebitno. Koliko je meni poznato, kada koristis batch opt. cuvaju se podaci u Originalnim podacima i o eventualnim izmenama (sve ovo ide preko parametara) u datasetu. Kada ti pokusas da postujes promene, ako je doslo do nekih promena (neko je promenuo originalne vrednosti bilo kog sloga tog dataseta u medjuvremenu) postovanje nece uspeti i bacice gresku koju ti mozes da uhvatis i obavestis korisnika sta se dogodilo ....

U tome je problem:

1. Uhvatim grešku
2. Analiziram i detektiram da li se desila konkurencija i ako se desila...
3. Ponovo se spojim na bazu i uzmem friške podatke

Ovo bez greške radi na Access bazi, ali kod SQL servera prilikom točke 3 ne učita mi ništa.... Jednostavno ne radi. Stoga, ima li kakvo rješenje koje se može napraviti u samom SQL serveru?

Ovo sto tebi treba nema veze sa bilo cime na sql serveru. Jedino tvoja klijentska aplikacija moze nakon sto je uhvacena greska tj. prikazana poruka korisniku da je doslo do konkurencije prilikom upisa u bazu, kazes mu da mora da otkaze promene i ako hoces mozes ponovo da okines upit koji ce uzeti sveze podatke, ali ti to moras sam isprogramirati na klijentu (mada ne znam zasto bi to radio - bolje ti je da samo obavestis korisnika da ga je neko preduhitrio u snimanju i da otkaze promene u batch-u, pa neka on odluci sta ce dalje)...

Nije to samo tako jednostavno jer kada program javi da je došlo do konkurencije zaključa mi problematični zapis i prisiljen sam refreshati cijeli dataset. Uglavnom, nije bitno. Ako se ništa ne može na server strani onda ću već nešto smisliti za aplikaciju. Hvala

Ja lično nisam radio ovo što ću ti predložiti ali sam negde pročitao da su tako neki radili.

Da bi održao konkuretnost podataka koje u batchu prebacuješ sa klijenta a da ti se obeležje svakog reda nalazi na serveru, stvarno nemogu da se setim gde sam ovo pročitao, tako što se željenoj tabeli doda jedna kolona tipa timestamp koja se menja automatski svaki put kada se podaci updateuju. Tako da kada pokopiš podatke ti za svaki red imaš i njegov timestamp koji si isčitao a kada podatke vraćaš pre nego što izvršiš update proveriš da li se timestamp u medjuvremenu promenio.

Jeste, može da se doda timestamp kolona u svaku tabelu.

Kada se radi update samo se proveri da li je to polje promenilo vrednost. Ako jeste, znači da je neki drugi korisnik već izmenio isto polje pa izmene treba odbaciti.

Ovo se još naziva i "optimistic concurrency."

Citao sam i ja o tome to je ok resenje ako se ne koriste datasetovi, ali malo mi je suvise posla ako isti rezultat mozete dobiti sa manje posla - barem kada se koriste datasetovi, kada se stavi u ADO na batch optimistic kursor ili u ADO.NET-u Optimistic concurrency kada se generise WHERE uslov za UPDATE naredbu on ne doda samo vrednost primary key-a u uslov vec dodaje i @oldValue (prva ucitana) za sve kolone i ako se ne slazu vrednosti - znaci da je neko vec nacinio izmene - sve u svemu dobija se isti rezultat.

_{[Ovu poruku je menjao aleksandarpopov dana 18.06.2007. u 18:56 GMT+1]}

^Pa jeste.. isto je.

Ako se doda timestamp, onda se procita vrednost tog polja prilikom čitanja zapisa. I to je onda "oldValue". Kada radiš update, trebaš da taj "oldValue" uporediš sa trenutnim, tj. otprilike

UPDATE table1 (ime, prezime) VALUES ('pera', 'peric') WHERE kupacID=17 AND time_stamp = @time_stamp_old

I to je to.

Ako je polje time_stamp (koje je tipa timestamp) u međuvremenu izmenjenou, neće ni doći do apdejta zbog uslova u WHERE. Ako UPDATE uspe, time_stamp se automatski postavlja na novu vrednost.

Pozdrav.