Comments
Sort by recent activity
Hi Dan, To clarify— the two products I mention are alternatives to SQL Source Control. SQL Source Control doesn’t have the functionality for managing data in this way. Hope this helps, Kendra / comments
Hi Dan,To clarify— the two products I mention are alternatives to SQL Source Control. SQL Source Control doesn’t have the functionality for managing data in this way.Hope this helps,Kendra
Hi EKelly, I believe that page is the main documentation we have on the offline method for static data. This morning I've just added an example post-deployment script approach for offline static data to the documentation, and linked to it from the main static data page. Does this help? Thanks for this note, and further feedback is very welcome. Cheers, Kendra / comments
Hi EKelly,I believe that page is the main documentation we have on the offline method for static data.This morning I've just added an example post-deployment script approach for offline static data...
Hi @Dylan01p , We recommend using dedicated development databases with SQL Change Automation. If you do need to use a shared development database, we recommend disabling the programmable objects feature. We have some more information documented here: https://documentation.red-gate.com/sca/getting-started/system-requirements/development-database-environment-configuration Hope this helps, Kendra / comments
Hi @Dylan01p ,We recommend using dedicated development databases with SQL Change Automation. If you do need to use a shared development database, we recommend disabling the programmable objects fea...
Hi @Awen , I definitely recommend changing the operation to "Build a SQL Source Control project", if that's what you're actually doing. The build task for SQL Change Automation projects has a check to validate three part names. That can be disabled by making changes in the SQL Change Automation project configuration file -- but you can't do things like that for SQL Source Control as it doesn't even have that file. Hope this helps, Kendra / comments
Hi @Awen ,I definitely recommend changing the operation to "Build a SQL Source Control project", if that's what you're actually doing.The build task for SQL Change Automation projects has a check t...
Hi @sam_alexander, We don't recommend using SQL Source Control to apply changes to QA/Staging/Production environments. If you need to deploy changes manually to these environments, we recommend using SQL Compare to do this. I am curious if you were aware that SQL Compare could help with this, if you don't have it installed, if it seemed like SQL Source Control might do the same thing, or if there was another reason? Thanks in advance, Kendra / comments
Hi @sam_alexander,We don't recommend using SQL Source Control to apply changes to QA/Staging/Production environments.If you need to deploy changes manually to these environments, we recommend using...
Hi, This video and related scripts is on this topic, and I think might help: [image] https://www.youtube.com/watch?v=-rZxLCRrgmI (If you expand the youtube description, the links to example code are in the "show more" bit.) Cheers, Kendra / comments
Hi,This video and related scripts is on this topic, and I think might help: https://www.youtube.com/watch?v=-rZxLCRrgmI(If you expand the youtube description, the links to example code are in the "...
Hi Peter, The first thing I should validate is to make sure that a deployment has happened via SQL Change Automation to the production database in the past. (The drift is since the last deployment -- so there's never a drift report on first deployment.) If this one is the case then it's possible to use SQL Compare to compare your project to the database to identify any key differences before first deployment. If that's not it, then my second guess is that the option "DriftFiltering" on New-DatabaseReleaseArtifact may be playing a role here. The default value for it is ModifiedObjectsOnly. With this default... Under this default behavior, the drift report will not include objects that exist in the target database but do NOT exist in the SQL Change Automation project. One possibility is that if the changes were to new objects that were created in the target which aren't in the project, these wouldn't show up as drift. If this might be the case, you can set -DriftFiltering to "AllObjects" to consider objects added to the target database as drift. Could this be what is going on? Kendra / comments
Hi Peter,The first thing I should validate is to make sure that a deployment has happened via SQL Change Automation to the production database in the past. (The drift is since the last deployment -...
Hi Yan, Apologies that you hit this error. I suspect that the error text bubbling up here may be misleading. The actual issue may be that the SQL Server can't resolve that specific login name. This can often happen if the production environment is in a different domain and than development. There are two things that you might wish to configure when creating the new project, before creating the baseline script: 1. Do you wish to include users (and related logins) in the project? If you do have some segmentation between your domains and the users and related logins which are being scripted aren't valid everywhere, then you probably wish to filter these out. To do this, when creating a project, on the "Options" screen there is an opportunity to specify a filter file that excludes users from the project. This filter file can be created and saved using the SQL Compare GUI.[image] [image] (Screenshot at the bottom of this post) I created a filter file excluding users and popped it in this Gist. More information is here on how to do this in case you'd like to do this yourself, or you want to create a more complex filter that also excludes other things. 2. Do you wish to include any permissions outside of role based permissions in the project? Sometimes permissions have been granted to individual users inside the database on specific objects. Often if you want to filter out users, you also want to change a comparison option so that only role-based permissions are included. To configure this, on the options tab when creating the project, hit the "Edit comparison options" button. This is right below where you configure the filter. Select "Users' permissions and role memberships" (screenshot below). Hope this helps! Kendra ----- [image] [image] / comments
Hi Yan,Apologies that you hit this error. I suspect that the error text bubbling up here may be misleading. The actual issue may be that the SQL Server can't resolve that specific login name. This ...
Hi @Sean_Lively, We don't currently have separate documentation for the YAML task. I wasn't sure how many of our customers were interested in YAML pipelines in Azure DevOps and created that page as a first step, so I'm glad to hear that you found it and are interested in this! I used our graphic CI/CD plugins to help write the YAML there -- I think they would help you configure LocalDB as well. In the video linked at the bottom of that page I show what I did at around this point: [image] https://youtu.be/oXampkDWcC0?t=405 Hope this helps, Kendra / comments
Hi @Sean_Lively,We don't currently have separate documentation for the YAML task. I wasn't sure how many of our customers were interested in YAML pipelines in Azure DevOps and created that page as ...
Hi @bkillen, SQL Source Control isn't designed for this use case-- the files committed to the repo are designed to be purely the object definition rather than a deployment script. Can I ask more about the use case / why this is important for the team? Cheers, Kendra / comments
Hi @bkillen,SQL Source Control isn't designed for this use case-- the files committed to the repo are designed to be purely the object definition rather than a deployment script.Can I ask more abou...