Expressions and Computed Columns in INSTEAD OF Triggers
The select list of a view can have expressions other than simple expressions made up of only a column name. INSTEAD OF triggers on these views must have logic to correctly determine from the values specified on INSERT and UPDATE what values must be set into columns in the base table. Examples of such expressions include the following:
View expressions that do not map to any column in any table, such as a constant or some types of functions.
View expressions that map to multiple columns, such as complex expressions formed by concatenating strings from two or more columns.
View expressions that transform the value of a single base table column, such as referencing a column in a function.
These issues also apply to view columns that are simple expressions referencing a computed column in a base table. The expression defining the computed column can have the same form as a more complex expression in the view select list.
Views can contain expressions in their select list that do not map to any base table columns, for example:
CREATE VIEW dbo.ExpressionView AS SELECT BusinessEntityID, JobTitle, GETDATE() AS TodaysDate FROM AdventureWorks2008R2.HumanResources.Employee;
Although the TodaysDate column does not map to any table column, SQL Server must build a TodaysDate column in the inserted table it passes to an INSTEAD OF trigger defined on ExpressionView. However, the inserted.TodaysDate column is nullable; therefore, an INSERT statement that is referencing ExpressionView does not have to supply a value for this column. Because the expression does not map to a column in a table, the trigger can ignore any value supplied by the INSERT in this column.
The same approach should be applied to simple view expressions that reference computed columns in base tables that also build a result that is not dependent on other columns, for example:
CREATE TABLE dbo.ComputedExample ( PrimaryKey int PRIMARY KEY, ComputedCol AS SUSER_NAME() );
Some complex expressions map to multiple columns, for example:
CREATE TABLE dbo.SampleTable ( PriKey int, FirstName nvarchar(20), LastName nvarchar(30) ); GO CREATE VIEW dbo.ConcatView AS SELECT PriKey, FirstName + ' ' + LastName AS CombinedName FROM SampleTable;
The expression CombinedName in ConcatView has the concatenated values of the FirstName and LastName values. If an INSTEAD OF INSERT trigger is defined on ConcatView, you must have a convention for how INSERT statements supply a value for the CombinedName column that lets the trigger determine which part of the string should be put in the FirstName column and which part should be put in the LastName column. If you choose a convention of having INSERT statements specify the value of CombinedName by using the convention 'first_name;last_name', the following trigger can successfully process an INSERT:
CREATE TRIGGER InsteadSample on dbo.ConcatView INSTEAD OF INSERT AS BEGIN INSERT INTO dbo.SampleTable SELECT PriKey, -- Pull out the first name string. SUBSTRING( CombinedName, 1, (CHARINDEX(';', CombinedName) - 1) ), -- Pull out the last name string. SUBSTRING( CombinedName, (CHARINDEX(';', CombinedName) + 1), DATALENGTH(CombinedName) - (CHARINDEX(';', CombinedName) + 1) ) FROM inserted END;
Similar logic is required to process view columns that are simple expressions referring to computed columns that have complex expressions.
Some view expressions can transform the value of a base table column, for example, by performing a mathematical operation or using the column as a parameter to a function. In this case, the logic in the INSTEAD OF INSERT trigger can take two approaches:
The convention can be that all INSERT statements supply the raw value to place in the base table, and the trigger logic moves the value from the inserted table to the base table.
The convention can be that all INSERT statements supply the value they expect to have returned by a SELECT on the view, in which case the logic in the trigger must reverse the operation. For example:
CREATE TABLE dbo.BaseTable ( PrimaryKey int PRIMARY KEY, ColumnB int, ColumnC decimal(19,3) ); CREATE VIEW dbo.SquareView AS SELECT PrimaryKey, ColumnB, -- Square the value of ColumnC SQUARE(ColumnC) AS SquareC FROM BaseTable; CREATE TRIGGER SquareTrigger ON dbo.SquareView INSTEAD OF INSERT AS BEGIN INSERT INTO dbo.BaseTable SELECT PrimaryKey, ColumnB, -- Perform logical inverse of function in view. SQRT(SquareC) FROM inserted END;
For some expressions, such as complex expressions using mathematical operations such as addition and subtraction, users may not be able to supply a value that the trigger can use to unambiguously build values for the destination base table columns. For example, if a view select list contains the expression IntColA + IntColB AS AddedColumns, what does a value of 10 in inserted.AddedColumns mean? Is 10 the result of 3 + 7, 2 + 8, or 5 + 5? There is no way to tell from the value of inserted.AddedColumns alone what values should be placed in IntColA and IntColB.
In these cases, the trigger can be coded to use alternative sources of information to determine the values to set in the base table columns. For views that have INSTEAD OF triggers, the view select list must contain enough information to build values for all nonnull columns in the base tables modified by the trigger. Not all data must come directly from the inserted table. In some cases, the values in the inserted table can be key values that the trigger uses to retrieve the relevant data from other base tables.