Ne brini, nisi poludeo, jednostavno to ne moze
Sa prelaskom iz ADO u ADO.NET ukinut je dinacki client pesimistic kurzor. Microsoft je zakljucio da ti, ja, pera, zika i mika nemamo pojma o programiranju i ukinuo nam je mehanizam kojim smo mogli da kocimo bazu
Sto je najgore u pravu su, lose odradjeni dinamicki kurzori su glavna prepreka skaliranju aplikacije kako vertikalno tako i horizontalno i uzrocnik mnogih deadlock situacija. Mene je to uzasno nerviralo u pocetku ali se brzo naviknes, a za ono malo situacija gde mi je trebao pesimistic locking koristio sam stored procedure.
Citat:
Dakle, zahtev je prilicno jednostavan: na tri racunara u mrezi treba da se vrti isti program povezan na jednu bazu, i kada neko na jednom racunaru unese neki podatak ta izmena treba da se odmah vidi na drugim racunarima i obrnuto.
Generalno ne postoji efikasan nacin da emuliras dinamicki kurzor u .NETu, jedini nacin je da periodicno ucitavas nove/promenjene podatke koristeci timestamp kolonu i mergujes sa radnim dataset-om ako je npr MAX(timestampcol)>tvogmaxucitanog, glavno pitanje medjutim je koliko ti je automatski reload vazan? Sve .NET komponente se uglavnom baziraju na tome da rade sa offline podacima na koje su bindovani i samim tim su veoma 'liberalne' u svom pristupu podacima, tj nista ne kesiraju vec uvek vuku podatke iz izvora, sto bi za dinamicke kurzore znacilo drastican pad performansi i jos gori locking nightmare.
Izuzev povratka na ADO nema nacina da ovo odradis automatski i osudjen si na disconected optimistic concurrency.
Citat:
Takodje, posto se radi o nekim tabelama koje imaju ogroman broj podataka, ne zelim da se svi podaci prebace na klijenta pa da on tada sa njima barata, vec da klijent uzme sa servera samo onoliko podataka koliko mu je potrebno da ih prikaze (recimo u gridu) a ako korisnik skroluje grid da po potrebi ucitava ostale slogove.
Ovo mozes da izvedes i kroz dodatne select komande u dataadapteru, a ako koristis Linq to SQL vec imas podrsku za to kroz Skip() i Take() metode koje rade savrseno. Poenta je da imas formiran SELECT koji parametrizovano ucitava podatke od do nekog kriterijuma, mada je implementacija ovoga u gridu iskreno mucenje. Ja npr za te svrhe koristim 3rd party 'huge dataset' proizvode, narodski poznatije kao 'virtual mode datasets'. Kosta nesto para ali radi posao npr koristio sam ga za prozor u tabelu sa nesto malo jace od 1.8mil redova i radilo je ultra brzo i ucitavalo samo one podatke koji se prikazuju i sve je izgledao "dinamicki" iako je u pozadini dataset odradjivao on-demand offline ucitavanje.
Citat:
Nekim tabelema je primarni kljuc autoincrement i treba da, kada neko unese novi slog, taj slog dobije kljuc u skladu sa onim sto se unosi i na drugim racunarima, a ne neki interni.
Linq to SQL i EF to resavaju automatski u pozadini, na DataSet-u se to resava tako ste se na ID polju postavi seed i increment na -1, tako da ce novi redovi u DS-u dobijati kljuceve -1, -2, itd i nece se klati sa realnim kljucevima iz tabele, a kad se uradi insert adapter ce ignorisati ID polje i posle inserta ce ucitati novokreirani red koji ima novi realni ID.