Comments
Sort by recent activity
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.
Hello Monday Sorry you're having issues using SQL Change Automation. There are a couple of things you could try here. First, instead of importing changes one by one, can you try to manually write a migration script that performs the required operations in the correct order? If that doesn't work, you may need to alter settings that control the order in which SQL Change Automation deploys scripts.
From the documentation page: 'By default deployment order is determined by file path, taking into account both folder path and file name. The file name must always start with a numeric prefix. To adjust the order of deployment, simply change the file's numeric prefix. If two migrations have the same number, then the rest of the filename will be used as the tie-breaker.' You can also configure the order of deployment with Migration Grouping, here. If you're still not having any luck, then Pre & Post-Deployment Scripts might help, as you said. In order to ensure the Pre/Post scripts are only executed in certain environments you'll have to manually write some SQL to check which DB context you're in. I don't recommend adding Pre/Post scripts, deploying the project, and then deleting them. Such an approach would lead to inconsistency if you source control your project. Hope that helps Mikiel / comments
Hello MondaySorry you're having issues using SQL Change Automation.There are a couple of things you could try here. First, instead of importing changes one by one, can you try to manually write a m...
Hello Monday It looks like a script ordering issue to me. Programmable Objects contain logic to drop and re-create themselves upon deployment. In this case, it looks like both objects have already been deployed to the shadow database. When you refresh, the project is deployed to the shadow database once more. When Return_RM_ID is deployed, it attempts to drop and re-create. However because a dependency exists between these two objects, the server blocks the change, which is fair enough. To fix this you'll have to manually amend the Programmable Object file in order to ensure the objects are deployed in the correct order every time. You can see more about how to do this on this documentation post. Thanks. / comments
Hello MondayIt looks like a script ordering issue to me.Programmable Objects contain logic to drop and re-create themselves upon deployment. In this case, it looks like both objects have already be...
Hello Magnus I've looked into this but there doesn't seem to be much more I can do without more information. Can you please create a ticket through the official support system at https://productsupport.red-gate.com. We'll be in a better position to help fix the problem that way. Thanks / comments
Hello MagnusI've looked into this but there doesn't seem to be much more I can do without more information. Can you please create a ticket through the official support system at https://productsupp...
Hello Syagla It seems to me this is what is happening: Training_DB is in the state of branch HOTFIX-001. When you check out MASTER, Training_DB of course doesn't change. When you compare MASTER to Training_DB in SQLCompare, you see the differences between MASTER and HOTFIX-001. This is what you expect because Training_DB is in HOTFIX-001's state. However, when you look at the commit tab in SQL Source Control, you see nothing, despite being on MASTER. This is because SQL Source Control is designed such that all changes you make within SQL Source Control itself are displayed on the commit tab. Changes made outside of SQL Source Control are displayed on the 'Get Latest' tab. Therefore, the changes you're expecting ought to be on the Get Latest tab. In terms of when you'd use one over another: when developing database changes, you'll want to use SQL Source Control's commit and Get Latest tab. This will allow you to see which changes were made by you, and which were made externally (for instance, by another dev on your team). If you want to compare database schemas without reference to where the changes have come from, use SQL Compare. Thanks / comments
Hello SyaglaIt seems to me this is what is happening:Training_DB is in the state of branch HOTFIX-001. When you check out MASTER, Training_DB of course doesn't change.When you compare MASTER to Tra...
Hello Mark SQL Change Automation stores the connection string in the .sqlproj file for your project. This is under the <DefaultConnectionString> property. To set the default connection string:
In Visual Studio, right click your project and select properties
Under the Debug tab, find the 'Target Connection String' box
Click 'Edit...' and select your development database
Then click the 'Set As Default' button
The development database will now be used by default for anyone opening this project from version control. However, there may also be a connection string in the .user file for the solution. This will override the default connection string. In order to ensure everyone is using the default connection string from the .sqlproj file:
In project properties, under the Debug tab, find the 'Target Connection String' box
Click 'Restore Default'
This will ensure the connection string is pulled from the .sqlproj file. You can then edit the target connection string to use different login credentials for the same DB as defined in the default connection string. Thanks / comments
Hello MarkSQL Change Automation stores the connection string in the .sqlproj file for your project. This is under the <DefaultConnectionString> property.To set the default connection string:
In Vis...
Hello Kalo I've managed to reproduce this. I agree that it's somewhat confusing behavior and could be considered a bug. Can you put a ticket into Redgate support? That way we can keep track of this issue. Thanks / comments
Hello KaloI've managed to reproduce this. I agree that it's somewhat confusing behavior and could be considered a bug. Can you put a ticket into Redgate support? That way we can keep track of this ...
Hello Syed Have you checked your machine meets the minimum requirements for each Redgate product you have installed? You can check the requirements on the documentation site. For instance, the system requirements for SQL Prompt are here: https://documentation.red-gate.com/sp9/getting-started/requirements. Also it might be worth checking the system requirements for SSMS. Can I also ask which Redgate tools you have installed? Thanks / comments
Hello SyedHave you checked your machine meets the minimum requirements for each Redgate product you have installed? You can check the requirements on the documentation site. For instance, the syste...