New answers tagged view
Yes, there are reasons to not use SELECT * in a view. The most important is that SQL Server caches the metadata of a view's output, and it doesn't magically update if underlying objects change. Here's a quick example to demonstrate: USE tempdb; GO -- simple table with two int columns CREATE TABLE dbo.x(a INT, b INT); GO INSERT dbo.x(a,b) VALUES(1,2); GO -- ...
I would check if you have "Quoted Identifiers" set in the DSN, it looks like its interpreting [Sat. Current] as the column [Current] in the table [Sat]
I posted a related question about views versus queries yesterday. The advice offered was to compare the query plans of linking to a view to linking to linking to the actual tables. The result - the plans were identical - so based on that I don't see a performance gain from using a view. You may be able to gain performance if you're able to use an indexed ...
Views are just stored queries: you don't execute views, but you SELECT data out of them. When you combine multiple views joining them, you are doing nothing different from inlining the view definition in the query. In fact, that's what the optimizer does: it's called view expansion. If your views will never be used in isolation, but always joined together ...
Not automatic, but you could use sp_refreshview, either for one specific view, or even for all views having dependencies on a given object. See sample code here.
Wiki answer generated from comments on the question by miracle173: Here is the error message manual and here is an explanation of key preserved table by Tom Kyte. There are updatable views but there are some restrictions. Related Stack Overflow question: Updating a Join View without getting Non Key-Preserved Error
Top 50 recent answers are included