Database version management and figuring out which scripts need to be run when deploying the latest version of your web app
When you are maintaining multiple web apps across environments it can be difficult to keep track of which scripts need to be run to upgrade the database when it comes time to deploy. If you’re maintaining different versions of web apps across environments when the versions can sometimes be significantly out of sync, the difficulty of determining which update scripts need to be run on deployment can explode.
While there are a ton of approaches to keeping your database under version control, if you want something simple and effective that you can implement with minimal time and effort, consider a DatabaseVersionHistory table in your database.
A database version history table will allow you to see at a glance the state the database is in and by comparing it with the update scripts in source control, you will quickly be able to determine which update scripts need to be run.
If you are connecting to a SQL server with the SQL profiler and none of your templates are showing up, compare the versions of the SQL profiler you are running and the version of SQL server that you’re connecting to; there is likely a version mismatch.
If this is the case, what’s likely happening here is that you’re connecting to a SQL 10.50 instance with a SQL 10.0 profiler and the profile templates for 10.50 aren’t present.