Using a new stored proc in a migration script
EricLamontagne
Posts: 46 Bronze 3
Hi,
My understanding, is that migration scripts run before the Programmable Objects, so my new stored procedure is not available to my migration script.
I can create the sp in the migration script (or one executed before), but I don't like this duplication of code...
Is there a solution I'm missing?
Regards,
Éric Lamontagne
My understanding, is that migration scripts run before the Programmable Objects, so my new stored procedure is not available to my migration script.
I can create the sp in the migration script (or one executed before), but I don't like this duplication of code...
Is there a solution I'm missing?
Regards,
Éric Lamontagne
Tagged:
Best Answer
-
DanC Posts: 642 Gold 5Hi @EricLamontagne
Ah, I understand and unfortunately, that would require a drastic change to the way SQL Change Automation works and we're moving towards Flyway and Flyway Desktop as part of our Redgate Deploy package for the future of DB Devops so I can't see this feature being implemented for SCAKind regards
Dan Calver | Redgate Software
Have you visited our Help Center?
Answers
In this case you can change the Programmable Objects setting to use
ScriptInMigrations
https://documentation.red-gate.com/sca/developing-databases/concepts/migrations/programmable-objects
This will then script the PO's into migration scripts directly, once configured you can delete all the existing programmable objects and then re-generate into migrations
Kind regards
Dan Calver | Redgate Software
Have you visited our Help Center?
We currently have a pretty large project using SCA and we have all our programmable objects neatly organized. I don't want to change any of this.
Right now, I have copied the necessary code into the migration script manually.
Having duplicated code at this point is not the end of the world for us event tough it might get out of hand if we keep doing so.
One suggestion: During the import of changes, new PO could have a checkbox like option where we could choose to put it in the migration script directly instead of the PO folder.
Regards,
Éric