Comments
Sort by recent activity
Hi Bruce, Sorry to differ from Bob, but I wouldn't recommend using the 'migration script' feature of Redgate SQL Source Control in the way that Bob has suggested. The 'migration script' feature is intended only for data migration and table refactors that SQL Compare cannot handle using generated code. Use it like pin-hole surgery to help SQL Compare only when it needs it, rather than for every change. Using a Redgate SQL Source Control 'migration script' for every change will cause significant performance issues with the Redgate tools and may lead you into complicated and difficult to troubleshoot issues. If you would like a migration script for every change that's perfectly reasonable. However, you should use a migrations first tool (such as ReadyRoll) rather than a model first tool (SQL Source Control). For more info on the Model vs Migration decision: http://dlmconsultants.com/model-vs-mig/ http://workingwithdevs.com/delivering-databases-migrations-vs-state/ If you would like to stick with a model based approach I recommend letting DLM Automation generate your deployment scrips within an automated build/release pipeline. I would also strongly encourage you to move to dedicated databases rather than a shared dev database. More info here: http://workingwithdevs.com/shared-vs-dedicated/ Those points aside, I would agree with Bob in pretty much every other aspect. :-) Since this is a massive topic, if you would like to schedule a free 30 minute skype chat etc let me know. You can contact me using the details in my signature or by using the email address on http://dlmconsultants.com/. (Ask for Alex.) / comments
Hi Bruce,Sorry to differ from Bob, but I wouldn't recommend using the 'migration script' feature of Redgate SQL Source Control in the way that Bob has suggested.The 'migration script' feature is in...
Firstly, I'd try to avoid that architecture. It doesn't scale well. However, if you are stuck with it, I would include all the sprocs in DEV/source control and I'd ensure there was some sort of naming convention that allows you to filter them all out at deployment time. Hence, all the standard tenants get the basic image without any custom sprocs. Then I would add a post deploy script that does an (if exists) drop and redeploy on the specific sprocs depending on the tenant. If you have a sensible naming convention you might be able to make that post deploy relatively straightforward. We had a similar problem with one of our customers. You can watch/read about it here: http://dlmconsultants.com/greentube/ / comments
Firstly, I'd try to avoid that architecture. It doesn't scale well.However, if you are stuck with it, I would include all the sprocs in DEV/source control and I'd ensure there was some sort of nami...
They had 6 production data centres that were *mostly* in sync. We developed a solution to include all the differences in source control but in the end it was very complicated and easier for them to standardise to a single golden version. / comments
They had 6 production data centres that were *mostly* in sync. We developed a solution to include all the differences in source control but in the end it was very complicated and easier for them to...
Yes. / comments
Yes.
Docs at: https://documentation.red-gate.com/sc13/using-the-command-line/switches-used-in-the-command-line Something like this should do the trick: sqlcompare /Scripts1:"C:\whatever\path\you\type\in\SQLSourceControl\Setup\tab" /Scripts2:"C:\whatever\other\path\you\type\in\SQLSourceControl\Setup\tab" /scriptFile:"C:\Scripts Folder\WidgetSyncScript.sql" What's the use case? You might find DLM Automation/PowerShell is a better option for you. / comments
Docs at:https://documentation.red-gate.com/sc13/using-the-command-line/switches-used-in-the-command-lineSomething like this should do the trick:sqlcompare /Scripts1:"C:\whatever\path\you\type\in\SQ...
Redgate have provided this step by step guide - but it uses SVN instead of Git: https://documentation.red-gate.com/dlma2/tutorials/walkthrough-set-up-continuous-integration-and-release-management Here is a shorter blog post explaining the set up with Git: https://www.red-gate.com/simple-talk/blogs/sql-source-control-and-git-2/ If you want a higher level real world case study I delivered this talk with the folks at Greentube last year. It's not exactly a step by step walk-through but it is a real world case study that documented a bunch of the benefits and challenges associated with setting it all up: http://dlmconsultants.com/greentube/ / comments
Redgate have provided this step by step guide - but it uses SVN instead of Git:https://documentation.red-gate.com/dlma2/tutorials/walkthrough-set-up-continuous-integration-and-release-managementHer...
Great news. If you had any sensitive data in prod you might want to consider using SQL Data Masker or something similar to ensure this data is not being used in dev. (Especially if you have any PII data regarding EU citizens. #GDPR) https://www.red-gate.com/products/dba/data-masker/index (Of course, if you do have such data in dev I strongly recommend that you don't admit that fact in a public forum.) / comments
Great news.If you had any sensitive data in prod you might want to consider using SQL Data Masker or something similar to ensure this data is not being used in dev. (Especially if you have any PII ...
In theory you should be using source control in dev, not production. You should be deploying to production from source control, not retrospectively commiting changes to source control after they have been applied in prod. If what you are looking for is an audit log of changes you should look at DLM Dashboard instead.
With regards moving your source control to the pre-prod DB, the simple answer is to use something like SQL Compare to sync yp the schemas and then unlink prod and link pre-prod.
But as I mentioned, you really you should be doing that all the way down to dev and then using source code as the source of truth for all deployments to your test/pre-prod/prod dbs. / comments
In theory you should be using source control in dev, not production. You should be deploying to production from source control, not retrospectively commiting changes to source control after they ha...
You shouldn't need to write a migration scripts. DLM Automation will do it for you.
Migration scripts are for data that are not included in your static data tables. For example if you decide to split full name into fName and lName. / comments
You shouldn't need to write a migration scripts. DLM Automation will do it for you.
Migration scripts are for data that are not included in your static data tables. For example if you decide to spl...
Maybe this is a silly question, but have you made any changes or are the source package and target database already in an identical state? / comments
Maybe this is a silly question, but have you made any changes or are the source package and target database already in an identical state?