Comments
Sort by recent activity
Glad you figured it out. That sounds like a good plan! / comments
Glad you figured it out. That sounds like a good plan!
Yes - that could well be the issue. As a rule of thumb, if the static data table is over 1,000 rows expect an impact on performance. If the table is an order of magnitude bigger consider using a different strategy. However, if this is the issue there is a trick you can use to give you a significant performance boost: Setup tab > under Options just for this database, disable checks for changes to static data. Now the source code will still include the static data, but you have turned off the comparison by default. Now that static data will stop slowing down your refresh on the commit/get latest tab. Crucially, however, it will no longer notify you if the data changes. You will need to head back to the settings tab and flip it back on if/when you want to commit or pull down data updates. Hence, this fix will boost performance, but will mean your team need to communicate any static data updates with each other and manually push them up/pull them down. Also, this setting is individual to each dev machine. Hence, if using the dedicated model, each developer will individually need to flip the check back on, pull down the data, and flip the check back off again to get their performance back. / comments
Yes - that could well be the issue. As a rule of thumb, if the static data table is over 1,000 rows expect an impact on performance. If the table is an order of magnitude bigger consider using a di...
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?
I'm not sure, but I did notice the other day that creating hyperlinks when writing a reply is super annoying. If I copy/paste a URL from chrome both the copy from chrome and also the add hyperlink feature in the forum will add an http, resulting in double http. Spotting the mistake is difficult and correcting it is a pain too. (While I'm on the subject - I also hate the automatic smily faces that you only see after posting your comment. Several times it has unexpectedly broken my intended use of actual punctuation.) / comments
I'm not sure, but I did notice the other day that creating hyperlinks when writing a reply is super annoying.If I copy/paste a URL from chrome both the copy from chrome and also the add hyperlink f...
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...