[MSSQL/TRIGGER] Hoe aan het ID te komen van de row

[PhoneTech]

Ik heb een tabel die bijgewerkt moet worden als er een verandering optreedt in een andere tabel

Nu kan je hiervoor triggers gebruiken.

Ik heb veel voorbeelden gezien, maar geen waar ik het ID van de rij kan achterhalen.

Ik moet namelijk een SP uitvoeren als er iets is verandert in de tabel Nodes. En daar voor heb ik het ID nodig van de rij die de verandering is ondergaan

Dus ik UPDATE rij 15
Hoe kan ik er dan voor zorgen dat mijn trigger ook de waarde 15 meekrijgt, zodat die vervolgens een SP kan aanroepen en die andere tabel bijwerkt met de waarde 15

Hoop dat het een beetje duidelijk is

[Coltrui]

MSSQL kent jammer genoeg ROWID niet.
Ik denk dat je voor die tabel een Identifier column moet aanmaken...
Zoek in je Books Online eens op "IDENTITY" en normaal zal het eerste item je verder helpen.

[EfBe]

SP 1 update iets in tabel ABC. Tabel ABC heeft trigger T. In T kun je nu de rij achterhalen die is geupdate door in T te refereren naar 'inserted', een speciale table die alleen beschikbaar is in triggers.

Zie books online omtrent 'triggers', 'inserted' en bv ook 'deleted'.

[PhoneTech]

EfBe schreef op 11 March 2003 @ 09:05:
SP 1 update iets in tabel ABC. Tabel ABC heeft trigger T. In T kun je nu de rij achterhalen die is geupdate door in T te refereren naar 'inserted', een speciale table die alleen beschikbaar is in triggers.

Zie books online omtrent 'triggers', 'inserted' en bv ook 'deleted'.

Precies EfBE, had het niet beter kunnen omschrijven...

inserted en deleted zijn idd aparte tables die ik kan aanspreken, maar was er zelf niet op gekomen!

[EfBe]

Het is ook een beetje krom om 'inserted' te gebruiken voor updated rows. Je zou 'updated' verwachten. Maar goed, zolang er debieliteiten als RAISERROR (let op de enkele E) in de syntax van T-SQL zitten, kijk ik nergens meer van op

[Annie]

EfBe schreef op 11 maart 2003 @ 09:49:
Het is ook een beetje krom om 'inserted' te gebruiken voor updated rows. Je zou 'updated' verwachten. Maar goed, zolang er debieliteiten als RAISERROR (let op de enkele E) in de syntax van T-SQL zitten, kijk ik nergens meer van op

Deze constructie is helemaal niet zo vreemd als je het zo bekijkt dat een update bestaat uit een delete (de oude waarde wordt verwijderd) en een insert (de nieuwe waarde wordt ingevoerd). De row die ge-update is vindt je dus terug in de deleted table en de nieuwe waarde vindt je dus terug in de inserted table.

De RAISERROR is natuurlijk gewoon uit lees-/schrijfbaarheidsoverwegingen gedaan (of je het inderdaad beter vind is een ander verhaal ). Wat ik kwalijker vind is dat het niet consequent overal is doorgevoerd.
Maar ach, dat houdt het ook weer een beetje spannend

[EfBe]

Annie schreef op 11 March 2003 @ 10:30:
Deze constructie is helemaal niet zo vreemd als je het zo bekijkt dat een update bestaat uit een delete (de oude waarde wordt verwijderd) en een insert (de nieuwe waarde wordt ingevoerd). De row die ge-update is vindt je dus terug in de deleted table en de nieuwe waarde vindt je dus terug in de inserted table.

ok, in dat geval is het logisch. Alleen is het weer niet logisch als je bekijkt dat inserted rows ook in de inserted table terecht komen. Je gebruikt dus op 1 plek (de trigger) een table met dezelfde naam voor semantisch gezien 2 verschillende dingen (de opsplitsing van de acties daargelaten, wat 'under the hood' gebeurt is niet het probleem van de developer). Beetje verwarrend imho.

De RAISERROR is natuurlijk gewoon uit lees-/schrijfbaarheidsoverwegingen gedaan (of je het inderdaad beter vind is een ander verhaal ). Wat ik kwalijker vind is dat het niet consequent overal is doorgevoerd.
Maar ach, dat houdt het ook weer een beetje spannend

heh, nou ik zet mijn geld echt op een typo.