Service Broker is not a programmable object?

mjashton

I'm just starting out using SCA (already been using SSC) and importing my existing database, but ran into a problem with the default options when the database makes use of Service Broker Queues.
The first migration script created attempts to create the Queue, but as the Queues all rely on stored procedures, and they are only added *after* migrations are run (as 'programmable objects') then the verify step will fail. The only solution I've found is on the project setting and to 'import into migration scripts' for programmable objects.

But I want to be clear that this means I'd no longer have the (extremely!) useful functionality of being able to inspect history, compare etc *all* programmable objects now? Am I relegated to a pure migrations approach now?

Are there other options I'm not aware of?

Ivo_Miller

There are some other options:
You could define the relevant programmable objects in the relevant migration as well. This has to be done manually. You can then still keep on using the programmable objects in their separate files as before.
Note that if you baseline an existing database, this will happen automatically for the baseline script
See the following page for handling some programmable object dependency issues: https://documentation.red-gate.com/sca/developing-databases/concepts/baseline/resolving-unsupported-programmable-objects..

If it is safe to drop and recreate these objects outside of migrations, you can instead either manually handle them as additional scripts (https://documentation.red-gate.com/sca/developing-databases/concepts/migrations/additional-scripts) or you can configure them to be treated as programmable objects (by editing DeployChangesImportObjectTypes - see https://documentation.red-gate.com/sca/reference/sql-change-automation-project-settings)