views:

35

answers:

2

I'm trying to add a simple trigger to a table- the 1st issue i came accross was that this table has text columns - so the for delete, insert, update triggers aren't going to float. 'instead of' does though.

I am now up against the fact that the table has cascades set on it. Do you know if there's a way to get around that little gem or am I basically fubared?

+1  A: 

Create a new table, which everyone uses instead of the cascading table. Then build your "instead of" trigger onto the new table, and update the old table within the trigger.

The old table will cascade as normal, but your new table doesn't have any cascades.

UPDATE:

You could try adding a view rather that creating another table. You could even exclude those text columns from the view.

Sohnee
I see the words - but they look like gilberts?! ;)
cvista
I should have cited the reference, but there isn't a URI for Gilbert's head :)
Sohnee
gilbert://brain.biz
cvista
For the view, you can even index it if you schemabind it: http://www.mssqltips.com/tip.asp?tip=1610
Nelson
couldnt go down the view route in the end as the table had replication and other show stoppers. in the end i created a snapshot table, when the deltas are required an sp can be called from the BCP command which compares the live table to the snapshot, generates the diff, reloads the snapshot ready for next time - not ideal but does the job
cvista
A: 

I don't know what version of SQL Server you are on but text columns are deprecated - they will NOT be in the next version of SQL Server. If you are on any version higher than 2000, I would suggest you make it an immediate prioroity to fix those by making them nvarchar(max) (You will also need to change code that uses CONTAINS, WRITETEXT and other text type code).

That said, I always got the value of text column in a trigger by joining inserted to the actual table itself on the primary key.

I'm not sure what to do about your cascade question as we do not allow cascade delete or update for performance reasons. As far as I can tell triggers will still fire (and should definitely be written to handle multiple record inserts, updates or deletes, but I strongly feel all triggers should be written this way). What problem exactly are you running into with the cascades?

HLGEM