Question

I’m having issues creating an index on a view that uses a custom CLR aggregate function.

I don’t see any way to flag the aggregate function as deterministic or with schemabinding.

I’m creating my function like so:

CREATE ASSEMBLY StringUtil
AUTHORIZATION dbo
FROM 'C:\StringUtil.dll'
WITH PERMISSION_SET = UNSAFE
GO

CREATE AGGREGATE SUMSTRING (@input nvarchar(200)) 
RETURNS nvarchar(max) WITH SCHEMABINDING 
EXTERNAL NAME StringUtil.Concatenate

And my view is defined as:

CREATE VIEW RolledValues WITH SCHEMABINDING
AS
SELECT ID, SumString(ValueText) as Value FROM [dbo].[IDValue]
GROUP BY ID

The issue occurs when I try to create an index on that view:

CREATE UNIQUE CLUSTERED INDEX IDX_RollValues_ID_VALUE on RolledValues (ID)

Error:  Cannot create index on view "dbo.RolledValues" because it uses aggregate
"dbo.SumString". Consider eliminating the aggregate, not indexing the view, or 
using alternate aggregates.

So is it possible to use a custom aggregate function in an indexed view? I cannot find any documentation on this…

Answer 1

The page on Creating Indexed Views lists a number of restrictions:

The SELECT statement in the view cannot contain the following Transact-SQL syntax elements:

…

A CLR user-defined aggregate function.

There’s not even provision, at the current time, to describe a CLR aggregate as Deterministic (at least, if the API was going to be consistent). The SqlFunctionAttribute has an IsDeterministic property. No such property exists in SqlUserDefinedAggregateAttribute

---

It does help to reason about things if you consider why so many restrictions exist on indexed views.

The ones on aggregates have a pretty simple explanation – you’re only allowed to use aggregates (such as SUM and COUNT_BIG) that have the property that SQL Server will be able to adjust the values, or add or remove rows from the index, based purely on the subset of rows that are the subject of the current transaction.

E.g. if the view has a row with ID=19, COUNT_BIG=5, and SUM=96, and a transaction deletes 3 rows with ID 19, whose SUM adds to 43, then it can update that row of the view to be COUNT_BIG=2 and SUM=53. Alternatively, if the transaction had deleted 5 rows with ID=19, it would have caused the row to be removed.

Note that in either case, we don’t have to examine any other rows of the table to determine if they have ID=19.

So how could SQL Server hope to achieve similar functionality with a user defined aggregate? The current interface for user defined aggregates doesn’t have the sort of support you’d need (it would need to have a trigger like interface also).