Samo da javim da sam, u medjuvremenu, testirao kod i epilog je:

- triger se okida za 'statement' -> znaci, tek kada se prethodni update / insert u cjelini izvrsi. U prevodu, ako radite update N rekorda neke tabele, triger ce se okinuti tek kada se zavrsi update svih N rekorda,
- tabela Inserted sadrzi svih N rekorda, i
- DA, moguce je primijeniti cursor nad tabelom Inserted, u okviru trigera.

Sto se mene tice, mozete zakljucati ovu temu.

Pozdrav

Za pohvalu je sto si sam iskopao i naucio kako trigeri rade. Bravo. Jedino brine upotreba kursora u trigeru. Kursori generalno lose resenje za rad sa pravim podacima - ama bas sve moze da se uradi bez kursora. Kursori su spori i tvoji update bi mogli da traju jako dugo, jer svaki put mora de se izvrsi spori kursor.

Kao prvo, hvala na odgovoru i javljanju.

Ja radim kao 'support develeoper' na aplikaciji projektovanoj i radjenoj, krajem 90-ih i pocetkom 2000-tih i nemamo bas puno vremena za razvoj i novotarije.

Ovo rjesenje (koriscenje trigera) je naslijedjeno. Ideja mi je bila da izbacim triger i da to, sto radi triger, odradim 'izvan' trigera - shvatio sam, posto nemamo ama bas nikakvu dokumentaciju, da bi ta izmjena mogla da prouzrokuje 'velike' side-effects, pa sam odustao.

S druge strane, zainteresovan sam da znam (naucim) koja su rjesenja za rad bez kursora ?

Konkretno: treba da 'prodjem' kroz tabelu 'Inserted' i za svaki rekord (u toj tabeli) kreiram upit sa jednom drugom tabelom ?

Unaprijed hvala ...

Nema potrebe da izbacujes triggere, oni cesto cine veoma vazan deo odrzavanja referencijalnog integriteta baze. Izbacivanje tog aspekta u aplikativni layer je najcesci uzrok sje*anih baza danas.

Potrebno je samo da ih preradis da ne koriste skupe i spore kurzore i umesto toga da koriste standardne CRUD izraze. U tvom slucaju ce verovatno biti neki inner join izmedju implicitne inserted tabele i tih drugih upitnih. Cak i krajem 90ih je upotreba kurzora bila bad taste.

I btw imas dve vrste triggera, FOR/AFTER koje si ti ivdeo koje se pozivaju tek nakon sto su podaci odradjeni, I imas INSTEAD OF koji se pozivaju pre operacije I kojima mozes da utices na podatke pre nego sto udju u bazu.



_{[Ovu poruku je menjao mmix dana 09.06.2016. u 18:31 GMT+1]}

Ima situacija gde su kursori neizbezni. U ranijim verzijama MS SQL servera, do verzije 2008 recimo, bilo je razloga za koriscenje kursora - zbog brzibe izvrsavanje - za upite tipa 'kumulativna suma' i slicno. Za mnoge zadatke DB administratora kursor je jako korisna stavr, upravo zato sto omogucuje looping. Ma primer, collation nije isti u svim tabelama, a desi se da i u okviru jedne tabele imas kolone na rzlicitim kolcijama, sto izaziva probleme u nekim iskazime. Ako dba odluci da to sve sinhronizuje, on ce onda da vrti kursor na sys.Objects tabeli, da dobije imana svih tabela, i onda ce za svaku da proveri i podesi collation. (Nemoj da me pitas kakao se ovo radi, to radi moj dba). Primeti da on ne izvrsava nikakav upit, nego za scaki korak u kursoru uradi neki posao

Za trigere, nisam ni rekao da ih ne koristis. Bez njih se cesto ne moze obezbediti integritet podataka. Nazalost, malo ljudi razmislja 'out of the box', pa se trigeri koriste vise nego sto bi moralo. Posto nije lako napisati pouzdan triger, kasnije se desavaju 'neobjasnjive' stvari. U svakom slucaju, ako triger radi posao, neka ga.

Stara garda je morala da pise trigere, jer nekad nisu postojali ni FOREIGN KEYs - uvedeni su u MS SQL tek u verziji 7, a to je posle 1995, cini mi se. Tada je ama bas svaka tabelka zahtevala triger, da bi se odrzao referntial integrity. Na obe tabele je morao da se dodaje triger. Posto je stara garda iz nuzde pisala trigere, oni su taj zanat izucili veoma dobro. Ali, to je stara garda...

Da se vratimo na konkretan problem:

Sta konkretno treba da uradis za svaki red u'Inserted' tabeli? Mozda mozemo da pomognemo da se to resi bez kursora, u okviru trigera, naravno. Ako ni za sta drugo, barem da dobijes ideju za neki sledeci put.