Comments
Sort by recent activity
How's your PowerShell? The step templates don't allow for it but the raw PowerShell does. https://documentation.red-gate.com/dlma2/cmdlet-reference/use-dlmdatabaserelease You'll want to take an input variable containing a list of target DB names and then you'll want to create aalist of DlmDatabaseConnection objects for each target DB. Then you'll use Use-DlmDatabaseRelease to deploy your release to each DlmDatabaseConnection object in the list. Let me know if you have any Qs or want some help. / comments
How's your PowerShell?The step templates don't allow for it but the raw PowerShell does.https://documentation.red-gate.com/dlma2/cmdlet-reference/use-dlmdatabasereleaseYou'll want to take an input ...
Not sure if it makes you feel more comfortable, but the transaction handling is managed by the open source tSQLt layer, not the Redgate layer. So you can fork it and/or contribute your own patches if you prefer. 😉 / comments
Not sure if it makes you feel more comfortable, but the transaction handling is managed by the open source tSQLt layer, not the Redgate layer.So you can fork it and/or contribute your own patches i...
Forgive me if I'm missing the point, but doesn't tSQLt handle this for you out of the box? You shouldn't need to handle transactions within the test sproc itself because the tSQLt.run will roll back the transaction after executing the test anyway. That's why stuff like FakeTable is safe. / comments
Forgive me if I'm missing the point, but doesn't tSQLt handle this for you out of the box?You shouldn't need to handle transactions within the test sproc itself because the tSQLt.run will roll back...
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?
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...