Settings and activity
3 results found
-
8 votes
An error occurred while saving the comment 
Andrew Whitcomb
supported this idea
·
-
9 votes
An error occurred while saving the comment Andrew Whitcomb
commented
We also ran into this issue when upgrading to Source Control 5, and we implemented our own extended property to mange this. When our CI environment builds a database installer, it updates the custom extended property to the revision number that we are building. We also set a second extended property that contains the version number (major.minor.build.revision format) for the database.
If I want to see the value of the extended property for all the databases in one of our servers, I just run a query that looks at sys.databases in the master database, and then calls fn_listextendedproperty on each database to read the extended property. I end up with a result set listing each database and the revision level it is currently at. You could then use these results to execute SQLCompare through the command line to bring each database up to the desired revision level.
-
254 votes
Hi all. Thank you for your votes and feedback on this issue over the years. Here is our current guidance for this suggestion:
Post-deployment scripts give you flexibility for static data
With SQL Source Control, you can now use a post-deployment script to “dynamically” deploy static data based on a factor such as @@SERVERNAME or other query-able conditions.
SQL Source Control introduced pre- and post- scripts in v6.3.
An example post-deployment script which shows how to control deployment of static data by environment is here: https://documentation.red-gate.com/soc7/common-tasks/working-with-pre-post-deployment-scripts/static-data
If you make heavy use of Static Data, we have stronger support for this in SQL Change Automation.
SQL Change Automation:
- Supports column filtered static data tables in the SCA plugin in SSMS
Supports multiple post-deployment scripts, in case there is a preference to manage static data tables in dedicated post-deployment scripts - Allows approaches like bulk loading larger static data tables by supporting SQLCMD…
An error occurred while saving the comment Andrew Whitcomb
commented
The concept makes sense to me, but I think is unappropriate for "Source Control". If you were talking about applications, you are effectively saying you are storing your customer's configuration files / preferences in your source control system. My company is doing SaaS hosting, so we'd prefer to see this in some sort of deployment tool rather than in our Source Control.
- Supports column filtered static data tables in the SCA plugin in SSMS
When you check in files to source control, you don't get to specify what version it uses - the source control system applies this number automatically. Most systems use a revision number that applies to everything in that source control root. So, this really doesn't have anything to do with RedGate Source Control. It has more to do with what source control system you use, and how you have it setup.
This was a learning curve for us because we were used to VSS where each project used it's own revision level, but as we migrated items to TFS, everything switched to the root revision level.