Inability to query underlying table of a schema-bound view

Question

I migrated a database from SQL Server 2008R2 to SQL Server 2019 (both Enterprise Edition) using the backup-restore technique, and a set of post-transfer actions like DBCC UPDATEUSAGE or UPDATE STATISTICS XXX.

At statistics update, I get following error:

Msg 402, Level 16, State 1, Procedure ZZZZ, Line 5 [Batch Start Line 0]
The data types datetime and time are incompatible in the add operator.
Msg 4413, Level 16, State 1, Line 1
Could not use view or function 'ZZZZ' because of binding errors.

I know that the message is quite explicit (the view, which was syntactically correct on 2008R2 is not anymore on 2019). I don't understand why a view defined WITH SCHEMABINDING that is not valid would prevent the update of statistics on an underlying table.

Moreover, I get the same error message when querying the underlying table with a WHERE clause, except if I force a FULLSCAN with following hint:

OPTION(TABLE HINT( $mytable, FORCESCAN ))

I know SQL Server will fire an error in case of DDL change to underlying schema-bound objects, but I don't understand why, if the view is invalid, the underlying objects cannot be used as usual.

I'm sure there is an explanation (like the protection mechanisms for schema-bound views cannot be processed due to the invalidity of the view), but I can't find it for sure in the documentation.

I ran a DBCC CHECKDB without problem. I changed the compat level to 150.

Answer 1

From the documentation:

A query does not have to explicitly reference an indexed view in the FROM clause for the Query Optimizer to use the indexed view. If the query contains references to columns in the base tables that are also present in the indexed view, and the Query Optimizer estimates that using the indexed view provides the lowest cost access mechanism, the Query Optimizer chooses the indexed view, similar to the way it chooses base table indexes when they are not directly referenced in a query.

When you have an invalid indexed view in your database, this Enterprise Edition feature can produce errors when the optimizer considers using the indexed view instead of base table access.

This automatic indexed-view matching feature can be disabled with the EXPAND VIEWS query hint:

EXPAND VIEWS
Specifies the indexed views are expanded. Also specifies the Query Optimizer won't consider any indexed view as a replacement for any query part. A view is expanded when the view definition replaces the view name in the query text.

This query hint virtually disallows direct use of indexed views and indexes on indexed views in the query plan.

When you upgraded your database, a warning was emitted:

Warning: The object "ZZZZ" could not be bound and was ignored during upgrade. Consider reviewing and correcting its definition.

This is easy to miss, and may not even be visible to the user in some scenarios. Still, the lesson is clear: A database with invalid objects may produce unexpected errors.

DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS will also detect the problem.

If you need to run the database on SQL Server 2019, use database compatibility level 100 until you are able to resolve the upgrade issues. This will allow datetimes to be added to times using the addition operator.

Answer 2

Regarding when you query the underlying table, perhaps the optimizer produces a plan that uses the view-index instead of the table?

The execution plan should tell you, or try the EXPAND VIEWS hint.