We have an Instead-Of-Insert trigger on a view which copies all values from the INSERTED virtual-table to another table.
One of the fields in the list is non-nullable for the target table, and has a default value specified.
What we are experiencing, is, some application code is sending an insert command, and not specifying the non-nullable field - which (if the insert were executed against the actual table) would normally result in SQL Server inserting the column's default value. But, the trigger is explicit for all fields, so the trigger tries to insert null for that field... resulting in an error.
What I DONT want, is code like this...
INSERT INTO XXXX (col1, col2, col3)
SELECT
ISNULL(col1, 0), ISNULL(COL2, 0), ISNULL(COL3, 0)
FROM INSERTED
I don't want the trigger to need to know what the actual default values of each column should be (from a maintainability perspective)...
Does anyone have a better solution?
Thanks
sys.default_constraints- you'd need to join to this table repeatedly, once for each column whose default you want to obtain, and you'd have to rely on the actual values being used for the default being easily convertible to the actual data type required. The complexity and brittleness of this solution makes embedding the column defaults in the trigger look (to me) like the better option. - Damien_The_Unbeliever