Activity overview
Latest activity by MikielAgutu
arturcarvalho said:
Jason_H said:
I have both installed, but I didn't start a trial for 2019. I assume once your trial expires it will still work in 2017, but 2019 will not.
I am assuming also... but i would like a confirmation from Redgate...
Yes, you should still be able to use SQL Change Automation Core in Visual Studio 2017 Enterprise once the trial has ended. However keep in mind you will revert to Core edition, and as such not all features are supported. You will need to buy a license to use it in any version of Visual Studio 2019 once the trial has ended. I hope that helps. / comments
arturcarvalho said:
Jason_H said:
I have both installed, but I didn't start a trial for 2019. I assume once your trial expires it will still work in 2017, but 2019 will not.
I am assu...
Have you read the documentation article on Static Data? It's available here: https://documentation.red-gate.com/sca3/developing-databases-using-sql-change-automation/generating-scripts-to-capture-database-changes/data-population/static-data#StaticData-online / comments
Have you read the documentation article on Static Data? It's available here: https://documentation.red-gate.com/sca3/developing-databases-using-sql-change-automation/generating-scripts-to-capture-d...
SQL Change Automation Core is only available in VS 2017 Enterprise edition. All other supported versions of Visual Studio will require a licence when the trial period has ended. So yes - while VS 2019 Enterprise is supported, you must purchase a licence. / comments
SQL Change Automation Core is only available in VS 2017 Enterprise edition. All other supported versions of Visual Studio will require a licence when the trial period has ended. So yes - while VS 2...
Hello Marco Unfortunately SQL Change Automation doesn't support setting SQL Data Compare options from Azure DevOps tasks, or the PowerShell cmdlets themselves. However SQL Data Compare option support is currently on our backlog and work is scheduled to start soon. I can't give a definite time frame for when it will be released however. Thanks / comments
Hello MarcoUnfortunately SQL Change Automation doesn't support setting SQL Data Compare options from Azure DevOps tasks, or the PowerShell cmdlets themselves. However SQL Data Compare option suppor...
Hello Sorry you're having issues with SQL Source Control. I think we'll need some more information to diagnose the problem. Are you able to share a screenshot of the error message you're getting? You said you've 'updated the path for SQL Source Control' - can you check that Git is on your PATH environment variable? If Git isn't present that can cause issues. Can you also confirm that you can perform Git operations on your machine for the repository outside of SQL Source Control - fetch, pull, commit, push, etc. Perhaps there is an underlying Git configuration issue that needs to be addressed. Thanks Mikiel / comments
HelloSorry you're having issues with SQL Source Control.I think we'll need some more information to diagnose the problem. Are you able to share a screenshot of the error message you're getting?You ...
Hello Tom Your question is difficult to answer in some ways, as it's about your team's processes. However I'll try and answer the best I can. To me, the main problem is that you're putting your changes through the CI process too late. As you said: 'Only the master branch is pushed through the Jenkins/Octopus processes.' This means you'll only be able to fully test your changes once they've been merged to master. If you discover the changes are bad, you'll want to undo them, as you said. In my opinion, your master branch should always be in a releasable state. That means any changes that go into master must be fully tested and reviewed before they're merged. Therefore, the simple fix is to ensure that you put all your branches through your Jenkins and Octopus testing process. That way you'll be able to validate if they're ready to be deployed. Only merge a branch into master once you're convinced that branch is in a releasable state. If you're still in a position where you find a change needs to be 'rolled back', the best way is to introduce the fix as another branch, and go through the testing process over again. In this sense you should 'roll forward', instead of trying to undo things. I hope that's helpful. As I said, this is a broad question about Agile delivery, and this is only my opinion on the matter based on your description of the situation. Thanks Mikiel / comments
Hello TomYour question is difficult to answer in some ways, as it's about your team's processes. However I'll try and answer the best I can.To me, the main problem is that you're putting your chang...
Hello Peter Semantic versioning works with the following format: Major.Minor.Patch-PreRelease+Build Note that PreRelease and Build are optional. There are two problems with your naming of the folder. The first is to do with the hyphen in your folder name. The hyphen in the Patch part of the Semantic Version number indicates a pre-release package. So for 1.0.0-2018_Aurora, SQL Change Automation is interpreting the '-2018_Aurora' to be the pre-release part. The second problem is that underscores are not supported in Semantic Version folder names. The supported characters for each part of a Semantic Version folder can be found on the documentation page - which I have just updated for you since it wasn't clear [image]
If you don't want to indicate a pre-release folder, use something like: '1.0.0+2018-Aurora': Major: 1 Minor: 0 Patch: 0 Build: 2018-Aurora If you want the pre-release part, use something like 1.0.0-2018+Aurora': Major: 1 Minor: 0 Patch: 0 PreRelease: 2018 Build: Aurora Alternatively, you might just want to use file path based ordering instead, which is explained on the same documentation page. It's simpler, and might be appropriate for your use case if you just need arbitrary folder names. Thanks / comments
Hello PeterSemantic versioning works with the following format:Major.Minor.Patch-PreRelease+BuildNote that PreRelease and Build are optional.There are two problems with your naming of the folder. T...
We've just released a fix for this issue. You can get it by updating to SQL Source Control v7.0.4 via the Frequent Updates channel. / comments
We've just released a fix for this issue. You can get it by updating to SQL Source Control v7.0.4 via the Frequent Updates channel.
We've managed to reproduce this on our developer machines. As far as we know this issue only occurs on Windows 8 or earlier. We're currently working on a fix, which we're aiming to release this week. For the time being, there are two ways to work around this issue. The first workaround is to install Git, and ensure it is in your PATH environment variable. The second is to temporarily uninstall SQL Prompt. Sorry for any inconvenience this has caused. Mikiel / comments
We've managed to reproduce this on our developer machines. As far as we know this issue only occurs on Windows 8 or earlier. We're currently working on a fix, which we're aiming to release this wee...
It's perfectly fine to edit the Programmable Object scripts manually. As long as your manual changes are valid there shouldn't be any issues with clashes between automatic and manual changes. / comments
It's perfectly fine to edit the Programmable Object scripts manually. As long as your manual changes are valid there shouldn't be any issues with clashes between automatic and manual changes.