Activity overview
Latest activity by danielpottenger
Hey @AdamY , The execution policy will need to be set to at least 'RemoteSigned' in order to import and run our scripts. Restricted doesn't allow the execution of any scripts, so it is likely an error in our release notes. I'm really sorry about that! I hope this works for you, but feel free to reply to this thread if there's still a problem, and I'll try my best to help resolve it. Many thanks, Dan / comments
Hey @AdamY ,The execution policy will need to be set to at least 'RemoteSigned' in order to import and run our scripts.Restricted doesn't allow the execution of any scripts, so it is likely an erro...
Hey @jaydarrenmiller , If a baseline script has already been generated for your schema and applied to your production databases, you can add another one within the baseline folder. If you do this directly using our tool, it should also generate you a file name for the migration (i.e 002_20201006-1620_Joe.Bloggs.sql), and a migration id within the file. From in SSMS, on the migrations tab, right click the baseline folder and click 'Add migration'. From within Visual Studio, right click the baseline folder, then 'Add' -> 'New Item'. You can add any of the statements you need to run, to the new baseline migration script, and then when you deploy the project to your production databases, the new baseline script should run (which can be verified by checking the migration log table). Many thanks, Dan / comments
Hey @jaydarrenmiller ,If a baseline script has already been generated for your schema and applied to your production databases, you can add another one within the baseline folder.If you do this dir...
Hey @jaydarrenmiller , It's possible to do that, as long as you're using a GUID at the top of the migration script. You're also able to seed the database using migration scripts too, though depending on the number of INSERT statements, you'll find that deployments may take longer. You can also rename the migration script files themselves, if required, as long as they contain the numbered prefix, as SQL Change Automation uses that to determine the execution order of the scripts. There is a bunch more information on the following page, that might be useful for you: https://documentation.red-gate.com/sca/developing-databases/concepts/data-population/strategies-for-data-population If you need any more help, feel free to reach out, Many thanks, Dan / comments
Hey @jaydarrenmiller ,It's possible to do that, as long as you're using a GUID at the top of the migration script. You're also able to seed the database using migration scripts too, though dependin...
Hey @jaydarrenmiller , The migration scripts support data insertion, and you should be able to do this just fine, as long as the migration scripts have a valid GUID at the top. You're also free to rename the scripts, as long as they contain the numeric prefix (i.e 001, 002, 003), as SQL Change Automation uses the prefix to determine the execution order. Once you've applied your scripts, you can check that the __MigrationLog table within your database contains the GUID that you've used, and that both your development database, and your shadow database contain the data as expected. For a little bit more information on this, and some potential alternatives, you might find the following link a good source: https://documentation.red-gate.com/sca/developing-databases/concepts/data-population/strategies-for-data-population. If you need any more help, feel free to reach out, Many thanks, Dan / comments
Hey @jaydarrenmiller ,The migration scripts support data insertion, and you should be able to do this just fine, as long as the migration scripts have a valid GUID at the top.You're also free to re...
Hey @pfiorella , Yep, you can do that! As putting the code here is a little bit troublesome, I've added another YAML file to my GitHub repo. Now, when you create the pipeline, and run it, it'll allow you to specify the database array. [image] [image] Hope it helps, Dan / comments
Hey @pfiorella ,Yep, you can do that!As putting the code here is a little bit troublesome, I've added another YAML file to my GitHub repo.Now, when you create the pipeline, and run it, it'll allow ...
Hey Chris, The best way would likely be to define your own YAML pipeline, which may be the easiest way to do what you need. With Azure pipelines, you can define a YAML file that can loop over a set of parameters and feed those in to a specific task. As an example, I've defined a release task, deploy-from-package.yaml. You can set up multiple different parameters and feed them in, if the server, and authentication method changes, though it may be more complex. To use the above task, you need to define your own pipeline using YAML. When creating your pipeline, you have the option to use YAML, at which point you can write something similar to the above (if you need help writing the YAML for some of the build steps, you can create it using our tasks within Azure, and then use the View YAML button within Azure DevOps, and then copy and paste it across). [image] [image] It isn't ideal to keep your username and password within the YAML, for obvious reasons, but you should be able to use service connections to specify the same thing, which should help to obfuscate the credentials. From the above, you can see that my pipeline creates the following on run: [image] [image] [image] [image] Hope this helps! Dan / comments
Hey Chris,The best way would likely be to define your own YAML pipeline, which may be the easiest way to do what you need.With Azure pipelines, you can define a YAML file that can loop over a set o...
Hey, From the looks of it, as you've generated the script, then it is by default, Marked as Deployed. This is because the change has been generated from something that already exists in the database. If you want the option to mark a script as deployed, then a script must then be edited manually. Alternatively, the script can be created manually through Add > Script in Visual Studio, rather than through the generate script button. Hope this helps! If you have any more questions, I'm happy to help as much as possible. [image] / comments
Hey,From the looks of it, as you've generated the script, then it is by default, Marked as Deployed.This is because the change has been generated from something that already exists in the database....