I've Composed custom tables with the new Component/Migration approach in V8 which has been awesome and easy to understand. One of the benefits of this method is that you can deploy the code to various development environments and you'll be confident that they will all be in sync.
So my question is: can/should I do the same for relational views?
I could of course just run up SQL Server manager and do it from there but thought I would just ask if anyone has any thoughts or experience on the matter.
You simply just need to run your create view SQL via an Execute command instead.
I'm hosting my site on Azure and was provided with the the following template code that checks to see if the view exists or not
IF object_id(N'<schema_name, sysname, dbo>.<view_name, sysname, Top10Sales>', 'V') IS NOT NULL
DROP VIEW <schema_name, sysname, dbo>.<view_name, sysname, Top10Sales>
GO
CREATE VIEW <schema_name, sysname, dbo>.<view_name, sysname, Top10Sales> AS
<select_statement, , SELECT TOP 10 * FROM Sales.SalesOrderHeader ORDER BY TotalDue DESC>
Creating a database view best practices
Morning all,
I've Composed custom tables with the new Component/Migration approach in V8 which has been awesome and easy to understand. One of the benefits of this method is that you can deploy the code to various development environments and you'll be confident that they will all be in sync.
So my question is: can/should I do the same for relational views?
I could of course just run up SQL Server manager and do it from there but thought I would just ask if anyone has any thoughts or experience on the matter.
TIA
So my research shows that unlike this code to create tables:
You simply just need to run your create view SQL via an Execute command instead.
I'm hosting my site on Azure and was provided with the the following template code that checks to see if the view exists or not
Hope this helps someone in a similar position!
is working on a reply...