Comments
Sort by recent activity
Any reason Start > SQL Source Control > R-Click "uninstall" won't work? [image] Also, SQL Source Control is really good. Why don't you need it? / comments
Any reason Start > SQL Source Control > R-Click "uninstall" won't work?Also, SQL Source Control is really good. Why don't you need it?
You must have upgraded from a super old version of SQL Source Control. Migration scripts are no longer kept in a different directory. They also work differently. Check out this documentation page: https://documentation.red-gate.com/soc6/common-tasks/working-with-migration-scripts/upgrading-from-old-versions-of-migration-scripts (And then you should probably read about how the new version of migration scripts works: https://documentation.red-gate.com/soc6/common-tasks/working-with-migration-scripts/how-migration-scripts-work) / comments
You must have upgraded from a super old version of SQL Source Control. Migration scripts are no longer kept in a different directory. They also work differently.Check out this documentation page:ht...
Default SQL Compare options are documented here: https://documentation.red-gate.com/dlma2/using-sql-compare-options-with-dlm-automation-cmdlets/default-sql-compare-options-used-by-dlm-automation-cmdlets Documentation for deselecting one of the default options is here: https://documentation.red-gate.com/dlma2/using-sql-compare-options-with-dlm-automation-cmdlets (Basically, pre-fix the option with -) / comments
Default SQL Compare options are documented here:https://documentation.red-gate.com/dlma2/using-sql-compare-options-with-dlm-automation-cmdlets/default-sql-compare-options-used-by-dlm-automation-cmd...
I would change your process. It's inefficient for various reasons. For clarification, I'm assuming when you say ''migration script" you are not referring to Redgate SQL Source Control "migration scripts" feature. It's an overloaded term so I just want to be sure that's not what you meant. If it was we should talk about that. First you need to decide if you want to use a migrations or a model based source control strategy. Currently you have a form of hybrid which is highly inefficient. If you really want a hybrid approach there are better ways to do it. More info: ore [image] /workingwithdevs.com/delivering-databases-migrations-vs-state/ If you would like to go with model, you should look at the DLM Automation release objects and you shouldsprobably create fresh DlmDatabaseRelease object against prod or staging for each build. (Other strategies may also work but this would be a good start.) Then you will just get a single upgrade script and a handy diff report for the DBA. But you may or may not wish to consider leaving the release creation to nearer the deployment day. If you would like to go with migrations, use ReadyRoll instead of SQL Source Control. (Also, I highly recommend moving to the dedicated model. It'll make your life much much easier: http://workingwithdevs.com/shared-vs-dedicated/) There are a lot of concepts here so if you'd like to talk through it feel free to contact me for a free 30 mins Skype chat. You can contact me either through any of the links in my signature or through the enquiries address on our website: www.dlmconsultants.com (Ask for Alex.) / comments
I would change your process. It's inefficient for various reasons.For clarification, I'm assuming when you say ''migration script" you are not referring to Redgate SQL Source Control "migration scr...
Ruddy smily faces changing the meaning of my reply... [image] / comments
Ruddy smily faces changing the meaning of my reply...
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...