Comments
Sort by recent activity
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?
How much data in your lookup tables? If roughly 1,000 rows or less try the Static Data option. Obviously you will need to ensure all dependencies are also in source control. If an order of magnitude more than that it's harder. You could try migration scripts but they are complicated and it's easy to get yourself into a pickle. / comments
How much data in your lookup tables?If roughly 1,000 rows or less try the Static Data option. Obviously you will need to ensure all dependencies are also in source control.If an order of magnitude ...