Comments
Sort by recent activity
Hiya, I think there may have been some confusion in the previous answer. We do support connecting to Git and or TFVC repos -- these are the types of repos hosted by Azure DevOps Server as well as Azure DevOps Services. The "Express" edition of Azure DevOps Server doesn't seem to change the behavior of these repos, so it should be supported like any other Git or TFVC repo. Like Microsoft, we do recommend Git repos for new projects, more info is here: https://www.red-gate.com/blog/why-to-use-git-instead-of-tfs-tfvc Cheers, Kendra / comments
Hiya,I think there may have been some confusion in the previous answer. We do support connecting to Git and or TFVC repos -- these are the types of repos hosted by Azure DevOps Server as well as Az...
Hi Albert, Quick check-- are you saying that you have already created a pre-deployment script which configures the filegroup automatically for a new database? I'm not completely sure where you are saying that the filegroup 'ftg_ft' exists. Some more details on how this works:
The error message you shared (thanks for including that!) mentions Catalog=dlmautomation_14501d96-5ec6-4784-952c-70b6b73d496e;
That means that you have the build configured without a hardcoded database name. During the build process, it creates a database on the instance where you have the build specified, uses it for the build, and then cleans up after.
That new database will be created based on the model database of the SQL Server instance where you are building -- so if model only has a primary filegroup, then the build database will only have a primary filegroup
If you would like this dynamically created database (and other databases you deploy to later in your pipeline) to have additional filegroups, you can check for existence of the filegroup and configure it in a pre-deployment script -- this page has sample code.
Hope this helps! Kendra / comments
Hi Albert,Quick check-- are you saying that you have already created a pre-deployment script which configures the filegroup automatically for a new database? I'm not completely sure where you are s...
Hi Joshua, SCA does contain logic to build the views after the dependencies. The only time I have run into this issue with building is when the dependent objects are not present in the exact database you are building -- either because they were dropped or because they are in a different database that isn't present on the build server. Could that be the case here? The error log should mention the specific object names to track down. There are ways to handle it, just depends on exactly where the dependent objects are. Kendra / comments
Hi Joshua,SCA does contain logic to build the views after the dependencies. The only time I have run into this issue with building is when the dependent objects are not present in the exact databas...
The videos are presently hosted on YouTube. Could something be blocking you from viewing that in your location? I just spot-checked a couple of the SCA courses and the videos look OK to me, so I suspect it's either a YouTube issue with your connection, or I'm not looking at the same course/lesson combo that you are. / comments
The videos are presently hosted on YouTube. Could something be blocking you from viewing that in your location?I just spot-checked a couple of the SCA courses and the videos look OK to me, so I sus...
Hi Peter, These options aren't stored in the metadata in SQL Server after the index is created -- EXCEPT for fillfactor. For fillfactor, you can change the 'SyncOptionIgnoreFillFactor' setting in the .sqlproj file. Instructions on that are here, and the note on that setting indicates it also will mean that any index padding settings you use will be scripted as well. For the options which apply to the index creation process only and aren't persisted in the metadata, like ONLINE and SORT_IN_TEMPDB, there is a User Voice page on this here which has an explanation of some of the considerations around why we don't have this presently. I personally think it's worth expanding the options list in Compare to have global enable/disable for each of these as it would be much nicer for you to be able to configure that preference rather than having to use snippets. Please do consider adding a note to that User Voice forum if you have the time. I'll also internally copy this thread over to the SQL Compare team as well, so they are aware. Kendra / comments
Hi Peter,These options aren't stored in the metadata in SQL Server after the index is created -- EXCEPT for fillfactor. For fillfactor, you can change the 'SyncOptionIgnoreFillFactor' setting in th...
Hello, You can control this behavior by setting the "SyncOptionIgnoreCollations" to false in your .sqlproj file. Notes on how to make this change and example syntax are in the article, "Configuring comparison & script generation options." Hope this helps! Kendra / comments
Hello,You can control this behavior by setting the "SyncOptionIgnoreCollations" to false in your .sqlproj file. Notes on how to make this change and example syntax are in the article, "Configuring ...
Note: striking this for other readers, as I did an incorrect step in my repro Thanks for clarifying! I did some testing. I believe the bug is with the Release Artifact -- in my repro it contains that exact text as well. However, it is misleading you-- the post deployment script is still being run in my testing. For my repro, I used this script and found that the job would be recreated even when I made no state change in the database itself, and the release artifact displayed that message. The team has created a Jira bug to prioritize this and make sure it doesn't get forgotten. But for the time being I think the actual deployment functionality is what you want. Kendra / comments
Note: striking this for other readers, as I did an incorrect step in my reproThanks for clarifying!I did some testing. I believe the bug is with the Release Artifact -- in my repro it contains that...
Note for readers who come by later: this was not correct, see later in the thread please! ps: just confirmed from chat with the team that this is considered a bug, the desired behavior is to include the pre- and post- sql code into the Release Artifact for display (as well as executing it, which is occurring). The Jira item will help make sure we track that. / comments
Note for readers who come by later: this was not correct, see later in the thread please!ps: just confirmed from chat with the team that this is considered a bug, the desired behavior is to include...
Sorry about this, Tom -- the team suggested I wasn't seeing the right behavior, and I ran through it again on the plane today. I made an error in my repro setup, and it was the *build* creating the the job that I saw, not the deployment. You're correct that it's not running it. Would committing a small state change as a workaround make this functional for you in the meantime? You could do a a change as small as adding / editing an extended property in the database itself where you want the post-deployment script to run. Sorry about the misinformation! / comments
Sorry about this, Tom -- the team suggested I wasn't seeing the right behavior, and I ran through it again on the plane today. I made an error in my repro setup, and it was the *build* creating the...
From a chat in the team Slack channel, I believe that it's intended that you *should* be able to deploy pre / post scripts without a schema change, so it could be a bug. I'd like to set up a repro. I'm guessing that you're using SQL Source Control / State Based + SQL Change Automation? (Just checking for the repro setup as migrations approach also has pre and post scripts). / comments
From a chat in the team Slack channel, I believe that it's intended that you *should* be able to deploy pre / post scripts without a schema change, so it could be a bug. I'd like to set up a repro....