If you’re getting an error that reads “Create View or Function failed because no column name was specified…” in SQL Server, perhaps you’re using a function or an arithmetic expression in the SELECT list, but you haven’t provided a name for the column.
As the error message alludes to, you need to provide a column name when doing stuff like that.
Continue readingIf you’re getting an error that reads “Cannot create index on view “demo.dbo.vDistinctPrice” because it contains the DISTINCT keyword…” etc etc in SQL Server, it appears that you’re trying to create an index on a view that contains the DISTINCT keyword.
As the error message alludes to, this is not allowed.
Continue readingIndexed views can significantly enhance the performance of complex queries in SQL Server. However, they come with several prerequisites and considerations that need to be carefully understood before implementation.
In this article, I provide an overview of indexed views, discussing their utility, prerequisites, and best practices, along with performance considerations and a simple example.
Continue readingIf you’re getting an error that reads something like “Cannot create index on view ‘demo.dbo.v1’. It contains text, ntext, image, FILESTREAM or xml columns” in SQL Server, it appears that you’re trying to create an index on a view that uses an invalid data type.
Not all data types are supported when indexing views.
Continue readingBelow are four ways to list out the views in a MariaDB database using SQL or the command line.
Continue readingIn PostgreSQL, we can use the information_schema.views view to return all views in a database.
We can also use the \dv psql command to do the same thing.
Here are four options for showing all views within an SQLite database.
Continue readingYou can use the following views to return a list of views in Oracle Database.
Continue readingBelow are four ways to list out the views in a MySQL database using SQL or the command line.
Continue readingOne of the great things about database views, is that they allow you to run complex queries without needing to know the underlying database schema.
Yes, it’s true that you need to know the underlying schema when you create the view, but you only need to do that once. Once you’ve created it, you can query that view all day long without needing to remember all the table and column names, etc.
Views typically combine data from multiple tables into a single, virtual table, which makes it kind of like a “black box”. As long as it works as designed, you don’t need to concern yourself with the hidden details.
But what if you do want to check a view for its underlying tables and columns?
Continue reading