Comments
Sort by recent activity
I am still wondering about why $ReleaseVersion wasn't automatically sourced from Octopus.Release.Number, though. Why did I have to create an Octo var and set it? / comments
I am still wondering about why $ReleaseVersion wasn't automatically sourced from Octopus.Release.Number, though. Why did I have to create an Octo var and set it?
I tried that, too, @Kendra_Little. And, as you said, not an option for our environments where the DB is pre-deployed, sized, file layout set, etc. The odd part to me is that I don't recall adding my account to model db. I think the SQL 2014 install did that...or perhaps a code I made during install did that. Would be nice to have some cleaner handling in SCA for these scenarios. Also, glad to hear the team is looking at cleaning up the docs. Seems like there is a fair amount of content that is no longer accurate or relevant. Of be happy to help in that process. Thanks for your help, and honored to collaborate with a "celebrity". [image] Cheers, -Peter / comments
I tried that, too, @Kendra_Little. And, as you said, not an option for our environments where the DB is pre-deployed, sized, file layout set, etc.The odd part to me is that I don't recall adding my...
Thank you, @Kendra_Little (and nice to hear from you!). I'm familiar with that doc. This situation is a little different in that we didn't have a prod DB. Developers had a start on the DB on a shared dev server. It didn't exist anywhere else (no QA, no UAT, no prod). I created the SCA project and set the shared dev DB, which I refer to as "dev integration", as the "target" DB. I set my local empty DB as "dev" in SCA. Methinks the right way to do this is to set the shared DB that already has objects in it as "dev" and not to set the "target" when creating the project. Then refresh the shared dev DB, import the scripts (no "baseline"), then set the connection to my local dev DB and deploy the project. At lease that technique was successful for me. The other option, is a bit more of a kludge - uncheck the "Mark first folder as baseline" and add the <SkipBaselineCheck>True</SkipBaselineCheck> element to the unloaded sqlproj file. / comments
Thank you, @Kendra_Little (and nice to hear from you!). I'm familiar with that doc. This situation is a little different in that we didn't have a prod DB. Developers had a start on the DB on a s...
Thank you, @Kendra_Little. Much appreciated. I believe my issues are being caused by the fact that SQL Server 2014 put my domain user account in the model DB (as a DB user) during install. SCA doesn't like that at all. I removed that from model (and therefore my "empty" targets), and things worked OK in my test project. I verified that this is what caused my "real" project to barf, too. SCA somehow sees that extra user as a delta and New-DataBaseReleaseArtifact chooses to NOT include the baseline script. I removed the account from the model DB, recreated the target, and voila. This almost smells like a bug, but perhaps only for SQL 2014 (and?). Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64) Jun 17 2016 19:14:09 Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.3 <X64> (Build 14393: ) / comments
Thank you, @Kendra_Little. Much appreciated. I believe my issues are being caused by the fact that SQL Server 2014 put my domain user account in the model DB (as a DB user) during install. SCA do...
I understand this can be frustrating, @eliassal. The changes I'm suggesting are made in your SQL Change Automation project - not in TFS or powershell. I provided instructions on how to change your project in my post on feb 8. Of course you are welcome to create a ticket with RG support, too. That may provide a more expedient solution. / comments
I understand this can be frustrating, @eliassal. The changes I'm suggesting are made in your SQL Change Automation project - not in TFS or powershell. I provided instructions on how to change your...
@eliassal, I understand this can be confusing. I believe I had similar issues when attempting to deploy to a DB that I thought was empty, but SCA didn't, so it failed to deploy. For my case,I was able to: 1) uncheck "mark first folder as baseline" in the project settings. 2) add the "skip baseline check" flag to the project settings file by: 2a) right-click on the project file in solution explorer and select "unload project" 2b) right click on the unloaded project file and select "edit" 2c) in the first property group, add the following element: <SlipBaselineCheck>True</SkipBaselineCheck> 2d) save the project file and close it 2e) right click the project file and select "load..." Than you can use the powershell cmdlets to build and deploy. Any rogue objects in your target db might cause SCA to mark the first baseline script in your project as already deployed during the baseline check. I found success with this. I also found success (alternatively) by discovering that my "empty" target db actually had a user that was in the model db. This user caused SCA to decide not to deploy the baseline script to my "empty" db. Removing that user from model and therefore from any new db I created allowed the project to successfully deploy to a new empty target without the "skip baseline check hack. One of these options should work gro you. I hope this is helpful rather than more confusing. -Peter / comments
@eliassal, I understand this can be confusing. I believe I had similar issues when attempting to deploy to a DB that I thought was empty, but SCA didn't, so it failed to deploy. For my case,I was ...
I believe TFS (and all of the CI server add-ons) are using the powershell cmdlets behind the scenes. I believe my suggestions will help you. That said, this will be my last post on this thread. Good luck. / comments
I believe TFS (and all of the CI server add-ons) are using the powershell cmdlets behind the scenes. I believe my suggestions will help you. That said, this will be my last post on this thread. ...
Not sure if this relates to your exact situation, but this discussion may be helpful: https://forum.red-gate.com/discussion/84708/best-way-to-handle-starting-sca-project-from-existing-dev-db#latest I was running into baseline issues, too. -Peter / comments
Not sure if this relates to your exact situation, but this discussion may be helpful: https://forum.red-gate.com/discussion/84708/best-way-to-handle-starting-sca-project-from-existing-dev-db#latest...
Follow up: since I included the __migrationLog table and its data as part of the initial, non-SCA generated deployment to our "higher" (ops DBA controlled) environments, I was able to introduce the new idea of using a SSQLCM script to the ops DBAs. The second deployment was the addition of a single new migration in a New-DatabaseReleaseArtifact generated TargetedDeploymentScript.sql. I manually modified it to comment out the target sever check, so they would have one script (currently a requirement) for all of their servers. They successfully ran that in uat and load test servers, so we're at least gaining the benefit of SCA generated deployment scripts and tracking in the __migrationLog table. Concurrently, I've had some meetings to introduce the idea of using PowerShell to deploy using the Use-DatabaseReleaseArtifact cmdlet. That would give us the added benefit of snapshot, drift check, etc. as an intermediate step. I've also showed then a taste of my POC using SCA, bamboo, and Octopus deploy, but my sense is we're months (or longer) away from being able to get buy-in for that move. Thank you for your help, Steve. Honored to have a celebrity work with me in the forums. -Peter / comments
Follow up: since I included the __migrationLog table and its data as part of the initial, non-SCA generated deployment to our "higher" (ops DBA controlled) environments, I was able to introduce the...
Follow up: Initial prod deployment was a hack - ssms generated ddl and dml scripts. But,I did include the __MigrationLog table and data. Once I cleared up my SCA deployment issues, I have been able to pass on the New-DatabaseReleaseArtifact and Export-DatabaseReleaseArtifact generated TargetedReleaseScript.sql, with the server name check removed, to the ops DBAs. They have been willing to execute that manually in SSMS in SQLCMD mode. This is working as an intermediate process until I can socialize deployment via ci/cd tech. / comments
Follow up:Initial prod deployment was a hack - ssms generated ddl and dml scripts. But,I did include the __MigrationLog table and data.Once I cleared up my SCA deployment issues, I have been able t...